Come probablilmente già sai, xz è stato compromesso. Per i non addetti ai lavori xz è una libreria per la compressione dei dati molto utilizzata sopratutto su Linux.

Il pacchetto è stato usato come entrypoint per l’injection di codice malevolo in sshd, modificandone il flusso di autenticazione. Sembrerebbe che ci sia una code execution direttamente tramite i parametri della chiave.

Questa vulnerabilità, introdotta deliberatamente attraverso una backdoor, è conosciuta come CVE-2024-3094.

Si tratta probabilmente di un’operazione a tutti gli effetti vista la metodologia e la durata (quasi due anni), ma non sono la persona giusta per parlare di attributions, OpSec e Threat Actors. Nella sezione “Risorse” in fondo alla pagina ci sono link che riportano ad analisi più dettagliate.

La situazione non sembra rosea quindi sto provando a scrivere questo blogpost in modo tale da fare un pò di chiarezza.

Non voglio trattare aspetti troppo tecnici della compromissione ma voglio guardare alla issue dalla prospettiva di un Security Engineer, riassumendo cosa è andato storto e quali sono le possibili remediation a questo problema.

1 Timeline

• 2023:

  • Un nuovo maintainer appare sul progetto xz

• 29 Mar 2024:

  • Andres Freund invia un’email alla mailing list oss-security che riguarda una backdoor in xz/liblzma. Stava ottimizzando la sua infrastruttura e si è accorto che ssh era “sospettosamente” lento (parliamo di 400ms di differenza, difficilmente notabili a meno che non si stia facendo micro ottimizzazione). Qualche debug dopo si è accorto che la problmatica di performace era probabilmente causata dal codice della backdoor. L’analisi iniziale è stata fatta con l’aiuto di Florian Weimer.

  • Le distribuzioni impattate (che quindi contenevano il pacchetto xz) hanno cominciato a rilasciare patch di downgrade a una versione precedente

• 30 Mar 2024:

  • GitHub ha bloccato l’accesso al repository e ha sospeso l’account di entrambi i maintainer di xz

  • Un comunicato ufficiale è stato rilasciato dal maintainer del progetto

• 31 Mar 2024:

  • Un potenziale killswitch è stato identificato, prendete questa informazione con le pinze.

2 Componenti impattate

L’estensione di questo breach è ancora poco chiaro di seguito è riportata una (parziale) lista dei componenti che contiengono la versione malevola di xz:

Distribuzioni:

• Arch
• Debian Sid
• Gentoo
• Fedora 40
• Manjaro Testing
• Parabola
• NixOS Unstable
• Slackware
• SUSE Tumbleweed
• Kali Linux

Il pacchetto con la backdoor è inoltre contenuto nei repository dei seguenti package manager:

• Homebrew
• MacPorts
• pkgsrc

Al momento sappiamo che ci sono dei controlli nel codice della backdoor che riguardano specificatamente le istanze di Linux x86_64/amd64 quindi il numero dei target effettivi potrebbe essere ridotto (relativamente) ma la situazione è poco chiara, non raccomanderei di tenere un pacchetto compromesso sul sistema.

3 Considerazioni

3.1 Il comportamento di GitHub

Le ragioni dietro il blocco dei repository di xz è ancora un mistero per me, specialmente sapendo che con il codice disponibile è possibile anche fare ulteriori analisi e avere uno scenario più chiaro della compromissione.

Il blocco dell’accesso ai sortgenti di xz è un fattore che rallenterà l’arrivo delle analisi, che è un male in una situazione time-critical come questa.

3.2 I downgrade

La patch strategy per praticamente tutti è stata di forzare il downgrade dalle versioni 5.6.0-5.6.1 ad una precedente. Qualcuno(homebrew, per esempio), ha forzato il downgrade alla versione 5.4.6.

Questo è interessante perchè sicurametne sappiamo che c’è una backdoor sulle versioni 5.6.0-5.6.1, ma sappiamo anche che l’attaccante ha lavorato sul repository per più di due anni.

