Agterdeur SSH
'n Slegte of gekompromitteerde onderhouer het kwaadwillige gedrag in 'n biblioteek met die naam ingevoeg liblzma, deel van die xz-kompressie-instrumente en -biblioteke, wat lei tot 'n agterdeur in SSH. Dit is 'n gevorderde sagteware-voorsieningskettingaanval aangesien die biblioteek doelbewus vir die agterdeur aangepas is, met verdoeselings- en stealth-tegnieke om die aanvalvrag van beoordelaars weg te steek.
Dit is onlangs (op 29 Maart) ontdek en bekend gemaak, en die aanval word steeds hanteer. Dit is egter vinnig onder beheer gebring, aangesien dit blykbaar slegs voorweergawes van 'n beperkte stel omgewings (DEB- en RPM-pakkette, vir die x86_64-argitektuur, en gebou met GCC) raak. Hoe dit ook al sy, die CVE is 'n gegee CVSS basistelling van 10, wat gereserveer is vir die mees kritieke kuberveiligheidskwesbaarhede. Indien dit stabiele verspreidings betree, sal die impak oorweldigend wees.
Die tegniese ontleding van die aanval, insluitend die xz agterdeur in diepte verduidelik, is elders geanaliseer. Hierdie plasing sal fokus op die tydlyn van die aanval, hoe dit opgespoor kon word, hoe die voorval tot op datum hanteer is, en watter lesse uit die aanval geleer kan word.
Die agterdeur se lang stert het voortgeduur ver na die aanvanklike opdatering. In Augustus 2025, meer as 'n jaar nadat CVE-2024-3094 bekend gemaak is, het sekuriteitsnavorsers by Binarly gevind dat die agterdeur steeds teenwoordig was in 'n dosyn Debian Docker-beelde wat op Docker Hub gepubliseer is, met Debian se span wat geweier het om hulle te verwyder en hulle as historiese ontwikkelingsartefakte eerder as aktiewe risiko behandel het. Afsonderlik, OpenSSF en OpenJS het kort na die XZ-voorval 'n gesamentlike waarskuwing uitgereik dat soortgelyke pogings tot oorname deur sosiale ingenieurswese reeds JavaScript-projekte geteiken het, wat daarop dui dat die onderhouer-trust-aanvalpatroon wat hier gebruik word, elders hergebruik word.
Hoe die XZ-agterdeur ingespuit is
Let wel: Die git-bewaarplek is in git.tukaani.org. Egter daar was ook 'n GitHub-gehuisveste bewaarplek (tans geblokkeer) waar die GitHub-rekening die veranderinge geplaas het wat later in die Git-bewaarplek geïntegreer is.
Een gedeelte van die agterdeur blyk slegs in die verspreide tarballs vir die 5.6.0 en 5.6.1 weergawes te wees, nie in die git repositories nie en maak staat op 'n enkele lyn in die build-to-host.m4 makro-lêer wat deur autoconf gebruik word. Die ander gedeelte was in twee sogenaamde toetslêers slegte-3-korrupte_lzma2.xx en goeie-groot_saamgeperste.lzma
dit was committed deur die GitHub-rekening “Jia Tan” (JiaT75) In die xz-bewaarplek op 23 Februarie. Dit was 'n onskadelike verandering om toetslêers by te voeg (vermoedelik .lzma en .xz saamgeperste blokke). Interessant genoeg is die toetslêers nie deur die toetse gebruik nie! Die lyn in die .m4-lêer spuit 'n verduisterde skrip (ingesluit in die tarball) in wat aan die einde van die konfigurasie uitgevoer moet word indien sommige voorwaardes ooreenstem. Dit wysig die Makefile vir die liblzma biblioteek om kode te bevat wat data uit die .xz-lêer onttrek, wat na deobfuskasie eindig in hierdie skrif, word aan die einde van die konfigurasie aangeroep. Dit besluit of die bouproses gewysig moet word om kode in te spuit: slegs onder GCC en die GCC-skakelaar, onder Debian of rpm, en slegs vir x86_64 Linux. Wanneer dit ooreenstem, onderskep die ingespuite kode die uitvoering deur twee te vervang. ifunc resolvers sodat sekere oproepe vervang word. Dit veroorsaak dat die simbooltabelle in die geheue ontleed word (dit neem tyd, wat tot die opsporing gelei het, soos later verduidelik).
Dan raak dinge interessant: Die agterdeur installeer 'n oudithaak in die dinamiese skakelaar en wag vir die RSA_public_decrypt-funksiesimbool om te arriveer, wat na 'n punt in die agterdeurkode herlei word, wat weer terugroep. libcrypto, vermoedelik om normale verifikasie uit te voer. En die vrag aktiveer as die lopende program die prosesnaam het. /usr/sbin/sshdDit was duidelik dat SSH-bedieners die teiken was. Tradisioneel, sshd bedieners soos OpenSSH was nie gekoppel aan liblzma, maar sshd is dikwels geplak om systemd-notify te ondersteun sodat ander dienste kan begin wanneer sshd loop. En dan word liblzma indirek gelaai deur systemd, die sirkel sluit.
Die agterdeur is nog nie volledig geanaliseer nie, maar dit lyk asof dit so is toelaat dat afstandopdragte uitgevoer word (RCE) met die voorregte van die sshd-daemon, wat in 'n voor-verifikasiekonteks loop. Inligting vanaf die afgeleë sertifikaat, wanneer dit deur die agterdeur ooreenstem, word met ChaCha20 ontsyfer, en wanneer dit suksesvol ontsyfer, word dit deurgegee aan die stelsel()So dit is in wese 'n beheerde RCE, baie erger as 'n blote publieke sleutel omseiling.
'n Latere 5.6.1-tarbal het addisionele pogings getoon om die spore weg te steek, verdere verduistering vir simboolname by te voeg, en probeer om die foute wat gesien is, reg te stel. verlengingsmeganisme waar addisionele toetslêers gesoek is vir sekere handtekeninge om by die agterdeur te voeg, is ook in plek gestel.
Hierdie redelik gesofistikeerde aanval kan ongemerk verbygaan totdat stabiele Linux-verspreidings bereik word. Gelukkig hou sommige mense daarvan om te kyk waarom abnormale dinge gebeur.
Die ontdekking van die XZ-agterdeuraanval
Baie keer word ingespuite kwaadwillige gedrag per toeval of ongeluk opgegrawe. 'n Goeie voorbeeld was 'n waarskuwing oor afkeuring (“Wie gee om vir waarskuwings?”) wat gelei het tot die ontdekking van die gebeurtenisstroom-aanval in Okt 2018. Nog een is die gebruiker wat gewaarsku het Codecov in April 2021 dat hul bash-oplaaierskrip nie die kontrolesom geslaag het nie (“Wie verifieer die integriteit van artefakte met kontrolesomme”?) Anomalieë en vreemde simptome met ssh logins (logins wat baie SVE-krag gebruik en verhoogde verlooptyd, valgrind-foute) het die nuuskierigheid van gewek Andres Freund, 'n waaksame PostgreSQL-ontwikkelaar, maar nie 'n sekuriteitsontleder nie (soos hy gesê hetNa 'n bietjie ondersoek met OpenSSH op Debian Sid, het hy tot die gevolgtrekking gekom dat 'n reaksietydprobleem op 'n biblioteek staatgemaak het, liblzma, Wat deel uitmaak van die xz-nuts kompressiebiblioteek. Die rede: “Die stroomop xz-bewaarplek en die xz-tarballe is agterdeur gebruikHierdie diagnose was so akkuraat! Op 29 Maart 2024 het Andres die eerste ontleding in Openwall geplaas: “agterdeur in stroomop xz/liblzma wat lei tot ssh-bedienerkompromie". Die feit: XZ Utils 5.6.0 en 5.6.1 tarballs bevat 'n agterdeur. Hierdie tarballs is geskep en onderteken deur die voorgenoemde Jia Tan-rekening. He geplaas in Mastodon later daardie dag, en erken dat die ontdekking toevallig was en baie toevallighede vereis het. Die kommentaar van ander gebruikers is die moeite werd om te lees. GitHub-gebruiker dieselfdesam (ook bekend as Sam James) het 'n mooi Gist gepubliseer Gereelde vrae oor die xz-utils-agterdeur waar die aanval opgesom is, wat verband hou met meer diepgaande ontledings van die aanvalsvrag. Hierdie ontledings was tegnies sappig en het ons gehelp om die inspuiting, wat hoogs uitgebreid was, beter te verstaan:- xz/liblzma: Verduistering van die Bash-stadiumMooi analise oor die deobfuskasie deur die inspuitingskrip, in vier "stadiums".
- Filippo Valsorda se blouhemel-draad Analise van die agterdeur self in RSA_public_decrypt, wat die aard daarvan toon: 'n RCE, nie 'n magtigingsomleiding nie, en 'n poort (aanvaar die outeur se privaat sleutel en indien nie, keer dit terug na normale gedrag) / onterugbetaalbaar. Die outeur het beoog om lae profiel te bly om opsporing te vermy!
- XZ Agterdeur Analise deur @smx-smx (WIP) – Bykomende ontleding van die agterdeur (ek het amper aan die begin verdwaal 😀)
- xz agterdeur dokumentasie wiki, nog 'n analise van die 5.6.1 inspuitingskrip.
Hoe die voorval hanteer is
Openbaarmaking deur Andreas Freund was versigtig omdat, in sy eie woorde:“Gegewe die oënskynlike betrokkenheid van die stroomop-platform, het ek nie 'n stroomop-fout aangemeld nie. Aangesien ek aanvanklik gedink het dit was 'n Debian-spesifieke probleem, het ek 'n meer voorlopige verslag na security@...ian.org gestuur. Daarna het ek die probleem na distros@ aangemeld. CISA is deur 'n verspreiding in kennis gestel.”
Wie is onder die aanval?
Óf die GitHub JiaT75-rekening is gekompromitteer (onthou dat GitHub onlangs 2FA verpligtend gemaak het) óf die fisiese gebruiker wat die rekening besit, het na die donker kant gegaan. Maar daar is dwingende redes om te dink aan 'n gevorderde aanhoudende bedreiging (APT), miskien staatsgesteund, as gevolg van die tegniese gesofistikeerdheid van die aanval. Verdere ondersoek deur kuberveiligheidsagentskappe en wetstoepassing sal wys ... Hierdie inskrywing in YCombinator Hacker Nuus oor Jia Tan werp lig op die "wie" en sy aktiwiteit. Aanbeveel! Dit gee baie inligting oor hoe die slegte ouens ander gebruikers probeer mislei deur sosiale manipulasie te gebruik.“Baie irriterend - die oënskynlike outeur van die agterdeur was vir etlike weke in kommunikasie met my (rwmj) om xz 5.6.x by Fedora 40 & 41 te voeg as gevolg van die "wonderlike nuwe kenmerke". Ons het selfs saam met hom gewerk om die valgrind-probleem op te los (wat nou blykbaar veroorsaak is deur die agterdeur wat hy bygevoeg het). Ons moes gisteraand jaag om die probleem op te los na 'n onbedoelde onderbreking van die embargo. Hy is al 2 jaar deel van die xz-projek en het allerhande binêre toetslêers bygevoeg, en om eerlik te wees met hierdie vlak van gesofistikeerdheid, sou ek agterdogtig wees teenoor selfs ouer weergawes van xz totdat die teendeel bewys word.”
Jia Tan het maatreëls getref om te verhoed dat dit opgespoor word: Dit lyk asof dit VPN (vpn.singapore.witopia.net) gebruik het om te konnekteer – wat op sigself aanvaarbaar is. En baie veranderinge blyk gerugsteun te word deur tydelike, eenmalige e-posse (van ProtonMail in hierdie geval) wat aandring om veranderinge saam te voeg.
Die akteur mag dalk van plan wees om selfs dieper te gaan, tot by die Linux-kern, as die bydraer tot die xy-ingebed projek. 'n Aanvanklike analise het geen bewyse van 'n miskraam gevind nie, tot vandag toe.
Let wel: nog een laeprofiel XZ-bydraer “Hans Jansen“ (GitHub-gebruiker “hansjans162”) is onder oorsigSy rekening by Debian is nou geblokkeerHy het baie opdaterings aan Debian Games gemaak om die een wat hy op debian/xz-utils wou hê, te verberg, 'n opdatering na upstream 5.6.1 om die verspreiding van die agterdeur te bespoedig. debian/onstabiel.
Al wat ons vir nou kan sê, is dat hierdie 'n (nog ongeïdentifiseerde) APT is wat verskillende rekeninge gebruik, vir ten minste twee jaar aan hierdie veldtog werk, en geduldig werk om 'n RCE in SSH te implanteer.
Ten tyde van hierdie skrywe is die identiteit agter "Jia Tan" steeds onbevestig. Geen geloofwaardige toeskrywing aan 'n spesifieke individu, organisasie of staatsakteur is in die openbaar bevestig nie, wat bevestig hoe doeltreffend die persona se operasionele dissipline was.
Was die XZ-agterdeuraanval voorkombaar?
Nogal moeilik.
Eerstens het 'n deel van die ingespuite agterdeur in saamgeperste toetslêers beland wat nie deur toetse gebruik is nie. Terugskouend kan dit 'n paar (lawaaierige) alarms veroorsaak, maar wie gee om om te kontroleer dat alle toetslêers deur werklike toetse in die werklike wêreld gebruik word? Tweedens het 'n deel van die ingespuite agterdeur in makro-lêers in die vrygestelde tarballs beland, en dit is moeilik om handmatig te kyk vir verskille met die verwagte tarballs. Outomatisering is ook kompleks, aangesien die verwagte resultaat van die bou self (vir enigiemand wat weet hoe automake/autoconf werk) moeilik is om te modelleer om te analiseer of die werklike tarball aan die verwagtinge voldoen. Sommige het dit gestel as "Die tarballs wat nie ooreenstem met die git-boom nie, is 'n kenmerk, nie 'n fout nie"Die herkoms van binêre teerballe vanaf sy bronkode is 'n onopgeloste probleem.
Gebruikersreputasie? Wel, die JiaTan75 GitHub-rekening het volgens die verlede nie skelm dinge gedoen nie. commits. Dit is eers opgeskort nadat die bewyse opgehoop het, maar tot 29 Maart was dit 'n gereelde gebruiker wat normale werk gedoen het. Wel, nie so normaal nie. Later commits (hierdie, hierdie, hierdie, en hierdie wat die ontginningskode aangepas het) het probeer om die valgrind-foute en -ineenstortings in sommige konfigurasies reg te stel, as gevolg van verskille met die stapeluitleg wat deur die agterdeur verwag word. Commit resensies kan dit opspoor, maar wie het die geduld om veranderinge in 'n binêre toetslêer of die werklike motivering vir 'n verandering in GCC-kenmerke in C-bronkode te analiseer?
Moet mens alarm maak wanneer 'n SSH login neem 800 ms in plaas van 300 ms? Waarskynlik sal net hiper-versigtige mense dit raaksien. Cicero het gesê, "Onbesonnenheid behoort tot die jeug; versigtigheid tot die ouderdom."
Die ifunc-infrastruktuur is in Junie 2023 deur “Hans Jansen” en “Jia Tan” bygevoeg. Dit is die eerste commit voeg ifunc-ondersteuning by crc64_fast.c (later gebruik om die agterdeur te inspuit). Maande voor die inspuiting van die agterdeur-binêre lêers in die toetslêers!
Let wel: Outeur en commitdaar verskil hier, maar dis normaal: Lasse Collin is die projekonderhouer, en hy het die veranderinge saamgevoeg. Hy bedank selfs “Hans Jansen” …
Niemand het kommer uitgespreek voor Andres Freund se plasing en die CVE wat deur RedHat geskep is nie. As jy 'n reeks gereedskap sien wat dit sou opspoor, sal hulle die betrokke komponent nou opspoor. ex post facto.
Die beste voorkoming het waarskynlik gekom van die aard van Linux-verspreidings, en hoe onstabiele, moderne weergawes slegs na 'n vinnige proses na stabiele verspreidings stroomaf oorgedra word.
Lesse geleer uit XZ bBackdoor-aanval
Ons het opgemerk hoe moeilik dit is om op te spoor opsetlike Agterdeure. Agterdeure moet as 'n interne bedreiging beskou word, aangesien hulle deur interne personeel of via gekompromitteerde interne rekeninge geplant word. En daardie ouens word meestal vertrou. En wanneer die agterdeur in die verspreide artefak ingeplant word, maak dit dit moeiliker om op te spoor.
Sommige skrywers soos Kevin Beaumont na gewys het stelsel, wat 'n groot aanvalsoppervlak van derdepartydienste na agterdeur oopmaak. Dit is wat die slegte akteur hier misbruik het. Systemd het baie oogballe, maar XZ is 'n obskure biblioteek op in die ketting. "Wanneer die stroomop besmet is, drink almal vergiftigde water stroomaf".
'n Onverwante veranderingsversoek in die stelsel vir laai kompressiebiblioteke dinamies, wat die agterdeur sou verwyder, is reeds in die stelsel saamgevoeg, maar nog nie afgelewer nie. Die ekstra afhanklikhede wat deur libsystemd ingestel word, kan die bron van kwesbaarhede wees., en gister hierdie versoek is oopgemaak.
A kommentaar lewer in die "xz: Deaktiveer ifunc om probleem op te los" commit het 'n skerp insig gegee oor waar om die fokus te plaas as ons sulke aktiwiteite wil voorkom (klem is myne):
"Die les wat ons as gemeenskap moet leer, is meer om te verseker software supply chain security holisties, ouditering van boustelsels wat verder strek as net bronkode. Soos die SolarWinds-oortreding waar aanvallers sagteware-opdaterings vir SolarWinds se geslote-bron moniteringsagteware-aanbod gewysig het.”
FAQ
Is die XZ-agterdeur vandag nog 'n risiko?
Meestal onder beheer, maar nie heeltemal weg nie. In Augustus 2025 het navorsers gevind dat die agterdeur steeds teenwoordig is in verskeie Debian Docker Hub-beelde, wat deur Debian as onaktiewe historiese artefakte behandel word. Spanne moet verifieer dat hulle nie op verouderde, ongepatcheerde basisbeelde bou nie, eerder as om aan te neem dat die 2024-patch die deur heeltemal toegemaak het.
