• Sicurezza
• 9 Aprile 2024

Il numero identificativo è CVE-2024-3094 ed il suo valore di gravità è un sonoro 10, il massimo, consentendo la possibilità di eseguire codice da remoto. Un serio problema all’interno di una libreria open source molto utilizzata. In questa storia gli aspetti interessanti sono molteplici, da come è stata scoperta a come è stata deliberatamente inserita all’interno della libreria XZ, lasciando tanti spunti di discussione interessanti che sarebbe opportuno approfondire per capire quanto, come spesso scriviamo in queste pagine, i dettagli fanno la differenza ed il fattore umano resta, purtroppo, l’arma più grande da utilizzare per un attaccante.

Cos’è XZ Utils ed a cosa serve

XZ Utils è una libreria open source utilizzata per eseguire azioni di compressione/decompressione di files con l’utilizzo dell’algoritmo LZMA. Viene utilizzata in ambienti Unix/Linux, ad esempio, per rilasciare le cosiddette “tarball“, ovvero uno dei modi più comuni di rilasciare software open source, o ancora per le kernel images ed altro. Solitamente su Linux e Mac è preinstallata, quindi già pronta all’utilizzo.

Cosa è successo?

Il 29 marzo 2024, Andres Freund, ingegnere Microsoft scrive un post su Mastodon relativamente ad attività di test che stava eseguendo.

Figura 1 – Post di Andres Freund su Mastodon

In pratica, nota una piccola latenza nelle connessioni tramite protocollo SSH ed un utilizzo della CPU piuttosto anomalo per la tipologia di attività che sta svolgendo e decide di approfondire. Analizzando tutte le componenti si rende conto che il problema è nella libreria XZ/LZMA: qualcuno ha inserito una backdoor deliberatamente.

Qualche anno prima, nel 2021, viene creato un account su Github con username Jia Tan (JiaT75). Inizia a collaborare con Lasse Collin, mantainer del progetto XZ, aiutandolo in molte attività. Da due account “Jigar Kumar” e “Dennis Ens“, successivamente ritenuti piuttosto dubbi dalla comunità, iniziano ad arrivare tutta una serie di richieste di nuove features e/o segnalazioni di problemi. In questo scambio si denota come la fatica di Lasse nel seguire il progetto inizi ad essere tanta e di quanto, solitamente, può essere stressante manutenere librerie largamente utilizzate. Decide, quindi, di rendere pubbliche le informazioni su Jia Tan e su una collaborazione già in essere che probabilmente aumenterà in futuro. Con quella che sembra un’azione di Social Engineering molto articolata, l’account JiaT75 riesce a farsi inserire come co-mantainter della libreria. Akamai afferma “The threat actor started contributing to the XZ project almost two years ago, slowly building credibility until they were given maintainer responsibilities” ed è proprio questo il punto: l’organizzazione, i lunghi tempi lasciano intendere la grande organizzazione ed orchestrazione che c’è stata dietro questa vicenda, che ricorda le azioni di un threat actor sponsorizzato da uno Stato, non un singolo individuo.

Nel 2023 Jia Tan inserisce diverse modifiche e a febbraio 2024 rilascia la versione 5.6.0, la prima a contenere la backdoor.

Dettagli tecnici

Per capire meglio i tecnicismi dietro questa vicenda possiamo consultare lo schema prodotto da Thomas Roccia che riassume quanto accaduto.

Figura 2 – XZ Outbreak by Thomas Roccia

Riuscire ad inserire codice malevolo in un repository pubblico non è cosa semplice: chiunque, proprio per i paradigmi dell’open source, deve poter leggere il codice. L’obbiettivo di JiaT75 è quella di riuscire ad utilizzare, tramite il protocollo SSH, un oggetto che fosse in grado di eseguire comandi arbitrari. Quindi, utilizzarlo non per l’accesso tradizionale, dove sono necessarie utenze o certificati ma per poter effettuare RCE (Remote Command Execution) grazie all’utilizzo di una backdoor. Questo è tutt’altro che semplice.

