Backdoor-SSH
Een snode of gecompromitteerde beheerder heeft kwaadaardig gedrag in een bibliotheek met de naam geplaatst liblzma, onderdeel van de xz-compressietools en -bibliotheken, resulterend in een achterdeur in SSH. Dit is een geavanceerde software-aanval op de toeleveringsketen, aangezien de bibliotheek opzettelijk is aangepast voor de achterdeur, met verduisterings- en stealth-technieken om de aanvalslading voor recensenten te verbergen. Het werd onlangs ontdekt en bekendgemaakt (op 29 maart), en de aanval wordt nog steeds afgehandeld. Het werd echter snel ingedamd, omdat het alleen pre-releaseversies van een beperkte set omgevingen lijkt te beïnvloeden (DEB- en RPM-pakketten, voor de x86_64-architectuur en gebouwd met GCC). Hoe dan ook, de CVE kreeg een CVSS-basisscore van 10, gereserveerd voor de meest kritieke cybersecuritykwetsbaarheden. Mocht het in stabiele distributies terechtkomen, dan zou de impact overweldigend zijn. De technische analyse van de aanval, inclusief de xz backdoor uitgebreid uitgelegd, werd elders geanalyseerd. Deze post zal zich richten op de tijdlijn van de aanval, hoe deze gedetecteerd kon worden, hoe het incident tot nu toe werd afgehandeld en welke lessen er uit de aanval kunnen worden getrokken.Hoe de XZ-achterdeur werd geïnjecteerd
Opmerking: de git-repository is binnen git.tukaani.org. Echter, er was ook een Door GitHub gehoste opslagplaats (momenteel geblokkeerd) waar het GitHub-account de wijzigingen postte die later in de Git-repository werden geïntegreerd. Eén deel van de achterdeur lijkt alleen in de gedistribueerde tarballs voor de 5.6.0- en 5.6.1-versies te zitten, niet in de git-repository's, en is afhankelijk van een enkele regel in build-to-host.m4 macrobestand gebruikt door autoconf. Het andere deel bevond zich in twee zogenaamde testbestanden slecht-3-corrupt_lzma2.xz en goed-groot_gecomprimeerd.lzma dat waren committed door het GitHub-account “Jia Tan” (JiaT75) in de xz-opslagplaats op 23 februari. Het was een onschadelijke wijziging door het toevoegen van testbestanden (zogenaamd gecomprimeerde .lzma- en .xz-blokken). Interessant genoeg werden de testbestanden niet gebruikt bij de tests! De regel in het .m4-bestand injecteert een versluierd script (opgenomen in de tarball) dat aan het einde van de configuratie moet worden uitgevoerd als bepaalde voorwaarden overeenkomen. Het wijzigt de Makefile voor de liblzma bibliotheek om code te bevatten die gegevens uit het .xz-bestand extraheert, die na de deobfuscatie eindigt in dit script, wordt aangeroepen aan het einde van de configuratie. Het beslist of het bouwproces moet worden aangepast om code te injecteren: alleen onder GCC en de GCC-linker, onder Debian of rpm, en alleen voor x86_64 Linux. Wanneer deze overeenkomen, onderschept de geïnjecteerde code de uitvoering door er twee te vervangen ifunc solvers zodat bepaalde oproepen worden vervangen. Dit zorgt ervoor dat de symbooltabellen in het geheugen worden geparseerd (dit kost tijd, wat tot de detectie heeft geleid, zoals later wordt uitgelegd). Dan wordt het interessant: de achterdeur installeert een audit hook in de dynamische linker, wachtend tot het RSA_public_decrypt-functiesymbool arriveert, dat wordt omgeleid naar een punt in de achterdeurcode, die op zijn beurt terugroept libcrypto, vermoedelijk om normale authenticatie uit te voeren. En de payload wordt geactiveerd als het actieve programma de procesnaam heeft /usr/sbin/sshd. Het was duidelijk dat SSH-servers het doelwit waren. Traditioneel, sshd servers zoals OpenSSH waren niet gekoppeld liblzma, maar sshd wel vaak gepatcht om systemd-notify te ondersteunen, zodat andere services kunnen starten wanneer sshd actief is. En dan wordt liblzma indirect geladen door systemd, de cirkel sluitend. De achterdeur is nog niet volledig geanalyseerd, maar lijkt dat wel te zijn waardoor uitvoering van opdrachten op afstand mogelijk is (RCE) met de rechten van de sshd-daemon, uitgevoerd in een pre-authenticatiecontext. Informatie van het externe certificaat wordt, wanneer deze door de achterdeur wordt gekoppeld, gedecodeerd met ChaCha20 en wanneer de decodering succesvol is, wordt deze doorgegeven aan de systeem(). Dit is dus in wezen een gated RCE, veel erger dan louter het omzeilen van een openbare sleutel. Een latere tarball uit 5.6.1 toonde aanvullende pogingen om de sporen te verbergen, verdere verduistering voor symboolnamen toe te voegen en te proberen de waargenomen fouten te herstellen. Een verlengingsmechanisme waar naar aanvullende testbestanden werd gezocht om bepaalde handtekeningen toe te voegen aan de achterdeur, werd ook geïnstalleerd. Deze tamelijk geavanceerde aanval zou onopgemerkt kunnen blijven totdat er stabiele Linux-distributies zijn bereikt. Gelukkig willen sommige mensen graag controleren waarom abnormale dingen gebeuren.De ontdekking van de XZ-achterdeuraanval
Vaak wordt geïnjecteerd kwaadaardig gedrag per toeval of per ongeluk aan het licht gebracht. Een goed voorbeeld was A waarschuwing voor beëindiging (“Wie geeft er om waarschuwingen?”) die leidde tot de ontdekking van de event-stream-aanval in oktober 2018. Een andere gebruiker is de gebruiker die waarschuwde codecov in april 2021 dat hun bash-uploader-script de checksum niet doorstond (“Wie verifieert de integriteit van artefacten met checksums”?) Afwijkingen en vreemde symptomen met ssh logins (logins die veel CPU in beslag nemen en de verstreken tijd verhogen, valgrind-fouten) wekten de nieuwsgierigheid van Andrés Freund, een waakzame PostgreSQL-ontwikkelaar maar geen beveiligingsanalist (zoals hij zei). Na enig onderzoek met OpenSSH op Debian Sid kwam hij tot de conclusie dat een responstijdprobleem afhankelijk was van een bibliotheek, liblzmaEen deel van de xz-hulpprogramma's compressie bibliotheek. De reden: "de upstream xz-repository en de xz-tarballs zijn achterdeurd”. Deze diagnose was zo nauwkeurig! Op 29 maart 2024 plaatste Andres in Openwall de eerste analyse: “achterdeur in upstream xz/liblzma, wat leidt tot een ssh-servercompromis”. Het feit: de tarballs van XZ Utils 5.6.0 en 5.6.1 bevatten een achterdeur. Deze tarballs zijn gemaakt en ondertekend door het bovengenoemde Jia Tan-account. He geplaatst in Mastodon later die dag, in het besef dat de ontdekking toevallig was en veel toevalligheden vereiste. De opmerkingen van andere gebruikers zijn het lezen waard. GitHub-gebruiker hetzelfde (ook bekend als Sam James) heeft een mooie Gist gepubliceerd Veelgestelde vragen over de xz-utils-achterdeur waar de aanval werd samengevat en naar meer linkte diepgaande analyses van de aanvalslading. Deze analyses waren technisch sappig en hielpen ons de injectie, die zeer gedetailleerd was, beter te begrijpen:- xz/liblzma: Bash-stage verduistering uitgelegd. Mooie analyse van de deobfuscatie door het injectiescript, in vier “fasen”.
- De blauwe luchtdraad van Filippo Valsorda Analyse van de achterdeur zelf in RSA_public_decrypt, die de aard ervan laat zien: een RCE, geen auth-bypass, en gated (accepteert de privésleutel van de auteur en keert terug naar normaal gedrag) / niet terugbetaalbaar. De auteur was van plan om onopvallend te blijven om detectie te voorkomen!
- XZ Backdoor-analyse door @smx-smx (WIP) – Aanvullende analyse van de achterdeur (ik was bijna in het begin verdwaald 😀)
- xz achterdeurdocumentatiewiki, nog een analyse van het 5.6.1-injectiescript.
Hoe het incident is afgehandeld
De openbaarmaking door Andreas Freund was voorzichtig omdat, in zijn eigen woorden:Gezien de schijnbare betrokkenheid van de upstream-afdeling heb ik geen upstream-bug gemeld. Omdat ik aanvankelijk dacht dat het een Debian-specifiek probleem was, heb ik een meer voorlopig rapport gestuurd naar security@...ian.org. Vervolgens heb ik het probleem gemeld aan distros@. CISA werd op de hoogte gebracht door een distributie.”
Red Hat heeft dit probleem CVE-2024-3094 toegewezen. Toen circuleerde het woord als een lopend vuurtje.
Lasse Collin, de andere onderhouder van de XZ, voegde een nieuwe commit op zaterdag 30 maart getiteld "CMake: Fix gesaboteerd Landlock sandbox check". Een van de landlock-methoden voor het sandboxen van de bibliotheek werd gesaboteerd, tenminste bij het bouwen met CMake. Hij maakte de kwestie onmiddellijk bekend in de krant XZ Maakt gebruik van een achterdeur.
Red Hat heeft dit probleem toegewezen CVE-2024-3094 (zie ook bij CVE, NVD, Ubuntu). Het kreeg maar liefst een opdracht CVSS-basisscore van 10. Dergelijke scores veroveren het internet altijd stormenderhand.
CISA op dezelfde 29 maart bracht een te waarschuwen, misschien te simplistisch vanwege de urgentie, en raadt gebruikers aan om te downgraden naar de stabiele versie 5.4.6.
GitHub-opslagplaatsen onder de Tukaani-organisatie zijn uitgeschakeld (is dit goed of slecht? Ik denk goed: veel distributies en organisaties linkten nog steeds naar de GitHub-releases om de geïnfecteerde tarballs te vinden om te bouwen. Het uitschakelen van de repository voorkomt dat. Er is hoe dan ook een kopie of de repo's op git.tukaani.org). De GitHub-accounts JiaTan75 en Lasse Collins' (Larhzu) werden ook opgeschort. Dit maakt deel uit van de containment, zelfs als het onschuldige mensen kan treffen. JiaT75 activiteit in niet-uitgeschakelde opslagplaatsen is nog niet te zien.
De sector reageerde onmiddellijk. Veel leveranciers hebben regels gepubliceerd voor het detecteren van kwetsbare systemen, zoals Yara regeert, of ondersteuning in commerciële tools van Sysdig, PAN, en anderen. Beveiligingsspecialisten houden van James Berthoty gepost over een review van hoe wij open-source software benaderen.
We bevinden ons nu in de uitroeiings- en herstelfase van het incident. Andere projecten die door JiaTan75 worden onderhouden, worden nauwlettend in de gaten gehouden, met name de bibliotheek/libarchive (waar JiaTan75 regelmatig een bijdrage aan leverde) en de fuzzer oss-fuzz (waar commit gemaakt door JiaTan75 probeerde oss-fuzz te vermijden, wat in feite kon de achterdeur niet detecteren). Deze verhullingspogingen voegen nog meer bewijs toe.
Wie wordt aangevallen?
Ofwel het GitHub JiaT75-account is gecompromitteerd (onthoud dat GitHub onlangs 2FA verplicht heeft gesteld) of de fysieke gebruiker die het account verschuldigd was, ging naar de duistere kant. Maar er zijn dwingende redenen om aan een geavanceerde persistente dreiging (APT) te denken, misschien door de staat gesteund, vanwege de technische verfijning van de aanval. Verder onderzoek door cyberveiligheidsdiensten en wetshandhavers zal uitwijzen... Dit bericht in YCombinator Hacker Nieuws over Jia Tan werpt enig licht op het ‘wie’ en zijn activiteit. Aanbevolen! Het geeft veel informatie over hoe de slechteriken andere gebruikers proberen te misleiden met behulp van social engineering.“Erg vervelend - de schijnbare auteur van de backdoor communiceerde wekenlang met mij (rwmj) om xz 5.6.x toe te voegen aan Fedora 40 & 41 vanwege de "geweldige nieuwe functies". We hebben zelfs met hem samengewerkt om het valgrind-probleem op te lossen (dat nu bleek te zijn veroorzaakt door de backdoor die hij had toegevoegd). We moesten gisteravond racen om het probleem op te lossen na een onbedoelde breuk van het embargo. Hij is al 2 jaar onderdeel van het xz-project en heeft allerlei binaire testbestanden toegevoegd, en om eerlijk te zijn zou ik met dit niveau van verfijning zelfs nog oudere versies van xz wantrouwen totdat het tegendeel bewezen is.”
Jia Tan heeft maatregelen genomen om te voorkomen dat ze worden gevolgd: het lijkt erop dat het een VPN (vpn.singapore.witopia.net) heeft gebruikt om verbinding te maken – wat op zichzelf prima is. En veel veranderingen lijken te worden ondersteund door tijdelijke e-mails voor eenmalig gebruik (in dit geval van ProtonMail) waarin wordt aangedrongen op het samenvoegen van de wijzigingen.
De acteur is misschien van plan nog dieper te gaan, tot aan de Linux-kernel, als bijdrager aan de xy-ingebed project. Een eerste analyse vond tot op heden geen bewijs van een miskraam.
Let op: nog een low-profile XZ-bijdrager “Hans Jansen“ (GitHub-gebruiker “hansjans162”) is onder toezicht. Zijn account bij debian is nu geblokkeerd. Hij heeft veel updates voor Debian Games aangebracht om degene die hij wilde op debian/xz-utils te verbergen, een update naar upstream 5.6.1 om haast te maken met de distributie van de achterdeur naar debian/onstabiel.
Het enige wat we voorlopig kunnen zeggen is dat dit een (nog niet geïdentificeerde) APT is die verschillende accounts gebruikt, die minstens twee jaar aan deze campagne werkt en geduldig werkt aan het implanteren van een RCE in SSH.
Was de XZ-backdooraanval te voorkomen?
Nogal moeilijk. Ten eerste kwam een deel van de geïnjecteerde backdoor terecht in gecomprimeerde testbestanden die niet door tests werden gebruikt. Achteraf gezien zou dat wat (luidruchtige) alarmbellen kunnen doen rinkelen, maar wie maakt zich druk om het controleren of alle testbestanden daadwerkelijk door tests in de praktijk worden gebruikt? Ten tweede kwam een deel van de geïnjecteerde backdoor terecht in macrobestanden in de release-tarballs, en het is lastig om handmatig te controleren op verschillen met de verwachte tarballs. Automatisering is ook complex, omdat het verwachte resultaat van de build zelf (voor iedereen die weet hoe automake/autoconf werkt) moeilijk te modelleren is om te analyseren of de echte tarball aan de verwachtingen voldoet. Sommigen stelden het as “Dat de tarballs niet overeenkomen met de git-boom is een feature, geen bug”. De herkomst van binaire tarballs uit de broncode is een onopgelost probleem. Reputatie van gebruikers? Welnu, het JiaTan75 GitHub-account deed volgens het verleden geen malafide dingen commitS. Het werd pas opgeschort nadat het bewijs zich had verzameld, maar tot 29 maart was het een regelmatige gebruiker die normale zaken deed. Nou ja, niet zo normaal. Later commits (dit, dit, diten dit die de exploitcode aanpaste) probeerde de valgrind-fouten en crashes in sommige configuraties op te lossen, vanwege verschillen met de stapelindeling die door de achterdeur werd verwacht. Commit beoordelingen zouden dit kunnen detecteren, maar wie heeft het geduld om veranderingen in een binair testbestand te analyseren of de echte motivatie voor een verandering in GCC-attributen in C-broncode? Moet er alarm worden geslagen wanneer een SSH login duurt 800 ms in plaats van 300 ms? Waarschijnlijk zouden alleen hypervoorzichtige mensen dit opmerken. Cicero zei: “Onbezonnenheid hoort bij de jeugd; voorzichtigheid tot op hoge leeftijd.” De ifunc-infrastructuur werd in juni 2023 toegevoegd door “Hans Jansen” en “Jia Tan”. Dit is de eerste commit ifunc-ondersteuning toevoegen aan crc64_fast.c (later gebruikt om de achterdeur te injecteren). Maanden voordat de achterdeur-binaire bestanden in de testbestanden worden geïnjecteerd!
Opmerking: auteur en commithier verschillen, maar dit is normaal: Lasse Collin is de projectbeheerder en hij heeft de wijzigingen samengevoegd. Hij bedankt zelfs “Hans Jansen”…
Niemand uitte zijn zorgen vóór de post van Andres Freund en de CVE die door RedHat werd gecreëerd. Als je een reeks tools ziet die dit zouden kunnen opvangen, detecteren ze het getroffen onderdeel nu. ex post facto.
Waarschijnlijk kwam de beste preventie voort uit de aard van Linux-distributies, en hoe onstabiele, geavanceerde versies pas stroomafwaarts na een snel proces overgaan naar stabiele distributies.
Lessen geleerd uit de XZ bBackdoor-aanval
We hebben gemerkt hoe moeilijk het te detecteren is opzettelijk achterdeurtjes. Achterdeurtjes moeten als een interne bedreiging worden beschouwd, omdat ze worden geplaatst door intern personeel of via gecompromitteerde interne accounts. En die jongens worden meestal vertrouwd. En wanneer de achterdeur in het gedistribueerde artefact wordt geïmplanteerd, wordt het moeilijker te detecteren.
Sommige auteurs houden van Kevin Beaumont gericht op system, waardoor een groot aanvalsoppervlak van services van derden naar de achterdeur wordt geopend. Dit is wat de slechte acteur hier heeft misbruikt. Systemd heeft veel oogappels, maar XZ is een obscure bibliotheek verderop in de keten. “Als de stroomopwaarts besmet is, drinkt iedereen stroomafwaarts vergiftigd water”.
Een niet-gerelateerd wijzigingsverzoek in het systeem voor dynamisch laden van compressiebibliotheken, waarmee de achterdeur zou worden verwijderd, was al in het systeem opgenomen maar nog niet opgeleverd. De extra afhankelijkheden die door libsystemd worden geïntroduceerd, kunnen de bron van kwetsbaarheden zijn, en gisteren dit verzoek werd geopend.
A commentaar in de "xz: schakel ifunc uit om het probleem op te lossen" commit gaf een scherp inzicht over waar we de nadruk op moeten leggen als we dergelijke activiteiten willen voorkomen (nadruk ligt bij mij):
“De les die we als gemeenschap moeten leren, is dat we beter moeten beveiligen software supply chain security holistisch gezien, auditing van bouwsystemen die verder gaan dan alleen de broncode. Zoals de inbreuk op SolarWinds, waarbij aanvallers software-updates voor het closed-source monitoringsoftwareaanbod van SolarWinds hebben aangepast.”
De vroege ontdekking en snelle reactie beperkten de impact enorm. Als u zich de eindscène uit Men in Black III: "Dat was op het nippertje". Opnieuw vergat K niet de fooi achter te laten. En geen enkele boglodiet kwam in de stabiele Linux-distributies terecht.
1. "Ik ben *geen* beveiligingsonderzoeker, noch een reverse engineer." 2. Jia is een veelvoorkomende Chinese voornaam. Tan is ook een veelvoorkomende familienaam die "geweldig" betekent. Veel mensen die geen familie van elkaar zijn, delen deze naam. Veroordeel alstublieft niemand met deze naam!
