stevehenderson/lab_xz_backdoorAlcuni laboratori che esaminano la vulnerabilità della backdoor xz (CVE-2024-3094)
Laboratori sicuri e pratici per comprendere la backdoor della supply chain di xz-utils — realizzati per difensori, studenti e blue team.
[!WARNING] Questo progetto gestisce malware reale, in-the-wild (la backdoor della xz 5.6.0 / 5.6.1). È fornito esclusivamente per formazione difensiva e ricerca autorizzata. Tutto viene eseguito in una guest isolata e usa e getta, senza accesso a Internet. Non eseguire questi artefatti su una macchina a cui tieni, su una rete che non controlli, o contro qualsiasi sistema che non sei autorizzato a testare. Vedi SECURITY.md.
| Laboratorio | Cosa fa | Esegue il payload? |
|---|
| Laboratorio 1 — Ispezione | Avvia una sandbox usa e getta, ottieni il tarball malevolo in offline e osserva il travestimento: il diff build-to-host.m4 tra git e tarball, i payload delle fixture di test, il marker magico. | No — solo ispezione statica |
| Laboratorio 2 — Detonazione | Costruisci una rete isolata a tre VM (analyst / compromised / normal, senza Docker). Dalla jumpbox analyst, connettiti via SSH a entrambi gli host per confrontare latenza e pcaps, poi attiva il sshd compromesso su compromised con la tua chiave Ed448 (tramite xzbot) per una RCE root pre-autenticazione — mentre normal resta immune. | Sì — VM isolate, offline, la tua chiave |
Una campagna di social engineering durata due anni ha concesso a un maintainer malintenzionato l'autorità
di rilascio su xz-utils. Il payload veniva distribuito solo nel tarball di release (non in git), nascosto in
fixture di test e attivato in fase di build su sistemi glibc x86-64. A runtime usava un
hook IFUNC della glibc su RSA_public_decrypt (raggiungibile tramite sshd → libsystemd → liblzma) per dare al possessore della chiave una RCE pre-autenticazione — un comando nascosto nel modulo RSA di un certificato
SSH, cifrato con ChaCha20 e firmato Ed448. Non è C2 né
un login magico. Scoperta da Andres Freund il 29 marzo 2024 grazie a un rallentamento di SSH di circa 500 ms, prima
che arrivasse alle distribuzioni stabili.
make setup # install/preflight checks (Multipass or Docker, tcpdump, etc.)
make lab1 # inspection sandbox
make lab2 # build the isolated 3-VM detonation network, then: multipass shell analyst
make clean # tear everything down, purge VMs / pcaps / generated keys
I prerequisiti e le guide dettagliate per ogni lab si trovano in docs/.
sshd compromesso del Lab 2 si lega solo a loopback / bridge interno e il lab
si rifiuta di avviarsi se la guest può raggiungere Internet.MIT.