Backdoor di XZ Utils: tutto ciò che dovete sapere e cosa potete fare
Analisi riassuntiva
La vulnerabilità CVE-2024-3094 è stata scoperta nella libreria open-source XZ Utils originata dal codice dannoso che era stato inserito in essa da uno dei responsabili della sua manutenzione.
Originariamente segnalata come backdoor di bypass dell'autenticazione SSH, ad un' ulteriore analisi è risultato che la backdoor, in effetti, consente l'esecuzione di codice remoto (RCE).
L'autore dell'attacco ha iniziato a prendere parte al progetto XZ quasi due anni fa, guadagnando lentamente credibilità finché non è riuscito ad ottenere il ruolo di responsabile della manutenzione. Queste operazioni a lungo termine sono, solitamente, l'ideale per i criminali sostenuti da governi nazionali, tuttavia attualmente l'attacco non è stato ancora attributo a nessuno nello specifico.
Poiché la backdoor influenza le ultime versioni di XZ Utils, si consiglia di effettuare il downgrade ad una versione non compromessa. In questo blog, vengono fornite altre potenziali mitigazioni che consentono di limitare il raggio d'azione dell'attacco.
Antefatto
XZ Utils, e la sua libreria sottostante liblzma, sono progetti open-source che implementano la compressione e la decompressione lzma. Questi progetti sono inclusi in molte distribuzioni di Linux immediatamente disponibili, sono molto popolari tra gli sviluppatori e sono ampiamente utilizzati nell'ecosistema di 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. Fin qui, tutto tutto bene, d’altronde è così che funzionano le cose nel mondo open-source. Nel corso degli anni, dopo aver creato intorno a sé un clima di fiducia e credibilità, Jia Tan ha iniziato a ricevere le autorizzazioni per il repository: prima le autorizzazioni di commit e, infine, i diritti di responsabile dei rilasci.
Sembra che, come parte del suo impegno volto ad ottenere queste autorizzazioni, Jia Tan abbia usato un'interessante forma di social engineering: sono stati utilizzati account fittizi per inviare una moltitudine di richieste di funzioni e reclami sui bug in modo da mettere pressione sul responsabile della manutenzione originale, causando poi, alla fine, la necessità di aggiungere al repository un altro responsabile della manutenzione.
Dopo aver contribuito al codice per circa due anni, nel 2023 Jia Tan ha introdotto alcuni cambiamenti alla libreria XZ che sono stati inclusi come parte della versione 5.6.0. Tra questi cambiamenti, figurava anche una sofisticata backdoor.
La backdoor
La backdoor è piuttosto complessa. Tanto per cominciare, non la si trova nel repository GitHub di xz (anche perché è stato chiuso, ma non è questo il punto). In ciò che sembra un tentativo di evitare il rilevamento, invece di spingere le parti della backdoor nel repository Git pubblico, il criminale-responsabile della manutenzione 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 molti fasi introdotte tramite più commit:
Utilizzo delle IFUNC nel processo di creazione per "dirottare" le funzioni di risoluzione dei simboli da parte del malware
Inclusione di un oggetto condiviso offuscato, che è nascosto nei file dei test
Esecuzione di uno script impostato durante il processo di creazione della libreria che estrae l'oggetto condiviso (non incluso nel repository, solo nelle versioni, ma aggiunto al file .gitignore)
Disabilitazione del landlocking, una funzionalità di sicurezza che consente di limitare i privilegi del processo
Anche la catena di esecuzione è composta da più fasi:
Lo script dannoso build-to-host.m4 viene eseguito durante il processo di creazione della libreria e decodifica il file "test" bad-3-corrupt_lzma2.xz in uno script bash
Lo script bash esegue quindi un processo di decodifica più complicato su un altro file "test", good-large_compressed.lzma, decodificandolo in un altro script
Questo script quindi estrae un oggetto condiviso, liblzma_la-crc64-fast.oche viene aggiunto al processo di compilazione di liblzma
Questo processo è decisamente difficile da seguire. Consigliamo di consultare la seguente infografica di Thomas Rocciaper un riferimento visivo e un'analisi approfondita.
L'oggetto condiviso viene compilato nella libreria liblzma e sostituisce il regolare processo di risoluzione del nome della funzione. Durante un qualsiasi caricamento del processo, i nomi delle funzioni vengono risolti in puntatori effettivi alla memoria di processo, che punta al codice binario. La libreria dannosa interferisce con il processo di risoluzione della funzione, quindi potrebbe sostituire il puntatore della funzione per OpenSSH RSA_public_decrypt (Figura 1)
e puntare la funzione ad una propria libreria dannosa, che, secondo la ricerca pubblicata da Filippo Valsorda, estrae un comando dal certificato del client da autenticare (dopo aver verificato che si tratta del criminale) e lo passa alla funzione system() per l'esecuzione, raggiungendo la RCE prima dell'autenticazione.
Figura 1. Il processo di compilazione di liblzma
Per una spiegazione più dettagliata delle parti della backdoor, potete leggere il post di Andres Freundsu openwall.
Il potenziale impatto
Attualmente, sembra che la backdoor venga aggiunta al daemon SSH sul computer vulnerabile, consentendo ad un criminale remoto di eseguire il codice arbitrario. In tal modo, un qualsiasi computer con il pacchetto vulnerabile che rende visibile il daemon SSH su Internet è potenzialmente vulnerabile.
Questa backdoor è diventata praticamente uno dei più importanti facilitatori di intrusioni mai esistiti, eclissando anche la backdoor SolarWinds. I criminali sono riusciti quasi ad ottenere un accesso immediato ai computer Linux con un distro infettato, che include Fedora, Ubuntu e Debian. Quasi.
Solo una persona è riuscita ad evitare che ciò accadesse: Andres Freund. Dopo aver rilevato un problema di latenza di 500 ms introdotta dopo un aggiornamento software, Andres è riuscito a risalire al problema nel pacchetto xz e, alla fine, ad identificare le backdoor.
Ovviamente, tutto ciò crea un sacco di perplessità. Siamo stati fortunati. Se questa backdoor non fosse stata rilevata da un curioso ingegnere, per quanto tempo sarebbe rimasta attiva?
E forse un aspetto ancora più problematico: E se fosse successo prima?
Rilevamento e mitigazione
Controllo delle versioni
La CISA (Cybersecurity and Infrastructure Security Agency) consiglia di effettuare il downgrade ad una versione non compromessa, come la 5.4.6.
Per sapere quale versione di XZ Utils o liblzma viene attualmente utilizzata nei vostri sistemi, potete eseguire la query riportata di seguito in Akamai Guardicore Segmentation Insight, che cercherà le istanze caricate della libreria liblzma (Figura 2).
SELECT DISTINCT path AS liblzma_path
FROM process_memory_map
WHERE LOWER(path) LIKE "%liblzma%"
Figura 2. Esecuzione di query per le istanze caricate del processo liblzma
In alternativa, potete eseguire la query riportata di seguito per individuare il gestore di pacchetti relativo alla versione installata.
SELECT name AS vulnerable_item, 'DEB' AS type, version
FROM deb_packages
WHERE (LOWER(name) LIKE '%xz-utils%' OR LOWER(name) LIKE '%liblzma%')
UNION
SELECT name AS vulnerable_item, 'RPM' AS type, version
FROM rpm_packages
WHERE (LOWER(name) LIKE '%xz-utils%' OR LOWER(name) LIKE '%liblzma%')
Ovviamente, potete anche filtrare i risultati per visualizzare solo le risorse vulnerabili.
SELECT path AS vulnerable_item, "Loaded Library" AS type, '5.6%' AS version
FROM process_memory_map
WHERE LOWER(path) LIKE "%liblzma%5.6%"
SELECT name AS vulnerable_item, 'DEB' AS type, version
FROM deb_packages
WHERE (LOWER(name) LIKE '%xz-utils%' OR LOWER(name) LIKE '%liblzma%')
AND version LIKE '5.6.%'
UNION
SELECT name AS vulnerable_item, 'RPM' AS type, version
FROM rpm_packages
WHERE (LOWER(name) LIKE '%xz-utils%' OR LOWER(name) LIKE '%liblzma%')
AND version LIKE '5.6.%'
Ricerca delle minacce
Poiché la backdoor esegue effettivamente i comandi di sistema e non consente solo l'autenticazione, potrebbe essere possibile rilevare tale comportamento tramite il monitoraggio dei processi.
Di solito, durante l'accesso, viene creata una nuova shell per l'utente che effettua la registrazione e viene eseguito il processo della shell predefinita (come lo script bash). Tuttavia, con questa backdoor, il comando dannoso viene effettivamente eseguito dal processo daemon SSH, sshd, che potrebbe attivare un'anomalia.
Il nostro servizio di ricerca delle minacce, Akamai Hunt, dispone di metodi utili per rilevare tali anomalie, ad esempio, monitorando costantemente uno standard delle attività del processo e dei relativi processi secondari.
Kill switch
Secondo alcune analisi, sembra che la backdoor disponga di una kill switch della variabile di ambiente. L'aggiunta della chiave yolAbejyiejuvnup=Evjtgvsh5okmkAvj alle variabili di ambiente del sistema potrebbe disattivare la backdoor.
Riferimenti