From b7c6c1838f42b567dfcfb6336e485a3231ad89db Mon Sep 17 00:00:00 2001 From: himazawa Date: Sun, 31 Mar 2024 09:34:06 +0000 Subject: [PATCH] deploy: 00a5b087c956d52c39ac6d4de76ed02911552a02 --- en/sitemap.xml | 2 +- index.xml | 8 ++++---- it/index.xml | 6 +++--- it/posts/index.xml | 6 +++--- it/posts/xz-backdoor/index.html | 10 +++++----- it/posts/xz-backdoor/index.md | 6 +++--- it/sitemap.xml | 2 +- it/tags/backdoor/index.xml | 6 +++--- it/tags/cve-2024-3094/index.xml | 6 +++--- it/tags/liblzma/index.xml | 6 +++--- it/tags/security-engineering/index.xml | 6 +++--- it/tags/supply-chain/index.xml | 6 +++--- it/tags/xz/index.xml | 6 +++--- posts/index.xml | 8 ++++---- posts/xz-backdoor/index.html | 12 ++++++------ posts/xz-backdoor/index.md | 8 ++++---- sitemap.xml | 2 +- tags/backdoor/index.xml | 8 ++++---- tags/cve-2024-3094/index.xml | 8 ++++---- tags/liblzma/index.xml | 8 ++++---- tags/security-engineering/index.xml | 8 ++++---- tags/supply-chain/index.xml | 8 ++++---- tags/xz/index.xml | 8 ++++---- 23 files changed, 77 insertions(+), 77 deletions(-) diff --git a/en/sitemap.xml b/en/sitemap.xml index 47410c8..2674d53 100644 --- a/en/sitemap.xml +++ b/en/sitemap.xml @@ -1 +1 @@ -https://appsec.space/2024-03-31T11:20:16+02:00weekly1https://appsec.space/tags/backdoor/2024-03-31T11:20:16+02:00weekly1https://appsec.space/tags/cve-2024-3094/2024-03-31T11:20:16+02:00weekly1https://appsec.space/tags/liblzma/2024-03-31T11:20:16+02:00weekly1https://appsec.space/posts/2024-03-31T11:20:16+02:00weekly1https://appsec.space/tags/security-engineering/2024-03-31T11:20:16+02:00weekly1https://appsec.space/tags/supply-chain/2024-03-31T11:20:16+02:00weekly1https://appsec.space/tags/2024-03-31T11:20:16+02:00weekly1https://appsec.space/posts/xz-backdoor/2024-03-31T11:20:16+02:00weekly1https://appsec.space/tags/xz/2024-03-31T11:20:16+02:00weekly1https://appsec.space/categories/2024-03-30T22:00:02+01:00weekly1https://appsec.space/categories/general-knowledge/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/infosec/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/rants/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/security-theatre/2024-03-30T22:00:02+01:00weekly1https://appsec.space/posts/security-theatre/2024-03-30T22:00:02+01:00weekly1https://appsec.space/categories/blog-news/2024-03-30T22:00:02+01:00weekly1https://appsec.space/posts/long-time-no-see/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/updates/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/ai/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/code-review/2024-03-30T22:00:02+01:00weekly1https://appsec.space/posts/mycroft-ai-rce/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/vocal-assistant/2024-03-30T22:00:02+01:00weekly1https://appsec.space/categories/vulnerability-research/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/writeup/2024-03-30T22:00:02+01:00weekly1https://appsec.space/about/2023-03-21T22:11:59+01:00weekly0.5 \ No newline at end of file +https://appsec.space/2024-03-31T11:33:45+02:00weekly1https://appsec.space/tags/backdoor/2024-03-31T11:33:45+02:00weekly1https://appsec.space/tags/cve-2024-3094/2024-03-31T11:33:45+02:00weekly1https://appsec.space/tags/liblzma/2024-03-31T11:33:45+02:00weekly1https://appsec.space/posts/2024-03-31T11:33:45+02:00weekly1https://appsec.space/tags/security-engineering/2024-03-31T11:33:45+02:00weekly1https://appsec.space/tags/supply-chain/2024-03-31T11:33:45+02:00weekly1https://appsec.space/tags/2024-03-31T11:33:45+02:00weekly1https://appsec.space/posts/xz-backdoor/2024-03-31T11:33:45+02:00weekly1https://appsec.space/tags/xz/2024-03-31T11:33:45+02:00weekly1https://appsec.space/categories/2024-03-30T22:00:02+01:00weekly1https://appsec.space/categories/general-knowledge/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/infosec/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/rants/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/security-theatre/2024-03-30T22:00:02+01:00weekly1https://appsec.space/posts/security-theatre/2024-03-30T22:00:02+01:00weekly1https://appsec.space/categories/blog-news/2024-03-30T22:00:02+01:00weekly1https://appsec.space/posts/long-time-no-see/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/updates/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/ai/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/code-review/2024-03-30T22:00:02+01:00weekly1https://appsec.space/posts/mycroft-ai-rce/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/vocal-assistant/2024-03-30T22:00:02+01:00weekly1https://appsec.space/categories/vulnerability-research/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/writeup/2024-03-30T22:00:02+01:00weekly1https://appsec.space/about/2023-03-21T22:11:59+01:00weekly0.5 \ No newline at end of file diff --git a/index.xml b/index.xml index 3d6896d..3eaff57 100644 --- a/index.xml +++ b/index.xml @@ -15,7 +15,7 @@ Check the Resources section for additional links.

