diff --git a/it/index.html b/it/index.html index 83f35f4..cab6209 100644 --- a/it/index.html +++ b/it/index.html @@ -15,7 +15,7 @@ Italiano
/images/logo.png

A space where I talk about Application Security & other stuff

Opinions are my own

/posts/xz-backdoor/xz.png

La backdoor di xz dalla prospettiva di un Security Engineer

 pubblicato su

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

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

Leggi di più
 Backdoor, CVE-2024-3094, Xz, Liblzma, Supply-Chain, Security-Engineering
\ No newline at end of file diff --git a/it/index.json b/it/index.json index a2b0a02..c89d25c 100644 --- a/it/index.json +++ b/it/index.json @@ -1 +1 @@ -[{"categories":null,"content":"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 autenticatione. Questa vulnerabilità, introdotta deliberatamente attraverso una backdoor, è conosciuta come CVE-2024-3094. Note La situazione si sta ancora evolvendo, maggiori dettagli emergeranno nel prossimo futuro e aggiornerò il post di conseguenza. 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. ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:0:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#"},{"categories":null,"content":" 1 Timeline Note Controlla la sezione Risorse per i link ad una timeline più dettagliata 2023: Un nuovo maintainer appare sul progetto xz A new maintainer shows up in the xz project 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 ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:1:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#timeline"},{"categories":null,"content":" 2 Componenti impattateL’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 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. ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:2:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#componenti-impattate"},{"categories":null,"content":" 3 Considerazioni","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:3:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#considerazioni"},{"categories":null,"content":" 3.1 Il comportamento di GitHubLe 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. ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:3:1","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#il-comportamento-di-github"},{"categories":null,"content":" 3.2 I downgradeLa 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. ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:3:2","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#i-downgrade"},{"categories":null,"content":" 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. Note TL;DR: non esiste una reale soluzione al problema ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:4:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#come-si-previene-questo-fenomeno"},{"categories":null,"content":" 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: ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:4:1","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#problemi-di-fiducia"},{"categories":null,"content":" 4.2 Statistiche di GitHubGiusto 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 ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:4:2","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#statistiche-di-github"},{"categories":null,"content":" 4.3 Engagement della communityValutare 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. ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:4:3","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#engagement-della-community"},{"categories":null,"content":" 4.4 Fondi e supportoCondsiderare 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. Tip Ricorda: si vuole fare affidamento su quel codice per l’intera settimana, non solo durante il tempo libero del maintainer. I progetti con un buon supporto finanziario è molto più probabile divengano lavori a tempo pieno che solo hobby da portare avanti sporadicamente. ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:4:4","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#fondi-e-supporto"},{"categories":null,"content":" 4.5 SDLCUna 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. ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:4:5","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#sdlc"},{"categories":null,"content":" 4.6 Enterprise vs IndividualQuesto è 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 ;) ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:4:6","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#enterprise-vs-individual"},{"categories":null,"content":" 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\u0026id=782 ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:5:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#risorse"},{"categories":["general-knowledge"],"content":"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”. ","date":"2023-02-13","objectID":"/it/posts/security-theatre/:0:0","series":null,"tags":["security theatre","infosec","rants"],"title":"Security Theatre? Direi quasi Security Circus","uri":"/it/posts/security-theatre/#"},{"categories":["general-knowledge"],"content":" 1 Cosa e’ il Security TheatreIl 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. sistema la tua password policy 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. ","date":"2023-02-13","objectID":"/it/posts/security-theatre/:1:0","series":null,"tags":["security theatre","infosec","rants"],"title":"Security Theatre? Direi quasi Security Circus","uri":"/it/posts/security-theatre/#cosa-e-il-security-theatre"},{"categories":["general-knowledge"],"content":" 2 CauseQuindi, 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. ","date":"2023-02-13","objectID":"/it/posts/security-theatre/:2:0","series":null,"tags":["security theatre","infosec","rants"],"title":"Security Theatre? Direi quasi Security Circus","uri":"/it/posts/security-theatre/#cause"},{"categories":["general-knowledge"],"content":" 3 Tirando le sommeIn 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. Tip Qui puoi trovare un articolo di Phil Venables, CISO di Google, sulla Cerimonial Security e i Cargo Cults. ","date":"2023-02-13","objectID":"/it/posts/security-theatre/:3:0","series":null,"tags":["security theatre","infosec","rants"],"title":"Security Theatre? Direi quasi Security Circus","uri":"/it/posts/security-theatre/#tirando-le-somme"},{"categories":null,"content":"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'. ","date":"2023-02-06","objectID":"/it/posts/long-time-no-see/:0:0","series":null,"tags":["updates"],"title":"Tanto tempo che non ci si vede","uri":"/it/posts/long-time-no-see/#"},{"categories":null,"content":" 1 Il funzionamento di questo blogIl 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. Un grafico che rappresenta il flusso logico dietro il sistema di deployment del blog 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: appsec.space logo E’ stato generato da Midjourney e non significa assolutamente nulla! ","date":"2023-02-06","objectID":"/it/posts/long-time-no-see/:1:0","series":null,"tags":["updates"],"title":"Tanto tempo che non ci si vede","uri":"/it/posts/long-time-no-see/#il-funzionamento-di-questo-blog"},{"categories":null,"content":" 2 Il futuroHo 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. Note Se il vecchio blog risponde con un redirect a quello nuovo significa che la migrazione e’ stata completata. 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. ","date":"2023-02-06","objectID":"/it/posts/long-time-no-see/:2:0","series":null,"tags":["updates"],"title":"Tanto tempo che non ci si vede","uri":"/it/posts/long-time-no-see/#il-futuro"}] \ No newline at end of file +[{"categories":null,"content":"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. Questa vulnerabilità, introdotta deliberatamente attraverso una backdoor, è conosciuta come CVE-2024-3094. Note La situazione si sta ancora evolvendo, maggiori dettagli emergeranno nel prossimo futuro e aggiornerò il post di conseguenza. 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. ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:0:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#"},{"categories":null,"content":" 1 Timeline Note Controlla la sezione Risorse per i link ad una timeline più dettagliata 2023: Un nuovo maintainer appare sul progetto xz A new maintainer shows up in the xz project 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 ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:1:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#timeline"},{"categories":null,"content":" 2 Componenti impattateL’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 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. ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:2:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#componenti-impattate"},{"categories":null,"content":" 3 Considerazioni","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:3:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#considerazioni"},{"categories":null,"content":" 3.1 Il comportamento di GitHubLe 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. ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:3:1","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#il-comportamento-di-github"},{"categories":null,"content":" 3.2 I downgradeLa 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. ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:3:2","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#i-downgrade"},{"categories":null,"content":" 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. Note TL;DR: non esiste una reale soluzione al problema ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:4:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#come-si-previene-questo-fenomeno"},{"categories":null,"content":" 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: ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:4:1","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#problemi-di-fiducia"},{"categories":null,"content":" 4.2 Statistiche di GitHubGiusto 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 ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:4:2","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#statistiche-di-github"},{"categories":null,"content":" 4.3 Engagement della communityValutare 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. ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:4:3","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#engagement-della-community"},{"categories":null,"content":" 4.4 Fondi e supportoCondsiderare 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. Tip Ricorda: si vuole fare affidamento su quel codice per l’intera settimana, non solo durante il tempo libero del maintainer. I progetti con un buon supporto finanziario è molto più probabile divengano lavori a tempo pieno che solo hobby da portare avanti sporadicamente. ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:4:4","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#fondi-e-supporto"},{"categories":null,"content":" 4.5 SDLCUna 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. ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:4:5","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#sdlc"},{"categories":null,"content":" 4.6 Enterprise vs IndividualQuesto è 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 ;) ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:4:6","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#enterprise-vs-individual"},{"categories":null,"content":" 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\u0026id=782 ","date":"2024-03-30","objectID":"/it/posts/xz-backdoor/:5:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"La backdoor di xz dalla prospettiva di un Security Engineer","uri":"/it/posts/xz-backdoor/#risorse"},{"categories":["general-knowledge"],"content":"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”. ","date":"2023-02-13","objectID":"/it/posts/security-theatre/:0:0","series":null,"tags":["security theatre","infosec","rants"],"title":"Security Theatre? Direi quasi Security Circus","uri":"/it/posts/security-theatre/#"},{"categories":["general-knowledge"],"content":" 1 Cosa e’ il Security TheatreIl 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. sistema la tua password policy 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. ","date":"2023-02-13","objectID":"/it/posts/security-theatre/:1:0","series":null,"tags":["security theatre","infosec","rants"],"title":"Security Theatre? Direi quasi Security Circus","uri":"/it/posts/security-theatre/#cosa-e-il-security-theatre"},{"categories":["general-knowledge"],"content":" 2 CauseQuindi, 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. ","date":"2023-02-13","objectID":"/it/posts/security-theatre/:2:0","series":null,"tags":["security theatre","infosec","rants"],"title":"Security Theatre? Direi quasi Security Circus","uri":"/it/posts/security-theatre/#cause"},{"categories":["general-knowledge"],"content":" 3 Tirando le sommeIn 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. Tip Qui puoi trovare un articolo di Phil Venables, CISO di Google, sulla Cerimonial Security e i Cargo Cults. ","date":"2023-02-13","objectID":"/it/posts/security-theatre/:3:0","series":null,"tags":["security theatre","infosec","rants"],"title":"Security Theatre? Direi quasi Security Circus","uri":"/it/posts/security-theatre/#tirando-le-somme"},{"categories":null,"content":"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'. ","date":"2023-02-06","objectID":"/it/posts/long-time-no-see/:0:0","series":null,"tags":["updates"],"title":"Tanto tempo che non ci si vede","uri":"/it/posts/long-time-no-see/#"},{"categories":null,"content":" 1 Il funzionamento di questo blogIl 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. Un grafico che rappresenta il flusso logico dietro il sistema di deployment del blog 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: appsec.space logo E’ stato generato da Midjourney e non significa assolutamente nulla! ","date":"2023-02-06","objectID":"/it/posts/long-time-no-see/:1:0","series":null,"tags":["updates"],"title":"Tanto tempo che non ci si vede","uri":"/it/posts/long-time-no-see/#il-funzionamento-di-questo-blog"},{"categories":null,"content":" 2 Il futuroHo 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. Note Se il vecchio blog risponde con un redirect a quello nuovo significa che la migrazione e’ stata completata. 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. ","date":"2023-02-06","objectID":"/it/posts/long-time-no-see/:2:0","series":null,"tags":["updates"],"title":"Tanto tempo che non ci si vede","uri":"/it/posts/long-time-no-see/#il-futuro"}] \ No newline at end of file diff --git a/it/index.xml b/it/index.xml index 7848822..144da29 100644 --- a/it/index.xml +++ b/it/index.xml @@ -2,7 +2,7 @@

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

+

Il pacchetto è stato usato come entrypoint per l’injection di codice malevolo in sshd, modificandone il flusso di autenticazione.

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

diff --git a/it/posts/index.xml b/it/posts/index.xml index a423c83..fbf1aad 100644 --- a/it/posts/index.xml +++ b/it/posts/index.xml @@ -2,7 +2,7 @@

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

+

Il pacchetto è stato usato come entrypoint per l’injection di codice malevolo in sshd, modificandone il flusso di autenticazione.

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

diff --git a/it/posts/xz-backdoor/index.html b/it/posts/xz-backdoor/index.html index abbbed2..292ed19 100644 --- a/it/posts/xz-backdoor/index.html +++ b/it/posts/xz-backdoor/index.html @@ -1,11 +1,11 @@ La backdoor di xz dalla prospettiva di un Security Engineer - appsec & stuff
Post Categorie About me Italiano +Il pacchetto è stato usato come entrypoint per l’injection di codice malevolo in sshd, modificandone il flusso di autenticazione. +Questa vulnerabilità, introdotta deliberatamente attraverso una backdoor, è conosciuta come CVE-2024-3094.">
Post Categorie About me Italiano @@ -21,7 +21,7 @@ Italiano

La backdoor di xz dalla prospettiva di un Security Engineer

L'ennesimo attacco alla supply chain

     1514 parole  8 minuti 
/posts/xz-backdoor/xz.png

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

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

Note
La situazione si sta ancora evolvendo, maggiori dettagli emergeranno nel prossimo futuro e aggiornerò il post di conseguenza.

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

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

Note
La situazione si sta ancora evolvendo, maggiori dettagli emergeranno nel prossimo futuro e aggiornerò il post di conseguenza.

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.

Note
Controlla la sezione Risorse per i link ad una timeline più dettagliata

  • 2023:

    • Un nuovo maintainer appare sul progetto xz
    • A new maintainer shows up in the xz project

  • 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

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

Distribuzioni:

Il pacchetto con la backdoor è inoltre contenuto nei 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.

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.

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. @@ -29,6 +29,6 @@ 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.

Note
TL;DR: non esiste una reale soluzione al problema

https://imgs.xkcd.com/comics/dependency_2x.png

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:

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

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.

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.

Tip
Ricorda: si vuole fare affidamento su quel codice per l’intera settimana, non solo durante il tempo libero del maintainer. I progetti con un buon supporto finanziario è molto più probabile divengano lavori a tempo pieno che solo hobby da portare avanti sporadicamente.

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.

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

Aggiornato il 2024-03-31  -4b37ca1
Leggi Markdown
 Backdoor, CVE-2024-3094, Xz, Liblzma, Supply-Chain, Security-Engineering
Indietro | Home
Aggiornato il 2024-03-31  +df2c2ba
Leggi Markdown
 Backdoor, CVE-2024-3094, Xz, Liblzma, Supply-Chain, Security-Engineering
Indietro | Home
\ No newline at end of file diff --git a/it/posts/xz-backdoor/index.md b/it/posts/xz-backdoor/index.md index 9055216..527868a 100644 --- a/it/posts/xz-backdoor/index.md +++ b/it/posts/xz-backdoor/index.md @@ -4,7 +4,7 @@ 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 autenticatione. +Il pacchetto è stato usato come entrypoint per l'injection di codice malevolo in `sshd`, modificandone il flusso di autenticazione. Questa vulnerabilità, introdotta deliberatamente attraverso una backdoor, è conosciuta come [CVE-2024-3094](https://nvd.nist.gov/vuln/detail/CVE-2024-3094). diff --git a/it/sitemap.xml b/it/sitemap.xml index a60a6e0..c583dcd 100644 --- a/it/sitemap.xml +++ b/it/sitemap.xml @@ -1 +1 @@ -https://appsec.space/it/2024-03-31T10:22:20+02:00weekly1https://appsec.space/it/tags/backdoor/2024-03-31T10:22:20+02:00weekly1https://appsec.space/it/tags/cve-2024-3094/2024-03-31T10:22:20+02:00weekly1https://appsec.space/it/posts/xz-backdoor/2024-03-31T10:22:20+02:00weekly1https://appsec.space/it/tags/liblzma/2024-03-31T10:22:20+02:00weekly1https://appsec.space/it/posts/2024-03-31T10:22:20+02:00weekly1https://appsec.space/it/tags/security-engineering/2024-03-31T10:22:20+02:00weekly1https://appsec.space/it/tags/supply-chain/2024-03-31T10:22:20+02:00weekly1https://appsec.space/it/tags/2024-03-31T10:22:20+02:00weekly1https://appsec.space/it/tags/xz/2024-03-31T10:22:20+02:00weekly1https://appsec.space/it/categories/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/categories/general-knowledge/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/tags/infosec/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/tags/rants/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/tags/security-theatre/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/posts/security-theatre/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/posts/long-time-no-see/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/tags/updates/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/about/2023-03-21T22:11:59+01:00weekly0.5 \ No newline at end of file +https://appsec.space/it/2024-03-31T10:25:51+02:00weekly1https://appsec.space/it/tags/backdoor/2024-03-31T10:25:51+02:00weekly1https://appsec.space/it/tags/cve-2024-3094/2024-03-31T10:25:51+02:00weekly1https://appsec.space/it/posts/xz-backdoor/2024-03-31T10:25:51+02:00weekly1https://appsec.space/it/tags/liblzma/2024-03-31T10:25:51+02:00weekly1https://appsec.space/it/posts/2024-03-31T10:25:51+02:00weekly1https://appsec.space/it/tags/security-engineering/2024-03-31T10:25:51+02:00weekly1https://appsec.space/it/tags/supply-chain/2024-03-31T10:25:51+02:00weekly1https://appsec.space/it/tags/2024-03-31T10:25:51+02:00weekly1https://appsec.space/it/tags/xz/2024-03-31T10:25:51+02:00weekly1https://appsec.space/it/categories/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/categories/general-knowledge/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/tags/infosec/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/tags/rants/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/tags/security-theatre/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/posts/security-theatre/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/posts/long-time-no-see/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/tags/updates/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/about/2023-03-21T22:11:59+01:00weekly0.5 \ No newline at end of file diff --git a/it/tags/backdoor/index.xml b/it/tags/backdoor/index.xml index 0c94e27..12b7c9d 100644 --- a/it/tags/backdoor/index.xml +++ b/it/tags/backdoor/index.xml @@ -2,7 +2,7 @@

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

+

Il pacchetto è stato usato come entrypoint per l’injection di codice malevolo in sshd, modificandone il flusso di autenticazione.

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

diff --git a/it/tags/cve-2024-3094/index.xml b/it/tags/cve-2024-3094/index.xml index bf578de..e0ec7ba 100644 --- a/it/tags/cve-2024-3094/index.xml +++ b/it/tags/cve-2024-3094/index.xml @@ -2,7 +2,7 @@

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

+

Il pacchetto è stato usato come entrypoint per l’injection di codice malevolo in sshd, modificandone il flusso di autenticazione.

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

diff --git a/it/tags/liblzma/index.xml b/it/tags/liblzma/index.xml index c3204da..9ca6726 100644 --- a/it/tags/liblzma/index.xml +++ b/it/tags/liblzma/index.xml @@ -2,7 +2,7 @@

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

+

Il pacchetto è stato usato come entrypoint per l’injection di codice malevolo in sshd, modificandone il flusso di autenticazione.

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

diff --git a/it/tags/security-engineering/index.xml b/it/tags/security-engineering/index.xml index 733c6d6..5f1ac7f 100644 --- a/it/tags/security-engineering/index.xml +++ b/it/tags/security-engineering/index.xml @@ -2,7 +2,7 @@

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

+

Il pacchetto è stato usato come entrypoint per l’injection di codice malevolo in sshd, modificandone il flusso di autenticazione.

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

diff --git a/it/tags/supply-chain/index.xml b/it/tags/supply-chain/index.xml index 356ff03..d646855 100644 --- a/it/tags/supply-chain/index.xml +++ b/it/tags/supply-chain/index.xml @@ -2,7 +2,7 @@

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

+

Il pacchetto è stato usato come entrypoint per l’injection di codice malevolo in sshd, modificandone il flusso di autenticazione.

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

diff --git a/it/tags/xz/index.xml b/it/tags/xz/index.xml index dba1719..d9c535f 100644 --- a/it/tags/xz/index.xml +++ b/it/tags/xz/index.xml @@ -2,7 +2,7 @@

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

+

Il pacchetto è stato usato come entrypoint per l’injection di codice malevolo in sshd, modificandone il flusso di autenticazione.

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

diff --git a/sitemap.xml b/sitemap.xml index 0e3c975..b32dd23 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -1 +1 @@ -https://appsec.space/en/sitemap.xml2024-03-31T10:22:20+02:00https://appsec.space/it/sitemap.xml2024-03-31T10:22:20+02:00 \ No newline at end of file +https://appsec.space/en/sitemap.xml2024-03-31T10:22:20+02:00https://appsec.space/it/sitemap.xml2024-03-31T10:25:51+02:00 \ No newline at end of file