Marco Calamari in Cassandra ne ha parlato qualche giorno fa.
"dignitosa coscienza e netta", lui non lo ha detto qui.
Maurizio
Il 11/04/24 18:25, 380° ha scritto:
Attenzione: NO PANIC, è molto probabile che i vostri sistemi "GNU/Linux"
non siano affetti da questa backdoor in XZ (ora risolta): per saperlo,
iscrivetevi, se non lo siete già, alla newsletter di sicurezza della
distribuzione che state utilizzando (o rivolgetevi a un professionista).
Buongiorno,
per diversi giorni il mio alter ego si è occupato con una certa
_apprensione_ di questa vicenda, ora per fortuna l'apprensione sta
scemando e può lavorare con più calma alle misure per mitigare questi
rischi... e lasciarmi scrivere qui in merito.
Qualcuno in lista almeno ne avrà sentito palare ma forse la maggior
parte ancora non sa che il 29 Marzo 2024 è stato scoperto il peggior
supply chain attack ad oggi conosciuto.
La vulnerabilità è tecnicamente conosciuta come CVE-2024-3094 e il NIST
gli assegna un punteggio di 10 (su 10), ma potrebbe benissimo essere 10
cum laude:https://nvd.nist.gov/vuln/detail/CVE-2024-3094
I dettagli tecnici e _sistemistici_ sono relativamente (poco) complessi
e NON trascurabili per poter avere una chiara e precisa comprensione del
/modus vivendi/ ma soprattutto del /modus operandi/ che ha reso
possibile questo attacco... "nucleare".
In merito si stanno scrivendo fiumi di parole, molte delle quali a
sproposito, anche da parte di "esperti del settore", come purtroppo
accade quando si tratta di "cose complesse" (non complicate!) di
informatica ;-(.
In questa prima parte, come /introduzione/ alla questione vi consiglio
un articolo che ritengo meritevole.
Prima però voglio sottolineare una opportuna quanto agghiacciante
considerazione di Bruce Schneier:
https://www.schneier.com/blog/archives/2024/04/xz-utils-backdoor.html
--8<---------------cut here---------------start------------->8---
Given how lucky we were to detect this one, I believe this kind of
operation has been successful in the past.
--8<---------------cut here---------------end--------------->8---
e una totalmente inopportuna e altrettanto superficiale:
--8<---------------cut here---------------start------------->8---
We simply have to stop building our critical national infrastructure on
top of random software libraries managed by lone unpaid distracted—or
worse—individuals.
--8<---------------cut here---------------end--------------->8---
Ecco finalmente l'articolo introduttivo:
https://www.insicurezzadigitale.com/backdoor-su-xz-il-problema-e-molto-piu-grande-non-e-lopen-source-e-non-si-risolve-con-un-aggiornamento-una-storia-incredibile/
«Backdoor su Xz: il problema è molto più grande, non è l'open source e
non si risolve con un aggiornamento. Una storia incredibile»
Dario Fadda, 2024-04-11
--8<---------------cut here---------------start------------->8---
Mondo Linux in allarme da alcuni giorni, grande eco per la
vulnerabilità rilevata su Xz il 29 marzo appena passato. Una backdoor
installata sul codice open source della libreria largamente utilizzata
per la compressione di dati che utilizza l'algoritmo [lzma], che
*permette di eseguire codice da remoto su un server SSH* senza averne
l'autenticazione.
Questi sono i fatti, ma il contenuto di questo articolo vuole
rispondere ad altre domande che sorgono naturalmente: come fa una
utility di compressione ad agire su SSH? Chi ha installato questa
backdoor e come ci è riuscito?
Proviamo a vederci chiaro, ma di sicuro premetto che le favolette
dell'instabilità di un progetto open source e dell'hacker annoiato
nella propria stanza, non reggono.
[lzma]<https://it.wikipedia.org/wiki/Algoritmo_Lempel-Ziv-Markov>
Come funziona la backdoor su Xz?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Non mi dilungherò in analisi dettagliate e tecniche sul funzionamento
di questa backdoor, già ampiamente dibattute ([qui] e [qui]), ma
giusto due righe per chiarirne il concetto base.
Vista l'efficienza della libreria Xz, è da sempre utilizzata da molti
altri software che necessitano di effettuare compressione dati
(soprattutto nella gestione dei loro pacchetti). Tra gli utilizzatori
c'è pure OpenSSH, il software più utilizzato per effettuare
connessioni sicure tra client e server (gestire da remoto la shell,
quindi la completa amministrazione, di un computer disposto altrove)
via SSH. Il pacchetto OpenSSH non ha però la diretta dipendenza della
libreria Xz. Qui dobbiamo prestare attenzione a questo passaggio,
perché è il primo punto di complicazione di *come è stato congegnato
l'atterraggio verso SSH* /senza farsi beccare/: OpenSSH ha una
funzionalità di notifica sui sistemi operativi che utilizzano
*SystemD* che è governata da una libreria “libsystemd” che a sua volta
utilizza una seconda libreria che si chiama “liblzma” che è parte del
progetto Xz! Un bel giro, per iniettare del codice malevolo ed
arrivare a destinazione, sicuramente niente di /fatto in casa/.
[qui]
<https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27>
[qui]<https://gynvael.coldwind.pl/?lang=en&id=782>
Come è stato possibile?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
La backdoor Xz è stata la parte finale di una campagna durata due anni
di attività, *si tratta di operazioni di human intelligence* molto
elaborate e che richiedono tempo e persone. Due anni di /lavoro/ per
avere una backdoor aperta circa tre settimane prima che venga
rilevata. C'è stato un approccio che è durato mesi prima che il
*personaggio di Jia Tan* (JiaT75 questo lo pseudonimo di chi ha
diffuso il codice malevolo all'interno del progetto Xz originale)
fosse ben posizionato per ricevere un ruolo di fiducia nel progetto,
da parte di chi segue la manutenzione diretta ( /Lasse Collin/ è
invece il suo nome).
L'account su GitHub di *Jia Tan viene registrato nel 2021*. Non
opererà però subito su Xz, ma inizia scrivendo un commit per un altro
pacchetto open source “libarchive”. Con questo commit aggiunge una
vulnerabilità pure li che nessuno discute mai e che quindi, ad oggi
potrebbe far considerare *non sicuro pure libarchive*.
In sintesi, Jia Tan e altri attori hanno lavorato per introdurre una
backdoor nel progetto XZ, utilizzando varie tattiche per aumentare il
controllo sul progetto e cercando di far includere la versione
compromessa in diverse distribuzioni di Linux.
La storia
╌╌╌╌╌╌╌╌╌
Subito dopo i fatti del 2021 appena descritti è un susseguirsi di
attività che portano fino ai giorni attuali.
[...]
La gravità
╌╌╌╌╌╌╌╌╌╌╌
Da come si sono articolati gli eventi, possiamo comprendere bene la
gravità della situazione e di come l'organizzazione dietro questo
attacco, sia enormemente organizzata. Va ricordato che la versione
vulnerabile di Xz è rimasta operativa per [tre settimane] circa (dal 9
marzo 2024), in ogni caso è plausibile che gli sforzi di questi due
anni per condurre l'operazione, mirino ai ritardi negli aggiornamenti,
prima che tutti i sistemi coinvolti (vista la diffusione dello
strumento Xz), vengano raggiunti dagli aggiornamenti necessari per
sanare il problema.
Il modus operandi di questa cronologia di eventi, è il tipico stile di
operazione di human intelligence che punta a *sconvolgere il
bersaglio* (Lasse Collin, mantenitore del progetto), dal punto di
vista psicologico (capendo su che leve operare): ecco cosa scrive
Lasse in una mailing-list nel 2022 quando aumentavano le pressioni per
far aggiungere un altro contributore al progetto Xz.
[immagine del messaggio:
https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html]
Sottolinei un problema che qualcuno non è in grado di risolvere, ti
fai spalleggiare da altri utenti (finti, della tua organizzazione
malevola), e ti rendi disponibile a risolverlo. È il modo migliore per
entrare nella cerchia della fiducia, di un debole preso dallo
sconforto per mille altre ragioni.
Ci sono voluti 12 mesi di lavoro per passare da essere nessuno, a
essere un contributore del progetto Xz. Per un progetto così ampio è
poco, non è tanto tempo. Il lavoro psicologico di questa
organizzazione in questo caso è stato preponderante nella testa di
Lasse Collin.
[tre settimane]<https://git.tukaani.org/?p=xz.git;a=summary>
Chi sono i responsabili?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Difficile dirlo. GitHub ha sospeso il progetto Xz bloccandone la
pagina di riferimento, ha anche bannato Lasse Collin come responsabile
del disastro, e questo è ancora più inaccettabile anche visto gli
sforzi (stipendiati zero Euro) da quando esiste Xz ad oggi, e dal 29
marzo ad ora per offrire supporto nel mitigare i danni [documentando
tutto].
GitHub ha anche ovviamente bannato l'account di JiaT75 che ha
fisicamente firmato gli aggiornamenti malevoli del programma,
certo. Ma questo account non esiste, è stato creato ad hoc solo per
questa lunghissima operazione, come lui ne possono esistere mille in
giro.
Sottolineo l'aggressività della campagna: Jia Tan ha cercato di far
integrare la sua modifica vulnerabile anche su progetti terzi come
1Password (gestore di password largamente utilizzato), su Ubuntu e su
Fedora. Progetti enormi che coinvolgerebbero una marea di utenti in
tutto il mondo.
Fortunatamente l'operazione è stata interrotta, ma la responsabilità
in cose così grandi e impattanti (per me) è una sola: un gruppo
sponsorizzato (anche finanziariamente) da uno Stato. Alcuni indizi
portano alla Cina (o comunque all'oriente) per eventuali dettagli di
orari di operatività e lingua parlata dagli utenti coinvolti, ma è
difficile dirlo con certezza.
Sicuramente si può dire che dietro ci sia una *organizzazione
criminale dalle grosse capacità economiche*: ne sono state spese più
dal 2021 ad oggi nella conduzione di questa campagna mirata
all'installazione della backdoor, che in tutta la vita del progetto Xz
per la sua realizzazione.
*Il software open source è sicuro?* Sì, lo è eccome. La comunità è il
cuore pulsante di ogni progetto e nel mondo è pieno di persone che
vogliono offrire supporto reale per migliorare un progetto, a volte
nato per hobby. È quando il progetto matura e diventa di proporzioni
ciclopiche che deve arrivare il vero supporto da parte della
comunità. Non si lascia uno sviluppatore da solo in balia del mondo,
mentre tutti /fanno i soldi/ con la sua libreria. Non si lascia mai
che un progetto abbia una persona da sola che pubblichi delle
modifiche al codice, senza che altri occhi le abbiano viste e
riviste.
[documentando tutto]<https://tukaani.org/xz-backdoor/>
--8<---------------cut here---------------end--------------->8---
Se avete compreso la pericolosità di questa _classe_ di backdoors
(spiegherò nella prossima parte /quale/ classe), vi lascio immaginare
cosa potrebbe succedere se con un sistema _analogo_ qualcuno riuscisse a
impiantare una backdoor del genere in una libreria usata dal sistema
operativo _proprietario_ della Intel Management Engine... o /qualsiasi/
sistema di out-of-band management (che è sostanzialmente un sistema
operativo "embedded") con accesso via LAN:
https://en.wikipedia.org/wiki/Out-of-band_management
Intuite la portata della falla /sistemistica/ di sicurezza? :-O
Fine della prima parte.
Saluti, 380°
_______________________________________________
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
------------------------------------------------------------------------
lo straniero non parla e non capisce la nostra lingua,
che non è più nostra, perché la nostra vera lingua
diventa la traduzione, lo scambio
luca ferrieri, dalla public library all’open library
------------------------------------------------------------------------
Maurizio Lana
Università del Piemonte Orientale
Dipartimento di Studi Umanistici
Piazza Roma 36 - 13100 Vercelli
_______________________________________________
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