La versione 5.4.6, ad esempio, è stata anch’essa compilata dall’attaccante e non dovrebbe essere considerata safe. Ancora una volta, grazie GitHub per aver bloccato l’accesso ai sorgenti e contribuito a far capire ancora meno la situazione.

4 Come si previene questo fenomeno?

Come ho detto all’inizio del post, non voglio scendere troppo in profondità con l’analisi tecnica della backdoor, per due ragioni principali: con l’accesso al codice sorgente bloccato solo un archivio (al momento della scrittura) è disponibile, le informazioni sono incomplete e non vorrei davvero reversare il binario di xz.

Inoltre, e questo è il motivo più importante, persone con più conoscienze di me sul modo di operare dei Threat Actors ci stanno già lavorando. Non appena verranno pubblicati i primi articoli tecnici saranno disponibili nella sezione “Risorse”, in fondo alla pagina

Una cosa che però posso fare qui è mostrare il punto di vista di un Security Engineer sul problema, come avrei mitigato la situazione e quali step sono andati storti.

4.1 Problemi di fiducia

xz è un software mantenuto (fino al 2023) da una singola persona. Successivamente un altro maintainer è arrivato ma sfortunatamente per noi, è la stessa persona che ha inviato la backdoor upstream. Questo ovviamente va in conflitto col fatto che xz sia un pacchetto incredbilimente popolare in tantissime distribuzioni e parte delle dipednenze di numerosi software.

Probabilmente questo è stato visto dall’attaccante come una miniera d’oro dal momento che risultava facile riuscire a farsi affidare il ruolo di maintainer e pubblicare codice malevolo.

Dovendo fare affidamento a codice di terze parti per la supply chain, è necessario avere fiducia in qualcuno a un certo punto. Quando si parla di Supply Chain security, le raccomandazioni sono sempre le stesse: pin degli hash e verifica delle firme.

Questo funziona fino a quando ci troviamo in scenari dove un attaccante ha compromesso la CICD della dipedenza e invia build malevole, un account è stato compromesso etc.

Ma cosa si può fare se, tutto a un tratto, un maintainer fidato si rivela malevolo?

Da utente standard, a meno che tu non voglia (e sia capace) di fare code review a ogni singolo commit di ogni singolo pezzo di software con cui interagisce il tuo sistema operativo: più o meno nulla.

Dall’altro lato, i developers e gli owner dei repsitory dovrebbero aumentare i controlli della loro supply chain includendo metriche più strette al fine di escludere pacchetti con alto rischio.

Una delle cose più ricorrenti che si sentono quando si parla si Open Source e Security sono le persone che credono che, dal momento che il codice sorgente è disponibile, magicamente risulta sicuro.

Uno dei fattori spesso trascurato è l’assunzione che avere accesso al sorgente si traduce automaticamente in un pool maggiore di occhi che cercano problemi e vulnerabilità.

L’efficacia di queste review dipende principamente dal livello di coinvolgimento della community e dall’esperienza delle persone che poi quel codice effettivamente lo leggono, e di solito non è tanto. Molti progetti ricevono pochissima attenzione e solo pochi contribuiscono attivamente ai processi di review. Come risultato, le vulnerabilità (intenzionali o meno) possono passare inosservate per lunghi periodi di tempo, creando un rischio significante per gli utenti.

Ogni volta che una discussione come questa si riapre, mi torna in mente il “Mese di Kali” di InfosectCBR, dove Silvio Cesare ha passato un mese a trovare e pubblicare vulnerabilità nei software contenuti nei repository di Kali Linux.

Di seguito riporto una lista (parziale) di fattori che potrebbero contribuire a ridurre il rischio:

4.2 Statistiche di GitHub

Giusto per essere chiaro fin dall’inizio: No, non si può fare affidamento su queste metriche.