The situation doesn’t look too good so I’m trying to write this blogpost as a summary.

I don’t want to address the technical aspect of the compromission but I want to look at the issue from the perspective of a Security Engineer, summarizing what went wrong and trying to find a remediation.

+ 1 Timeline
Note
@@ -55,12 +55,12 @@ He was optimizing his infrastructure and found that ssh was suspiciously slow. 2 Impacted components

The extent of this breach is still unkown, but here is a (partial) list of components shipping the known malicious version of xz:

Distributions:

    -
  • Arch
    • +
  • Arch
  • Debian Sid
    • -
  • Gentoo
    • +
  • Gentoo
  • Fedora 40
  • Manjaro Testing
    • -
  • Parabola
    • +
  • Parabola
  • NixOS Unstable
  • Slackware
  • SUSE Tumbleweed
    • diff --git a/it/index.xml b/it/index.xml index ae51ba1..ae72af1 100644 --- a/it/index.xml +++ b/it/index.xml @@ -61,12 +61,12 @@ Stava ottimizzando la sua infrastruttura e si è accorto che ssh era “sosp 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:

    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. Ancora una volta, grazie GitHub per aver bloccato l’accesso ai sorgenti e contribuito a far capire ancora meno la situazione.

    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

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

    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.

Aggiornato il 2024-03-31  -e676706
Leggi Markdown
 Backdoor, CVE-2024-3094, Xz, Liblzma, Supply-Chain, Security-Engineering
Indietro | Home
+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 ;)

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.

Aggiornato il 2024-03-31  +00a5b08
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 6ae95b7..4fe2af7 100644 --- a/it/posts/xz-backdoor/index.md +++ b/it/posts/xz-backdoor/index.md @@ -45,12 +45,12 @@ Controlla la sezione Risorse per i link ad una timeline più dettagliata 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 +- [Arch](https://archlinux.org/news/the-xz-package-has-been-backdoored/) - [Debian Sid](https://security-tracker.debian.org/tracker/CVE-2024-3094) -- Gentoo +- [Gentoo](https://bugs.gentoo.org/928134) - [Fedora 40](https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users) - Manjaro Testing -- Parabola +- [Parabola](https://www.parabola.nu/news/arch-announce-the-xz-package-has-been-backdoored/) - NixOS Unstable - Slackware - [SUSE Tumbleweed](https://news.opensuse.org/2024/03/29/xz-backdoor/) diff --git a/it/sitemap.xml b/it/sitemap.xml index fd42900..4f6a09e 100644 --- a/it/sitemap.xml +++ b/it/sitemap.xml @@ -1 +1 @@ -https://appsec.space/it/2024-03-31T11:21:25+02:00weekly1https://appsec.space/it/tags/backdoor/2024-03-31T11:21:25+02:00weekly1https://appsec.space/it/tags/cve-2024-3094/2024-03-31T11:21:25+02:00weekly1https://appsec.space/it/posts/xz-backdoor/2024-03-31T11:21:25+02:00weekly1https://appsec.space/it/tags/liblzma/2024-03-31T11:21:25+02:00weekly1https://appsec.space/it/posts/2024-03-31T11:21:25+02:00weekly1https://appsec.space/it/tags/security-engineering/2024-03-31T11:21:25+02:00weekly1https://appsec.space/it/tags/supply-chain/2024-03-31T11:21:25+02:00weekly1https://appsec.space/it/tags/2024-03-31T11:21:25+02:00weekly1https://appsec.space/it/tags/xz/2024-03-31T11:21:25+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-31T11:33:45+02:00weekly1https://appsec.space/it/tags/backdoor/2024-03-31T11:33:45+02:00weekly1https://appsec.space/it/tags/cve-2024-3094/2024-03-31T11:33:45+02:00weekly1https://appsec.space/it/posts/xz-backdoor/2024-03-31T11:33:45+02:00weekly1https://appsec.space/it/tags/liblzma/2024-03-31T11:33:45+02:00weekly1https://appsec.space/it/posts/2024-03-31T11:33:45+02:00weekly1https://appsec.space/it/tags/security-engineering/2024-03-31T11:33:45+02:00weekly1https://appsec.space/it/tags/supply-chain/2024-03-31T11:33:45+02:00weekly1https://appsec.space/it/tags/2024-03-31T11:33:45+02:00weekly1https://appsec.space/it/tags/xz/2024-03-31T11:33:45+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 3794724..64c9dcb 100644 --- a/it/tags/backdoor/index.xml +++ b/it/tags/backdoor/index.xml @@ -61,12 +61,12 @@ Stava ottimizzando la sua infrastruttura e si è accorto che ssh era “sosp 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: