./cve/CVE-2024-3094/xz.wtf

Premessa

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).

Iniziamo

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.

Fonte: https://www.bugcrowd.com/blog/supply-chain-backdoors-xz-liblzma-cve-2024-3094-and-what-we-currently-know/

Il risultato

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

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:

L’utilizzo degli IFUNC nel processo di creazione, che verranno utilizzati per dirottare le funzioni di risoluzione da parte del malware
L’inclusione un oggetto condiviso offuscato nascosto nei file di test
L’esecuzione di uno script impostato durante il processo di compilazione della libreria che estrae l’oggetto condiviso (non incluso nel repository, solo nelle versioni, ma aggiunto a .gitignore)
La disabilitazione il landlocking, che è una funzionalità di sicurezza per 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.o, che viene aggiunto al processo di compilazione di liblzma

Riporto il post originale di Thomas Roccia con relativa infografica

Fonte: https://infosec.exchange/@fr0gger/112189232773640259

Analisi tecnica dell’attacco

Il payload viene iniettato nel server OpenSSH (processo sshd), poiché liblzma (che contiene il codice dannoso) è una dipendenza di alcune build di OpenSSH
Il payload aggancia la funzione RSA_public_decrypt, una funzione originariamente utilizzata per convalidare le firme RSA
Il codice malevolo aggancia il modulo pubblico RSA passato all’interno della struttura RSA (quarto argomento di RSA_public_decrypt). C’è da tenere presente che questo modulo è completamente controllato dal client SSH che si connette (nel nostro caso parliamo degli aggressori)
Il codice decodifica gli ultimi 240 byte del valore “N” utilizzando il codice a flusso simmetrico ChaCha20, con una chiave di decrittazione hardcoded (vedi sotto) e poiché si tratta di una chiave simmetrica e codificata, questa può essere utilizzata per decrittografare i dump di rete dei tentativi di attacco per comprendere quali comandi sono stati inviati dall’aggressore alla vittima.

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

I dati decrittografati contengono 114 byte di signature di cui viene verificata la validità utilizzando l’algoritmo Ed448, in particolare utilizzando la seguente chiave pubblica Ed448

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.

Il “null-payload” (cioè il comando shell) segue direttamente i byte della firma. Se la firma è stata verificata come valida, il payload viene eseguito come comando di shell passandola direttamente a system()
Se i dati inviati non sono validi (payload o firma non valida), l’implementazione originale di RSA_public_decrypt viene meno. Ciò significa che il rilevamento di macchine vulnerabili sulla rete potrebbe essere impossibile per chiunque oltre agli aggressori.

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”.

Fonti & credits

EOF