Il primo passo è stato quello di dover nascondere il codice. Per farlo ha utilizzato dei pacchetti compilati ma che, per la natura open del repository, se inseriti nell’alberatura standard del progetto avrebbero insospettito chiunque. La scelta di utilizzare la libreria XZ, ovvero una libreria di compressione, rende ancora di più l’idea sulla quale si basa questa vicenda. Ogni sviluppatore sa che per fare bene il proprio lavoro, prima di un rilascio ufficiale, è necessario creare i cosiddetti Unit Test, ovvero quei processi in cui si esegue la verifica anche della più piccola porzione di codice per garantirne qualità. Solitamente sono inseriti in una posizione specifica dell’alberatura di progetto e, soprattutto, eseguiti in maniera automatica. Quale può essere il risultato di un test su una libreria di compressione? Ovviamente un pacchetto compresso, un file binario. Sfruttando questo concetto, è stato inserito un oggetto binario in una posizione specifica e che non era un risultato di un test ma il codice appositamente scritto e compilato per altri scopi, riuscendo nell’intento di non destare sospetti.

Per riuscire ad utilizzare quanto fatto, JiaT75 ha effettuato delle modifiche ad alcune funzioni presenti all’interno della libreria ma che, come spesso accade in questi casi, hanno creato degli errori di regressione visti anche da software come Valgrind. Dettaglio, tra l’altro, ricordato nel primo post di Andres Freund su Mastodon.

Semplificando, il software Valgrind viene usato, tra le varie cose, per fare analisi del codice alla ricerca di problemi o vulnerabilità. In un progetto strutturato e largamente diffuso solitamente è implicito l’utilizzo di strumenti di analisi di questo tipo. Per riuscire a superare questo scoglio, ovvero come evitare l’esecuzione di un controllo eseguito con Valgrind e la diffusione di un report con i relativi errori, Jia Tan è riuscito con delle semplici scuse a distogliere l’attenzione semplicemente affermando qualcosa che suona più o meno in questo modo: “Sto ancora lavorando su questa parte del progetto, gli errori saranno risolti successivamente” facendo leva sulla reputazione di co-maintainer acquisita. Ennesima prova di quanto le attività di Social Engineering ed il fattore umano risultano centrali durante gli attacchi.

Figura 3 – Commit effettuato da JiaT75 e descrizione per evitare il fuzzing di questa porzione di codice

I mantainer sono coloro che possono eseguire la build del progetto facendola diventare “release“, in questo caso con numero di versione 5.6.0 e 5.6.1. Se si apre il pacchetto rilasciato è possibile notare che lo script di build di quella porzione di codice, della backdoor, è diverso da quello inserito all’interno del repository pubblico su Github. In questa condizione, se si prende il pacchetto rilasciato e lo si utilizza per la build della libreria con estensione .deb la backdoor viene effettivamente compilata all’interno del pacchetto risultante, quindi solo nell’archivio di distribuzione.

Riassumendo con qualche tecnicismo in più, la backdoor è composta da diverse parti introdotte nel tempo:

• Utilizzo/modifica della funzione IFUNC nella fase di build;
  
• Inclusione di pacchetti offuscati nella sezione dell’alberatura dedicata ai test;
  
• Esecuzione di uno script durante il processo di build della libreria non incluso nell’alberatura generale ma solo in .gitignore;
  
• Introduzione di una funzione che disabilita il landlocking, ovvero quel processo di sicurezza che limita i privilegi di un processo.
  

Conseguentemente, nella fase di esecuzione:

• Durante la fase di build viene eseguito lo script build-to-host.m4 che decodifica il file bad-3-corrupt_Lzma2.xz in uno script bash;
  
• Lo script bash esegue un secondo processo di decodifica su un altro file good_large_compressed.lz trasformandolo in un ulteriore script bash;
  
• Quest’ultimo recupera il file liblzma_la-crc64-fast.o e lo aggiunge al processo di compilazione della libreria liblzma;
  

A questo punto, utilizzando SSH ed una chiave ben specifica non avviene la verifica dell’utente che sta tentando di connettersi ma è possibile eseguire arbitrariamente dei comandi che la backdoor riversa direttamente in memoria.

Essendo un processo così complesso è difficile immaginare che dietro questo enorme lavoro ci sia un solo soggetto, in grado di continuare le attività per più di due anni ed arrivare a questo tipo di risultato. Per coloro maggiormente interessati ai dettagli, è possibile consultare una storyline appositamente redatta.

Chi è affetto da questa vulnerabilità?

Varie distribuzioni Linux e MacOS sono vulnerabili se hanno:

• Una distribuzione basata su GLIBC per poter utilizzare l’incriminata IFUNC;
  
• Le versioni 5.6.0 o 5.6.1 delle librerie XZ o LIBLZMA installate tenendo in considerazione che xz-utils le include entrambe.
  

Al momento solo la combinazione di systemd e OpenSSH sembra essere impattata.

Le distribuzioni Linux, invece, che sono state impattate sono varie tra cui Debian, Fedora, openSUSE e Kali Linux.

Raccomandazioni

Nella maggior parte dei casi, per risolvere il problema è sufficiente un update. Nel caso in cui l’aggiornamento non fosse disponibile è opportuno procedere ad un downgrade di xz-utils alla prima versione stabile non compromessa (5.4.6) o smettere di utilizzarle.

Per riuscire a determinare se si è vulnerabili è possibile eseguire il seguente comando:

Per verificare la presenza della versione di XZ compromessa.

Dopo aver effettuato il downgrade e riavviato il sistema, se non è possibile effettuare l’upgrade esiste un workaround che è possibile applicare: all’interno della backdoor è presente un “kill switch” ovvero un meccanismo che disabilita le funzionalità della stessa se una specifica stringa è presente all’interno delle variabili d’ambiente del sistema. Per applicare questo metodo è sufficiente aprire il file /etc/environment, aggiungere la seguente stringa

yolAbejyiejuvnup=Evjtgvsh5okmkAvj

e riavviare SSH e systemd.

Considerazioni

Sono molte le considerazioni necessarie dopo aver analizzato questa storia. La supply chain resta un tema caldo poiché già con altre vicende, ad esempio con il caso SolarWinds, ci siamo resi conto della difficoltà di proteggersi quando un fornitore di tecnologia subisce un attacco simile. Nel mondo open source, però, non era mai capitato qualcosa del genere. In realtà, abbiamo notato come la community si sia subito attivata nell’analizzare quanto accaduto, soprattutto considerando le difficoltà legate ad un processo del genere e questo è estremamente positivo. Fortunatamente, la backdoor non è mai stata inserita nelle distribuzioni “Stable“; quindi, non è arrivata su sistemi in produzione ma affidarsi alla fortuna è un comportamento non sempre remunerativo.

Determinate vulnerabilità vengono scoperte un po’ per caso: in questa storia c’è un professionista a cui davano particolarmente fastidio pochi millisecondi di latenza nell’effettuare una connessione. Quel fastidio si è trasformato in una ricerca strutturata di dettagli ed informazioni, fino ad una scoperta e relativa segnalazione pubblica. Quanti possibili altri casi analoghi ci sono? Quanti sono i progetti open che vengono gestiti anche solo da una persona ma che, all’atto pratico, vengono distribuiti a livello globale? Le persone che li gestiscono lo fanno nel tempo libero, senza essere retribuiti, solo per passione e, talvolta, anche stressati a causa dell’estrema diffusione del progetto e dalle relative richieste di fix/features. Non avremo sempre la fortuna di avere qualcuno che, infastidito da quello che molti definirebbero una perdita di tempo, nota un dettaglio e lo approfondisce in maniera così articolata: senza di lui questa vulnerabilità potrebbe ancora non essere stata scoperta e, soprattutto, utilizzata con conseguenze inimmaginabili.

Conclusioni

Non ci stancheremo mai di far capire quanto i dettagli fanno la differenza. Dobbiamo capire come reagire in questi casi. Un Incident Response Team deve avere le corrette procedure per ricostruire e rimediare, i corretti strumenti di analisi e di backup per essere davvero resilienti. Tutto questo è necessario proprio per capire cosa fare quando un evento del genere accade perché, come diceva John Chambers, “There are two types of companies: those that have been hacked, and those who don’t know they have been hacked”.

Questo è stato uno degli attacchi più sofisticati degli ultimi tempi. Nonostante qualche speculazione, non è noto il paese di provenienza del gruppo che si cela dietro Jia Tan JiaT75. Quello che, invece, è chiaro sono gli impatti di un attacco del genere, sia a livello personale/aziendale, sia a livello statale o mondiale.

Stay tuned!