Backdoor SSH
Un manutentore nefasto o compromesso ha inserito un comportamento dannoso in una libreria denominata liblzma, parte degli strumenti di compressione e delle librerie xz, che risulta in una backdoor in SSH. Si tratta di un attacco avanzato alla catena di fornitura del software poiché la libreria è stata intenzionalmente modificata per la backdoor, con tecniche di offuscamento e occultamento per nascondere il carico utile dell'attacco ai revisori. È stato scoperto e divulgato di recente (il 29 marzo scorso) e la gestione dell'attacco è in corso. Tuttavia, è stato rapidamente contenuto poiché sembra influenzare solo le versioni pre-release di un set limitato di ambienti (pacchetti DEB e RPM, per l'architettura x86_64 e compilati con GCC). In ogni caso, il CVE è stato dato un Punteggio di base CVSS di 10, riservato alle vulnerabilità di sicurezza informatica più critiche. Se dovesse entrare in distribuzioni stabili, l'impatto sarebbe travolgente. L'analisi tecnica dell'attacco, compresa la xz backdoor spiegato in dettaglio, è stato analizzato altrove. Questo post si concentrerà sulla cronologia dell'attacco, su come è stato rilevato, su come l'incidente è stato gestito fino ad oggi e su quali lezioni si possono trarre dall'attacco.Come è stata iniettata la backdoor XZ
Nota: il repository git è in git.tukaani.org. Tuttavia, c'era anche un Repository ospitato su GitHub (attualmente bloccato) dove l'account GitHub pubblicava le modifiche che sono state successivamente integrate nel repository Git. Una parte della backdoor sembra essere solo nei tarball distribuiti per le versioni 5.6.0 e 5.6.1, non nei repository git e si basa su un singola riga nel build-to-host.m4 file macro utilizzato da autoconf. L'altra parte era in due presunti file di test bad-3-corrotto_lzma2.xz and buono-grande_compresso.lzma che erano commitTed dall'account GitHub “Jia Tan” (JiaT75) nel Programma archivio xz il 23 febbraio. È stata una modifica innocua l'aggiunta di file di test (presumibilmente blocchi compressi .lzma e .xz). È interessante notare che i file di test non sono stati utilizzati dai test! La riga nel file .m4 inietta uno script offuscato (incluso nel tarball) da eseguire alla fine della configurazione se alcune condizioni corrispondono. Modifica il Makefile per il liblzma libreria per contenere il codice che estrae i dati dal file .xz, che termina dopo la deoffuscamento in questa sceneggiatura, viene richiamato alla fine della configurazione. Decide se modificare il processo di compilazione per iniettare il codice: solo sotto GCC e il linker GCC, sotto Debian o rpm e solo per x86_64 Linux. Una volta abbinato, il codice inserito intercetta l'esecuzione sostituendone due ifunc risolutori in modo che alcune chiamate vengano sostituite. Ciò fa sì che le tabelle dei simboli vengano analizzate in memoria (questo richiede tempo, che ha portato al rilevamento, come spiegato più avanti). Poi le cose si fanno interessanti: la backdoor installa un audit hook nel linker dinamico, aspettando l'arrivo del simbolo della funzione RSA_public_decrypt, che viene reindirizzato a un punto nel codice della backdoor, che a sua volta richiama libcrypto, presumibilmente per eseguire la normale autenticazione. E il payload si attiva se il programma in esecuzione ha il nome del processo /usr/sbin/sshd. Era chiaro che l’obiettivo erano i server SSH. Tradizionalmente, sshd server come OpenSSH non erano collegati liblzma, ma sshd lo è spesso rattoppato per supportare systemd-notify in modo che altri servizi possano essere avviati quando sshd è in esecuzione. E poi liblzma viene caricato indirettamente da systemd, chiudendo il cerchio. La backdoor non è stata ancora completamente analizzata, ma sembra di esserlo consentendo l'esecuzione di comandi remoti (RCA) con i privilegi del demone sshd, in esecuzione in un contesto di pre-autenticazione. Le informazioni dal certificato remoto, quando corrispondono alla backdoor, vengono decrittografate con ChaCha20 e quando vengono decrittografate con successo vengono passate al sistema(). Quindi questo è essenzialmente un RCE recintato, molto peggio di un semplice bypass della chiave pubblica. Un tarball successivo della versione 5.6.1 ha mostrato ulteriori sforzi per nascondere le tracce, aggiungendo ulteriore offuscamento per i nomi dei simboli e tentando di correggere gli errori rilevati. UN meccanismo di estensione dove sono stati cercati file di test aggiuntivi per determinate firme da aggiungere alla backdoor. Questo attacco abbastanza sofisticato potrebbe passare inosservato finché non verranno raggiunte distribuzioni Linux stabili. Fortunatamente, ad alcune persone piace verificare perché accadono cose anormali.La scoperta dell'attacco backdoor XZ
Molte volte il comportamento dannoso introdotto viene portato alla luce per caso o incidente. Un buon esempio è stato a avviso di deprecazione (“Chi se ne frega degli avvertimenti?”) che ha portato alla scoperta del attacco a flusso di eventi nell'ottobre 2018. Un altro è l'utente che ha avvisato CodeCov nell'aprile 2021 che il loro script di caricamento bash non ha superato il checksum ("Chi verifica l'integrità degli artefatti con i checksum"?) Anomalie e strani sintomi con ssh loginS (loginrichiede molta CPU e aumenta il tempo trascorso, errori di Valgrind) ha suscitato la curiosità di Andrés Freund, un vigile sviluppatore PostgreSQL ma non un analista della sicurezza (come ha affermato). Dopo alcune indagini con OpenSSH su Debian Sid, ha concluso che un problema di tempo di risposta si basava su una libreria, liblzma, Parte del xz-utils libreria di compressione. La ragione: "il repository xz upstream e i tarball xz sono stati sottoposti a backdoor”. Questa diagnosi era così accurata! Il 29 marzo 2024 Andres ha pubblicato su Openwall la prima analisi: “backdoor nell'upstream xz/liblzma che porta alla compromissione del server ssh”. Il fatto: i tarball di XZ Utils 5.6.0 e 5.6.1 contengono una backdoor. Questi tarball sono stati creati e firmati dal già citato account Jia Tan. He pubblicato in Mastodonte più tardi quel giorno, riconoscendo che la scoperta era stata accidentale e richiedeva molte coincidenze. Vale la pena leggere i commenti degli altri utenti. Utente GitHub lo stesso (alias Sam James) ha pubblicato un bel Gist Domande frequenti sulla backdoor xz-utils dove l'attacco è stato riassunto, collegandosi a altro analisi approfondite del carico utile dell'attacco. Queste analisi sono state tecnicamente succose e ci hanno aiutato a comprendere meglio l'iniezione, che è stata molto elaborata:- xz/liblzma: Spiegazione dell'offuscamento dello stadio Bash. Bella analisi sul deoffuscamento da parte dello script di iniezione, in quattro “fasi”.
- Il filo azzurro di Filippo Valsorda Analisi della backdoor stessa in RSA_public_decrypt, che ne mostra la natura: un RCE, non un bypass di autenticazione e un gate (accetta la chiave privata dell'autore e, in caso contrario, ripristina il comportamento normale)/non rimborsabile. L'autore intendeva mantenere un basso profilo per evitare di essere scoperto!
- Analisi della backdoor XZ di @smx-smx (WIP) – Analisi aggiuntiva della backdoor (mi sono perso quasi all'inizio 😀)
- xz wiki della documentazione backdoor, un'altra analisi dello script di injection 5.6.1.
Come è stato gestito l'incidente
La divulgazione di Andreas Freund è stata cauta perché, secondo le sue stesse parole:"Dato l'apparente coinvolgimento upstream, non ho segnalato un bug upstream. Poiché inizialmente pensavo che fosse un problema specifico di Debian, ho inviato un rapporto più preliminare a security@...ian.org. Successivamente, ho segnalato il problema a distros@. CISA è stato avvisato da una distribuzione."
Red Hat ha assegnato questo problema CVE-2024-3094. Poi la voce circolò a macchia d'olio. Lasse Collin, l'altro manutentore dell'XZ, ha aggiunto a nuovi commit sabato 30 marzo intitolato "CMake: correzione del controllo sandbox Landlock sabotato". Uno dei metodi di sandboxing della libreria è stato sabotato, almeno durante la creazione con CMake. Ha prontamente segnalato il problema nella Backdoor di XZ Utilis. Red Hat ha assegnato questo problema CVE-2024-3094 (vedi anche in CVE, NVD, Ubuntu). Gli è stato assegnato un enorme Punteggio base CVSS pari a 10. Tali punteggi prendono sempre d'assalto Internet. CISA lo stesso 29 marzo ha rilasciato un allarme, forse troppo semplicistico data l'urgenza, consigliando agli utenti il downgrade alla versione stabile 5.4.6. I repository GitHub sotto l'organizzazione Tukaani sono stati disabilitati (è positivo o negativo? Penso che sia positivo: molte distribuzioni e organizzazioni si collegavano ancora alle versioni GitHub per procurarsi i tarball infetti da compilare. Disabilitare il repository lo impedisce. Esiste comunque una copia o i pronti contro termine a git.tukaani.org). Anche gli account GitHub JiaTan75 e Lasse Collins (Larhzu) sono stati sospesi. Questo fa parte del contenimento, anche quando può colpire persone innocenti. JiaT75 attività in repository non disabilitati non può ancora essere visto. L'industria ha reagito prontamente. Molti fornitori hanno pubblicato regole per il rilevamento di sistemi vulnerabili, come Yara governao supporto negli strumenti commerciali da sysdig, PAN, e altri. Agli specialisti della sicurezza piace Giacomo Berthoty pubblicato sulla revisione del nostro approccio al software open source. Ora siamo nella fase di eradicazione e recupero dell’incidente. Altri progetti gestiti da JiaTan75 sono sotto stretta revisione, in particolare il libarchivio/libarchivio (dove JiaTan75 collaborava regolarmente) e il fuzzer oss-fuzz (dove questo commit realizzato da JiaTan75 ha cercato di evitare oss-fuzz, che in effetti non è stato in grado di rilevare la backdoor). Questi tentativi di occultamento aggiungono ulteriori prove.
Chi è sotto attacco?
O l'account GitHub JiaT75 è stato compromesso (ricorda che GitHub ha recentemente imposto la 2FA) oppure l'utente fisico titolare dell'account è passato al lato oscuro. Ma ci sono ragioni convincenti per pensare a una minaccia persistente avanzata (APT), magari sostenuta dallo Stato, a causa della sofisticazione tecnica dell’attacco. Ulteriori indagini da parte delle agenzie di sicurezza informatica e delle forze dell’ordine diranno… Questa voce in YCombinator Hacker Notizie su Jia Tan getta luce sul “chi” e sulla sua attività. Consigliato! Fornisce molte informazioni su come i malintenzionati tentano di ingannare gli altri utenti, utilizzando l'ingegneria sociale."Molto fastidioso - l'apparente autore della backdoor è stato in comunicazione con me (rwmj) per diverse settimane cercando di aggiungere xz 5.6.x a Fedora 40 e 41 a causa delle sue "grandi nuove funzionalità". Abbiamo anche lavorato con lui per risolvere il problema di Valgrind (che ora risulta essere causato dalla backdoor che aveva aggiunto). Abbiamo dovuto gareggiare ieri sera per risolvere il problema dopo un'involontaria rottura dell'embargo. Ha fatto parte del progetto xz per 2 anni, aggiungendo tutti i tipi di file di test binari, e ad essere onesti con questo livello di sofisticatezza sarei sospettoso anche verso le versioni più vecchie di xz fino a prova contraria."
Jia Tan ha adottato misure per impedire di essere tracciato: sembra che abbia utilizzato una VPN (vpn.singapore.witopia.net) per connettersi, il che di per sé è ok. E molte modifiche sembrano essere supportate da e-mail temporanee e monouso (da ProtonMail in questo caso) che sollecitano a unire le modifiche. L'attore potrebbe avere intenzione di andare ancora più in profondità, fino al kernel Linux, in quanto collaboratore del file xy-incorporato progetto. Una prima analisi non ha trovato prove di aborto spontaneo, ad oggi. Nota: un altro collaboratore di basso profilo di XZ "Hans Jansen" (Utente GitHub "hansjans162") lo è sotto esame. Il suo account su Debian è ora bloccato. Ha fatto molti aggiornamenti a Debian Games per nascondere quello che voleva su debian/xz-utils, un aggiornamento all'upstream 5.6.1 per sbrigarsi con la distribuzione della backdoor su debian/unstabile. Tutto quello che possiamo dire, per ora, è che si tratta di un APT (ancora non identificato) che utilizza diversi account, lavora da almeno due anni su questa campagna e lavora pazientemente per impiantare un RCE in SSH.
L'attacco backdoor XZ era prevenibile?
Piuttosto difficile. In primo luogo, parte della backdoor iniettata è arrivata in file di test compressi che non sono stati utilizzati dai test. Retrospettivamente, questo potrebbe far sorgere qualche (rumoroso) allarme, ma a chi importa di verificare che tutti i file di test siano utilizzati dai test effettivi nel mondo reale? In secondo luogo, parte della backdoor iniettata è arrivata in file macro nei tarball di release, ed è difficile verificare manualmente eventuali differenze con i tarball previsti. Anche l'automazione è complessa, poiché il risultato atteso dalla build stessa (per chiunque sappia come funzionano automake/autoconf) è difficile da modellare per analizzare se il tarball reale corrisponde alle aspettative. Alcuni lo hanno proposto as "La mancata corrispondenza dei tarball dall'albero git è una funzionalità, non un bug". La provenienza dei tarball binari dal suo codice sorgente è un problema irrisolto. Reputazione degli utenti? Bene, l'account GitHub JiaTan75 non stava facendo cose canaglia secondo il passato commitS. È stato sospeso solo dopo che le prove si sono accumulate, ma fino al 29 marzo quell'utente era abituale e svolgeva la normale attività. Beh, non così normale. Dopo commitS (questo, questo, questoe questo che ha modificato il codice dell'exploit) ha provato a correggere gli errori di valgrind e i crash in alcune configurazioni, a causa delle differenze con il layout dello stack previsto dalla backdoor. Commit le revisioni potrebbero rilevarlo, ma chi ha la pazienza di analizzare i cambiamenti in un file di test binario o la vera motivazione per un cambiamento negli attributi GCC nel codice sorgente C? Si dovrebbe lanciare un allarme quando un file SSH login impiega 800 ms invece di 300 ms? Probabilmente solo le persone iper-prudenti prenderebbero nota. Cicerone disse: “La temerarietà appartiene alla giovinezza; prudenza fino alla vecchiaia”. L'infrastruttura ifunc è stata aggiunta nel giugno 2023 da "Hans Jansen" e "Jia Tan". Questo è il primo commit aggiunta del supporto ifunc a crc64_fast.c (successivamente utilizzato per iniettare la backdoor). Mesi prima di inserire i file binari della backdoor nei file di test!
Nota: Autore e commitqui differiscono, ma questo è normale: Lasse Collin è il manutentore del progetto e ha unito le modifiche. Ringrazia anche “Hans Jansen”…
Nessuno ha sollevato preoccupazioni prima del post di Andres Freund e del CVE creato da RedHat. Se vedi una serie di strumenti in grado di rilevare questo problema, rilevano subito il componente interessato, ex post facto.
Probabilmente la migliore prevenzione è arrivata dalla natura delle distribuzioni Linux e dal fatto che le versioni instabili e all'avanguardia passano solo alle distribuzioni stabili a valle dopo un processo frenetico.
Lezioni apprese dall'attacco XZ bBackdoor
Abbiamo notato quanto sia difficile da rilevare intenzionale backdoor. Le backdoor dovrebbero essere considerate una minaccia interna, poiché vengono installate dal personale interno o tramite account interni compromessi. E quei ragazzi sono per lo più fidati. E quando la backdoor viene impiantata nell’artefatto distribuito, diventa più difficile da rilevare.
Alcuni autori come Kevin Beaumont puntato verso sistema, che apre un'ampia superficie di attacco di servizi di terze parti alle backdoor. Questo è ciò di cui il cattivo attore ha abusato qui. Systemd ha molti occhi, ma XZ è una libreria oscura lungo la catena. “Quando il monte è inquinato, a valle tutti bevono l’acqua avvelenata”.
Una richiesta di modifica non correlata nel sistema per caricamento dinamico delle librerie di compressione, che eliminerebbe la backdoor, era già integrato nel sistema ma non ancora consegnato. Le dipendenze aggiuntive introdotte da libsystemd potrebbero essere la fonte di vulnerabilità, e ieri è stata aperta questa richiesta.
A commento nella sezione "xz: disabilita ifunc per risolvere il problema" commit ha fornito una visione chiara su dove focalizzare l’attenzione se vogliamo prevenire tale attività (il corsivo è mio):
“La lezione che dovremmo imparare come comunità è più quella di garantire software supply chain security olisticamente, controllando i sistemi di creazione oltre il semplice codice sorgente. Come la violazione di SolarWinds in cui gli aggressori hanno modificato gli aggiornamenti software per l’offerta di software di monitoraggio closed-source di SolarWinds”.
La scoperta anticipata e la pronta reazione hanno limitato moltissimo l’impatto. Se ricordi il scena finale da Men in Black III: “Ci siamo andati vicini”. Ancora una volta K non si dimenticò di lasciare la mancia. E nessun boglodita è entrato nelle distribuzioni stabili di Linux.
1. "Non sono un ricercatore di sicurezza, né un reverse engineering." 2. Jia è un nome proprio cinese comune. Anche Tan è un cognome comune che significa "magnifico". Molte persone non imparentate condividono questo nome, per favore non condannate nessuno che lo porti!