Esiste un mercato sulla compravendita di statistiche di GitHub come stelle, fork etc. Puoi trovare un buon articolo qui: https://dagster.io/blog/fake-stars

4.3 Engagement della community

Valutare sempre la dimensione e l’engagement della community che circonda il progetto.

Una community grande ed attiva può fornire occhi aggiuntivi sulle code review, i bug report etc.

xz aveva letteralmente 2 maintainers e uno dei due è risultato essere l’attore malevolo.

4.4 Fondi e supporto

Condsiderare sempre l’aspetto economico del progetto e da chi sta venendo finanziato. I progetti con dei fondi dedicati tendono ad avere risorse aggiuntive per i security audit e la manutenzione del codice e soprattutto è meno probabile che vengano abbandonati.

4.5 SDLC

Una buona porzione della valutazione dovrebbe concentrarsi sul ciclo si sviluppo del software per assicurarsi che i gate (di sicurezza e qualità più in generale) siano implementati correttamente, le pull request abbiano bisogno di approvazione e ci siano delle pratiche sane che non permettano ad un singolo contributor di inviare codice malevolo senza approvazione.

Inoltre è necessario tenere in cosiderazione che siamo umani e commettiamo errori. Passare una code review non significa automaticamente che il codice sia sicuro, come ho detto prima: non esiste una vera soluzione al problema, solo modi per abbassare la probabilità che le cose brutte accadano.

4.6 Enterprise vs Individual

Questo è un argomento abbastanza controverso perchè ci sono progetti mantenuti da persone individuali che sono ben strutturati. Di solito però, utilizzando cdice prodotto da (grandi) aziende renderà più probabile l’avere delle best practice di sviluppo, avere un continuo stream di fondi per mantenere il progetto in piedi e soprattuto difficilmente una grande azienda metterebbe una backdoor di proposito nel proprio codice. Di nuovo, questo aumenta solo le probabilità, non va preso come concetto assoluto ;)

4.7 Controlli Ricorsivi

Il progetto che stai includendo probabilmente avrà anch’esso delle dipendenze, assicurati che i maintainers applichino a loro volta lo stesso scrutinio sulla loro supply chain per evitare compromissioni indirette.

5 Risorse

• OSS-Security List: https://www.openwall.com/lists/oss-security/2024/03/29/4
• Comprehensive timeline: https://boehs.org/node/everything-i-know-about-the-xz-backdoor
• Compromise link roundup: https://shellsharks.com/xz-compromise-link-roundup
• Obfuscation Analysis: https://gynvael.coldwind.pl/?lang=en&id=782
• Backdoor Analysis: https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504
• Additional info: https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b

Lavorando nel campo, ho visto molte organizzazioni investire una quantita’ significativa di tempo e risorse (che si traduce in persone e soldi), in misure che garantiscono poca se non zero, reale sicurezza.

Ho assistito a organizzazioni che si esibiscono in un eterno clown show nel nome della security.

Questo fenomeno e’ comunemente chiamato “security theatre”.

1 Cosa e’ il Security Theatre

Il security theatre, nella sua forma piu’ semplice, e’ una grande illusione. E’ l’insieme di misure di sicurezza messe in piedi non perche’ prevengano realmente i data breach, ma solo perche’ sulla carta sembrano buoni, tranquillizzano gli stakeholders e fanno sentire tutti come se stessero davvero facendo qualcosa di utile per proteggersi.

Lo senti? Lo senti l’odore? compliance figliolo, non c’e’ nient’altro al mondo che odora cosi’. .

Come esempio, prendiamo il requisito di avere password complesse che devono essere regolarmente cambiate. Questo e’ il classico esempio di security theatre.

Per quanto possa sembrare una buona fa molto poco per prevenire un data breach. E non dimentichiamoci il downside principale: la cosiddetta “password fatigue”, che porta i dipendenti a usare password che sono piu’ facili da ricordare o sempli variazioni di quelle usate in precedenza. Del resto c’e’ un motivo (molti in realta’) se Microsoft, Google ed Apple vogliono abbandonare del tutto le password.

