Questo articolo è stato scritto in data 02-Aprile-24. Le indagini sono ancora in corso d’opera pertanto è normale che possano risultare obsolete nel breve periodo.
Lo scopo di questo articolo è quello di realizzare una timeline con qualche accorgimento tecnico a quanto già presente in abbondanza in rete (in fondo le fonti dalle quali ho preso informazioni per redigere il post).
XZ Utils (e la sua libreria sottostante liblzma) sono progetti open source che implementano la compressione e decompressione lzma. Questa è inclusa in molte distribuzioni Linux ed è molto apprezzata dagli sviluppatori portandola ad essere ampiamente utilizzata in tutto l’ecosistema Linux.
Quasi due anni fa, uno sviluppatore di nome Jia Tan si è unito al progetto e ha iniziato ad aprire richieste pull per varie correzioni di bug o miglioramenti. Fino a qui tutto bene, d’altronde è così che funzionano le cose nel mondo open source. Nel corso degli anni, dopo aver costruito fiducia e credibilità, Jia Tan ha iniziato a ricevere le autorizzazioni per il repository: prima le autorizzazioni di commit e, infine, i diritti di release manager.
E’ opinione comune – stando allo stato dell’arte – che come parte dello sforzo per ottenere queste autorizzazioni, Jia Tan abbia utilizzato un’interessante forma di ingegneria sociale: sono stati utilizzati account falsi per inviare una moltitudine di richieste di funzionalità e reclami su bug per fare pressione sul manutentore originale, causando infine la necessità di aggiungere un altro manutentore al repository.
Dopo aver contribuito al codice per circa due anni, nel 2023 Jia Tan ha introdotto alcune modifiche a XZ incluse come parte della versione 5.6.0.
Tra questi cambiamenti c’era una sofisticata backdoor.
Il codice aggiunto alle versioni 5.6.0 e 5.6.1 di xz modifica il modo in cui funziona il software. La backdoor manipola sshd, eseguibile utilizzato per effettuare connessioni SSH remote, per consentire a specifici aggressori remoti che possiedono una specifica chiave privata di inviare payload arbitrari tramite SSH che verranno eseguiti prima della fase di autenticazione, dirottando di fatto l’intera macchina della vittima.
E’ importante sottolineare che nessuno ha effettivamente visto (almeno fino ad ora) il codice caricato, quindi non è noto quale codice l’aggressore intendesse eseguire. In teoria, il codice potrebbe consentire qualsiasi cosa, incluso il furto di chiavi di crittografia o l’installazione di malware.
Per chi si stesse chiedendo come fa un utility di compressione a manipolare il processo di accesso via ssh qui la risposta: qualsiasi libreria può manomettere il funzionamento interno di qualsiasi eseguibile a cui è collegata. Spesso, lo sviluppatore dell’eseguibile stabilisce un collegamento a una libreria necessaria affinché funzioni correttamente.
OpenSSH, l’implementazione sshd più popolare, non collega la libreria liblzma, ma Debian e molte altre distribuzioni Linux aggiungono una patch per collegare sshd a systemd, in particolare la chiamata a dlopen() di liblzma. Systemd, a sua volta, si collega a liblzma e questo consente a xz-utils di esercitare il controllo su sshd.
Non sono mancate le frecciate da parte dei soliti franchi tiratori sull’argomento, ma ovviamente, lascio ogni qualsivoglia commento ai bar dello sport, per così dire.
La backdoor è piuttosto complessa. Tanto per cominciare, non la si trova nel repo xz ufficiale GitHub (anche perchè è stato chiuso). In quello che sembra un tentativo di evitare il rilevamento, invece di pushare parti della backdoor nel repository git pubblico, Tia Jan l’ha inclusa solo nelle versioni tarball del codice sorgente. Ciò ha fatto sì che parti della backdoor rimanessero relativamente nascoste, pur continuando a essere utilizzate durante il processo di creazione dei progetti dipendenti.
La backdoor è composta da molte fasi introdotte su più commit:
Anche la catena di esecuzione è composta da più fasi:
Riporto il post originale di Thomas Roccia con relativa infografica
0a 31 fd 3b 2f 1f c6 92 92 68 32 52 c8 c1 ac 28
34 d1 f2 c9 75 c4 76 5e b1 f6 88 58 88 93 3e 48
0a 31 fd 3b 2f 1f c6 92 92 68 32 52 c8 c1 ac 28
34 d1 f2 c9 75 c4 76 5e b1 f6 88 58 88 93 3e 48
10 0c b0 6c 3a be 14 ee 89 55 d2 45 00 c7 7f 6e
20 d3 2c 60 2b 2c 6d 31 00
Sebbene la chiave pubblica sia nota, solo gli aggressori hanno la corrispondente chiave di firma privata Ed448, garantendo quindi che solo gli aggressori possano generare payload validi per la backdoor. Inoltre, la firma è legata alla chiave pubblica dell’host, il che significa che una firma valida per un host non può essere riutilizzata su un host diverso.
Vista la complessità e la preparazione dell’attacco, la community infosec sta sempre di più pensando che si tratti di un “nation-state level cyberattack”.
EOF