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.
Come funziona la backdoor su Xz?
Non mi dilungherò in analisi dettagliate e tecniche sul funzionamento di questa backdoor, già ampiamente dibattute (here e here), 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.
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.
Aprile 2022:
- Jia Tan invia una patch irrilevante tramite una mailing list.
- Jigar Kumar inizia a fare pressioni per l’unificazione della patch.
- Jigar Kumar poi spinge Lasse Collin ad aggiungere un altro manutentore a XZ.
2023:
- JiaT75 (Jia Tan) fa il suo primo commit su XZ, diventando in seguito uno dei contributori più attivi.
- A marzo, l’email di contatto principale nell’oss-fuzz di Google viene aggiornata per essere quella di Jia, anziché di Lasse Collin.
- Una modifica critica viene introdotta nel repository XZ da Jia Tan, mascherata come lavoro di Lasse Collin.
2024:
- Viene aperta una richiesta pull per cambiare l’URL del progetto XZ.
- Viene aggiunto un commit contenente i passaggi finali per una backdoor nel repository XZ.
- Viene inviata una mail alla mailing list oss-security annunciando la scoperta della backdoor.
- Si diffonde una panoramica tecnica dell’exploit.
- Hans apre una richiesta per includere la versione compromessa di XZ in Debian.
- Altri account sospetti spingono per l’inclusione della versione vulnerabile in vari progetti.
- Un dipendente di 1Password chiede di aggiornare la libreria alla versione vulnerabile per un progetto Go.
- Jia Tan cerca l’inclusione della versione compromessa in Fedora e Ubuntu.
- GitHub sospende l’account di JiaT75 e il repository XZ, causando un’indagine sulla situazione.
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.
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.
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.