Un altro esempio di security theatre e’ il fatto di implementare sistemi che dovrebbero dare un livello aggiuntivo di sicurezza come firewall, IDS e IP (in realta’ potremmo aprire un dibattito sul fatto che aumentino o diminuiscano la superficie d’attacco), per poi non aggiornali.

2 Cause

Quindi, cosa possono fare le aziende per evitare questo circo infinito? Prima di tutto dovrebbero capire quali sono i veri rischi che corrono e implementare contromisure che li indirizzino in maniera adeguata. Questo deve includere in primo luogo la formazione dei dipendenti su come riconoscere e rispondere ad un attacco.

Dopotutto, la cybersecurity non e’ altro che la Corsa all’Oro 2.0, ci sono moltissimi soldi sul tavolo e tutti ne vogliono una fetta, questo causa pero’ difficolta’ nel trovare genete realmente preparata e se per caso ci si volesse affidare a dei consulenti esterni sarebbe ancora peggio, in quanto si dipenderebbe completamente da un’entita’ esterna per la propria Security Posture.

3 Tirando le somme

In conclusione, il security theatre e’ un problema comune nel mondo dell’IT Security. Per evitare di far parte di questo pessimo show le organizzazioni dovrebbero concentrarsi nell’implementare controlli funzionia, nel testarne regolarmente l’efficacia e nell’avere un piano di risposta comprensivo. A, per favore, smettiamola con le policy inutili.

Tanto tempo che non ci si vede, eh? Sono successe tante cose dall’ultimo post nel 2018 sul vecchio blog.

Sfortunatamente non ho scritto molto, sia per mancanza di tempo sia per l’impossibilita’ di condivider cio’ che ho imparato. Questo post contiene un’introduzione a questo nuovo sito e come funzionera’ d’ora in poi.

Innanzitutto, sono ancora nel campo della security, ma mi sono spostato alla parte di Product Security (di piu’ su questo argomento piu’ avanti ma TL;DR: noia, carriera e opportunita’ di cresita, frustrazione e paura di andare in burnout).

Fortunatamente nel mio attuale lavoro mi vengono concessi tempo e risorse per fare anche vulnerability research quindi occasionalmente postero’ alcune vulnerabilita’ interessanti che ho trovato.

Vorrei inoltre parlare degli aspetti dell’Application Security a applicata al SDLC, vedremo se funzionera'.

1 Il funzionamento di questo blog

Il setup e’ molto semplice, uso hugo per buildare pagine statiche che vengono pubblicate su una GithubPage.

C’e’ una Github Action che builda e deploya le pagine ogni volta che una Pull Request viene approvata sul branch main.

Il tema che uso e’ LoveIt. E’ molto carino e ricco di funzionalita’ ma ha alcuni bug che devono essere fixati; per esempio, se stai leggendo questa pagina in Italiano ti sarai accorto che l’header ha le traduzioni abbastanza fatte a caso.

La localization del tema e’ una feature molto carina ma dover riscrivere ogni volta lo stesso post per ogni linguaggio e’ abbastanza tedioso quindi penso che aggiungero’ il supporto a DeepL.

Infine, il blog ha un nuovo logo:

E’ stato generato da Midjourney e non significa assolutamente nulla!

2 Il futuro

Ho intenzione di cambiare molte cose: prima di tutto vorrei migrare tutti i post del vecchio blog perche’ vorreri mantenere un archivio. Successivamente potro’ cominciare a scrivere nuovi post.

Nonostante il nome sia appsec.space mi piacerebbe parlare di diversi argomenti, spaziando dall’Application security, al Malware Development (a scopo formativo, ovviamente), al mio setup per la produttivita’ a lamentele varie.

Il prossimo post sara’ sul Security Theater quindi, come diceva qualcuno, ci vediamo li.