Il 29 marzo 2024 un ingegnere Microsoft, Andres Freund, notò qualcosa di strano: gli accessi SSH su una macchina Debian di sviluppo erano più lenti di circa mezzo secondo, con un uso anomalo di CPU e qualche errore in Valgrind. Invece di ignorarlo, tirò il filo. In fondo c'era una delle backdoor più sofisticate mai inserite in software open source, a un passo dall'arrivare su milioni di server in tutto il mondo.

La falla

CVE-2024-3094, punteggio CVSS 10.0 — il massimo. Il codice malevolo era nelle versioni 5.6.0 e 5.6.1 di xz/liblzma, una libreria di compressione presente ovunque in Linux. Su alcune distribuzioni sshd viene collegato indirettamente a liblzma (tramite la notifica a systemd), e la backdoor sfruttava questo per intercettare l'autenticazione: con la chiave privata giusta (Ed448, in mano all'attaccante) permetteva l'esecuzione di codice remoto pre-autenticazione. Una master key su una fetta enorme di Internet.

Il lato più inquietante: la pazienza

Cronologia dell'attacco a XZ Utils
Fiducia guadagnata in anni, sfruttata in una singola release.

Il vero exploit non era tecnico: era sociale. Un'identità chiamata Jia Tan iniziò a contribuire al progetto nel 2021. Il progetto era mantenuto quasi da una sola persona, sotto pressione e senza risorse. Nel 2022 comparvero account — Jigar Kumar, Dennis Ens — che lamentavano la lentezza degli aggiornamenti e spingevano il manutentore originale a passare la mano. Nel 2024, a backdoor pronta, altri profili (Hans Jansen, krygorin4545, misoeater91) sollecitavano le distribuzioni ad adottare subito le nuove versioni. Indirizzi mai comparsi altrove su Internet: con ogni probabilità sockpuppet della stessa operazione. Dopo mesi di questa pressione, Jia Tan ottenne i permessi da co-manutentore. A quel punto poté agire da dentro.

Il meccanismo tecnico

La backdoor era un capolavoro di occultamento:

  • Il payload malevolo era nascosto in file di test binari apparentemente innocui (dati "corrotti" per testare la decompressione).
  • L'attivazione passava da uno script build-to-host.m4 modificato, presente solo nei tarball di rilascio, non nel repository Git. Chi guardava il codice su GitHub non vedeva nulla; il male entrava solo compilando dal pacchetto distribuito.
  • La compilazione iniettava il codice solo in condizioni precise: Linux x86-64, glibc, build di pacchetti deb o rpm. Un modo per colpire le distribuzioni mainstream evitando di attivarsi nei test degli sviluppatori.
  • A runtime, tramite un risolutore IFUNC, la libreria dirottava la verifica delle chiavi in sshd.

Furono colpite le versioni in sviluppo di Debian, Fedora, openSUSE Tumbleweed, Kali. Le distribuzioni stabili si salvarono perché la scoperta arrivò prima. La reazione fu immediata: downgrade a versioni sicure (5.4.x) e, in seguito, la 5.6.2 correttiva.

Il dettaglio che fa riflettere

Non è stato uno scanner a trovare la backdoor. Non un audit, non un tool di sicurezza. È stato un ingegnere curioso infastidito da mezzo secondo di lentezza. Se non avesse tirato quel filo, oggi parleremmo di uno dei più grandi compromessi della storia.

Le lezioni

  1. Infrastruttura critica, manutenzione fragile. Pezzi fondamentali di Internet poggiano su volontari isolati e sotto pressione. È una vulnerabilità strutturale, non tecnica.
  2. Divergenza tra sorgente e artefatto. Il male era nel tarball, non nel Git. I build riproducibili, che garantiscono che il binario derivi esattamente dal sorgente pubblico, avrebbero fatto emergere l'anomalia.
  3. Fiducia come superficie d'attacco. L'ingegneria sociale non colpisce solo gli utenti finali: colpisce i processi di governance dei progetti. Contributi anonimi che scalano rapidamente ai permessi meritano attenzione.
  4. SBOM e minimizzazione delle dipendenze. Serve sapere cosa si esegue davvero, e ridurre il numero di componenti fidati. sshd non aveva bisogno di liblzma: era una dipendenza indiretta.

C'è un filo che collega XZ a un altro segnale del 2026: il progetto curl ha chiuso a fine gennaio 2026 il suo bug bounty, sommerso da segnalazioni di bassa qualità generate dall'AI: dal 2025 le vulnerabilità confermate erano scese sotto il 5% dei report. A marzo le segnalazioni sono tornate su HackerOne, ma le ricompense in denaro no. Da un lato attaccanti pazienti sfruttano la scarsità di manutentori; dall'altro, il rumore prosciuga il loro tempo. La difesa della supply chain open source non è solo tecnica: è, prima di tutto, una questione di sostenibilità delle persone che la reggono.

Fonti