Nel mondo della sicurezza informatica, un recente evento ha messo in luce le vulnerabilità nascoste nei software che usiamo ogni giorno. Andres Freund, sviluppatore presso Microsoft, ha scoperto una backdoor insidiosa nel codice di liblzma, un elemento chiave del pacchetto xz, sollevando questioni urgenti sulla sicurezza dei progetti open-source. Questa scoperta, originata da anomalie nelle prestazioni di sistema, ha portato alla luce un sofisticato tentativo di compromissione che rischia di avere ripercussioni su vasta scala, mostrando come la backdoor in informatica rappresenti una minaccia costante.
Ma partiamo dall’inizio, per capire bene come si sono svolti e fatti e cosa ci ha insegnato questa storia.
La scoperta della backdoor
Il 29 marzo 2024 Andres Freund (uno sviluppatore Microsoft) ha creato un thread in oss-security Openwall (una nota mailing list per la sicurezza open-source) che inizia così:
Salve, Dopo aver osservato alcuni strani sintomi relativi a liblzma (parte del pacchetto xz) su installazioni Debian sid nelle ultime settimane, (accessi con ssh che richiedono molta CPU, errori di valgrind) ho trovato la risposta:
Il repository upstream xz e i tarball xz sono stati “backdoored”.
All’inizio ho pensato che si trattasse di una compromissione del pacchetto di debian, ma si è scoperto che si trattava di upstream.
In pratica, Andres ha notato che il processo di login ssh richiedeva circa 500 ms in più del solito. Ha poi iniziato ad analizzare la causa principale del problema e ha scoperto che xz (una popolare libreria per la compressione dei dati lossless ampiamente utilizzata nei sistemi tipo unix) era stata compromessa da un aggressore che vi aveva introdotto una backdoor.
Backdoor in informatica: come si è sviluppato l’attacco
Ciò che è davvero interessante (e spaventoso allo stesso tempo) è il modo in cui il malintenzionato ha perpetrato l’attacco.
Il codice xz (ora disabilitato) era ospitato su GitHub ed è completamente open source (quindi chiunque può contribuire e il manutentore può accettare o rifiutare le modifiche). Tuttavia, l’aggressore (il cui nome è Jia Tan) ha iniziato a fare commit su questo repository dal febbraio 2022 (è possibile consultare la sua attività su GitHub, poiché l’account è ancora presente). Lentamente si è guadagnato la fiducia e la credibilità del manutentore del progetto, fino al 9 marzo 2024, quando ha utilizzato una tecnica intelligente per nascondere una backdoor utilizzando due file di test e diverse fasi di offuscamento del payload. Inoltre, una parte della backdoor (che viene eseguita in più fasi) era presente solo nei tarball delle versioni interessate (5.6.0 e 5.6.1) e non era inclusa nella versione di controllo della sorgente (quindi era più difficile trovarla).
L’immagine seguente riassume ciò che è accaduto dal 2021 (creazione dell’account GitHub) fino all’impacchettamento finale della backdoor all’interno di xz/libzma (i crediti vanno a Thomas Roccia per questa fantastica infografica):
Impatto
L’aggressore può sostanzialmente eseguire qualsiasi comando arbitrario (RCE – Remote Code Execution) sui sistemi interessati che hanno un daemon sshd in esecuzione, e quindi esposto. Solo l’aggressore può eseguire i comandi perché il payload deve essere firmato con una chiave Ed448 nota solo all’aggressore. Maggiori dettagli qui.
Fortunatamente, solo poche distribuzioni Linux sono state colpite di default (soprattutto quelle con rami instabili/testing/sviluppo o le distribuzioni rolling-release) tra cui Fedora (40,41), Debian (testing, unstable, experimental) e Arch Linux.
Al momento sappiamo che il payload funziona in alcune condizioni specifiche:
- deve essere in esecuzione un daemon sshd
- sshd deve essere patchato per supportare systemd-notify (che in realtà usa xz/liblzma come dependency)
Sono possibili altri scenari di attacco e i reverse engineers stanno ancora lavorando per fornire ulteriori informazioni.
Se si vuole verificare se si sta utilizzando la libreria xz backdoored, eseguire il seguente comando:
strings `which xz` | grep ‘5\.6\.[01]‘
Un sistema vulnerabile mostrerebbe qualcosa come:
xz (XZ Utils) 5.6.1
e si dovrebbe immediatamente eseguire il downgrade alla versione 5.4.6.
Se non si ottiene alcun risultato, si è al sicuro.
Maggiori informazioni qui.
Riflessioni finali
Questo incidente di sicurezza ci offre l’opportunità di riflettere su alcune cose importanti.
- Gli attacchi stanno diventando sempre più sofisticati. Il modo in cui l’attore malintenzionato è riuscito a guadagnare reputazione e credibilità è stato pazzesco. Ha agito con pazienza e ha sfruttato tecniche di social engineering per spingere il manutentore a dargli il pieno controllo della repository. Ha anche creato account falsi per spingere il pacchetto xz-utils infetto a essere incluso in debian (come qui). Inoltre, ha usato tecniche avanzate e piuttosto intelligenti per nascondere e offuscare il payload. Personalmente ritengo che, sebbene i meccanismi di creazione del software siano essenziali, la loro complessità possa inavvertitamente creare opportunità di sfruttamento di vettori di attacco precedentemente sconosciuti o meno praticabili.
- Cosa significa mantenere un progetto open-source? Il manutentore originale del progetto (Lasse Collin, che ha anche creato questa pagina per fornire aggiornamenti sull’incidente) è stato completamente sopraffatto dalle richieste provenienti da chi utilizzava la libreria xz e si lamentava della lentezza del rilascio di nuove funzionalità. In questo thread Lasse ha anche ammesso di soffrire di “problemi di salute mentale a lungo termine” e che stava pensando di dare a Jia Tan (il ragazzo che ha introdotto la backdoor) un ruolo più importante nel progetto xz. Probabilmente tutti noi abbiamo bisogno di capire che tipo di sforzo è necessario per mantenere un progetto open-source, soprattutto considerando che la maggior parte di essi non riceve alcun compenso finanziario nonostante siano utilizzati quotidianamente da migliaia di aziende multimilionarie.
- Possiamo fidarci ciecamente dell’open-source? Sappiamo tutti che il software ha dei bug e che i bug possono creare problemi di sicurezza, introdotti dagli errori degli sviluppatori. Questo è normale e per lo più sappiamo come affrontare il problema (ad esempio adottando strumenti di analisi della composizione del software e impedendo l’importazione di dependency vulnerabili di terze parti nel nostro ecosistema applicativo non appena viene scoperta una vulnerabilità). Tuttavia, questa volta è diverso: come possiamo fidarci dei collaboratori di un progetto open source? Mentre molti collaboratori mirano sinceramente a migliorare il software e a portare benefici alla comunità, altri potrebbero avere secondi fini, come sfruttare le vulnerabilità per tornaconto (?) personale. Considerando che questo incidente di sicurezza è stato identificato per caso, quanti altri potrebbero esistere che sono ancora lì, non ancora identificati?