Bakdøring med SSH
En ondsinnet eller kompromittert vedlikeholder la inn ondsinnet oppførsel i et bibliotek med navnet liblzma, en del av xz-komprimeringsverktøyene og -bibliotekene, noe som resulterer i en bakdør i SSH. Dette er et avansert programvareforsyningskjedeangrep, ettersom biblioteket ble bevisst modifisert for bakdøren, med obfuskasjons- og stealth-teknikker for å skjule angrepsnyttelasten fra anmeldere.
Det ble oppdaget og avslørt nylig (den 29. mars), og håndteringen av angrepet pågår fortsatt. Det ble imidlertid raskt begrenset, da det ser ut til å bare påvirke forhåndsversjoner av et begrenset sett med miljøer (DEB- og RPM-pakker, for x86_64-arkitekturen, og bygget med GCC). Uansett, den CVE ble gitt en CVSS basispoengsum av 10, som er reservert for de mest kritiske sårbarhetene i nettsikkerheten. Skulle den komme inn i stabile distribusjoner, ville virkningen være overveldende.
Den tekniske analysen av angrepet, inkludert xz bakdør forklart i dybden, ble analysert andre steder. Dette innlegget vil fokusere på tidslinjen for angrepet, hvordan det kunne oppdages, hvordan hendelsen ble håndtert frem til nå, og hvilke lærdommer som kan trekkes fra angrepet.
Bakdørens lange hale har fortsatt godt etter den første oppdateringen. I august 2025, over et år etter at CVE-2024-3094 ble avslørt, fant sikkerhetsforskere hos Binarly bakdøren fortsatt tilstede i et dusin Debian Docker-bilder publisert på Docker Hub, og Debians team nektet å fjerne dem, og behandlet dem som historiske utviklingsartefakter snarere enn aktiv risiko. Separat, OpenSSF og OpenJS utstedte en felles advarsel kort tid etter XZ-hendelsen om at lignende forsøk på sosial manipulering allerede hadde rettet seg mot JavaScript-prosjekter, noe som tyder på at vedlikeholder-tillits-angrepsmønsteret som brukes her, blir gjenbrukt andre steder.
Hvordan XZ-bakdøren ble injisert
Merk: Git-depotet er i git.tukaani.org. Imidlertid det var også en GitHub-hostet repository (for øyeblikket blokkert) der GitHub-kontoen publiserte endringene som senere ble integrert i Git-repositoriet.
En del av bakdøren ser ut til å bare være i de distribuerte tarballene for 5.6.0- og 5.6.1-versjonene, ikke i git-repositoriene og er avhengig av en enkelt linje i build-to-host.m4 makrofil brukt av autoconf. Den andre delen var i to antatte testfiler bad-3-corrupt_lzma2.xx og god-stor_komprimert.lzma
som var committed av GitHub-kontoen «Jia Tan» (JiaT75) I xz-depotet 23. februar. Det var en uskyldig endring som la til testfiler (angivelig .lzma og .xz komprimerte blokker). Interessant nok ble ikke testfilene brukt av testene! Linjen i .m4-filen injiserer et obfuskert skript (inkludert i tarballen) som skal kjøres på slutten av konfigurasjonen hvis noen betingelser samsvarer. Den endrer Makefile for liblzma biblioteket som inneholder kode som trekker ut data fra .xz-filen, som etter at deobfuskeringen er avsluttet i dette manuset, kalles på slutten av konfigurasjonen. Den bestemmer om byggeprosessen skal modifiseres for å injisere kode: bare under GCC og GCC-lenkeren, under Debian eller rpm, og bare for x86_64 Linux. Når den matches, avskjærer den injiserte koden kjøringen ved å erstatte to ifunc resolvere slik at visse kall erstattes. Dette fører til at symboltabellene analyseres i minnet (dette tar tid, noe som førte til deteksjonen, som forklart senere).
Så blir det interessant: Bakdøren installerer en revisjonshook i den dynamiske linkeren, og venter på at RSA_public_decrypt-funksjonssymbolet skal ankomme, som blir omdirigert til et punkt i bakdørskoden, som igjen kaller tilbake. libcrypto, antagelig for å utføre normal autentisering. Og nyttelasten aktiveres hvis det kjørende programmet har prosessnavnet /usr/sbin/sshdDet var tydelig at SSH-servere var målet. Tradisjonelt sett, sshd servere som OpenSSH var ikke koblet til liblzma, men sshd er ofte lappet for å støtte systemd-notify slik at andre tjenester kan starte når sshd kjører. Og deretter lastes liblzma indirekte av systemd, slutter sirkelen.
Bakdøren er ikke fullstendig analysert ennå, men det ser ut til å være det tillater fjernutførelse av kommandoer (RCE) med rettighetene til sshd-daemonen, som kjører i en forhåndsautentiseringskontekst. Informasjon fra det eksterne sertifikatet, når det matches av bakdøren, dekrypteres med ChaCha20, og når dekrypteringen er vellykket, sendes den til system()Så dette er i hovedsak en gated RCE, mye verre enn bare en omgåelse av offentlig nøkkel.
En senere 5.6.1-tarball viste ytterligere forsøk på å skjule sporene, legge til ytterligere tilsløring av symbolnavn og forsøk på å rette opp feilene som ble observert. forlengelsesmekanisme der det ble lette etter ytterligere testfiler for bestemte signaturer for å legge til bakdøren, ble det også satt på plass.
Dette ganske sofistikerte angrepet kan gå ubemerket hen inntil stabile Linux-distribusjoner er nådd. Heldigvis liker noen å sjekke hvorfor unormale ting skjer.
Oppdagelsen av XZ-bakdørangrepet
Mange ganger avdekkes injisert ondsinnet oppførsel ved en tilfeldighet eller uhell. Et godt eksempel var en advarsel om avskrivning («Hvem bryr seg om advarsler?») som førte til oppdagelsen av hendelsesstrømangrep i oktober 2018. En annen er brukeren som advarte Codecov i april 2021 at bash-opplastingsskriptet deres ikke bestod sjekksummen («Hvem verifiserer integriteten til artefakter med sjekksummer»?) Anomalier og merkelige symptomer med ssh logins (logins som bruker mye CPU og øker tiden som har gått, valgrind-feil) vekket nysgjerrigheten til Andres Freund, en årvåken PostgreSQL-utvikler, men ikke en sikkerhetsanalytiker (som han uttalteEtter litt undersøkelser med OpenSSH på Debian Sid, konkluderte han med at et responstidsproblem var avhengig av et bibliotek, liblzma, En del av xz-utils komprimeringsbibliotek. Årsaken: «Oppstrøms xz-depotet og xz-tarballene har blitt bakdøret«Denne diagnosen var så nøyaktig!» Den 29. mars 2024 publiserte Andres den første analysen i Openwall: «bakdør i oppstrøms xz/liblzma som fører til kompromittering av SSH-serverFaktum: XZ Utils 5.6.0 og 5.6.1 tarballer inneholder en bakdør. Disse tarballene ble opprettet og signert av den nevnte Jia Tan-kontoen. He postet i Mastodon senere samme dag, og erkjente at oppdagelsen var tilfeldig og krevde mange tilfeldigheter. Kommentarene fra andre brukere er verdt å lese. GitHub-bruker sammesam (også kjent som Sam James) publiserte en fin Gist Vanlige spørsmål om xz-utils-bakdøren hvor angrepet ble oppsummert, med kobling til mer dyptgående analyser av angrepsnyttelasten. Disse analysene var teknisk sett saftige, og hjalp oss å bedre forstå injeksjonen, som var svært detaljert:- xz/liblzma: Forklaring av obfuskasjon i bash-stadietFin analyse av deobfuskeringen av injeksjonsskriptet, i fire «stadier».
- Filippo Valsordas bluesky-tråd Analyse av selve bakdøren i RSA_public_decrypt, som viser dens natur: en RCE, ikke autentiseringsomgåelse, og portet (aksepterer forfatterens private nøkkel og hvis ikke, går tilbake til normal oppførsel) / ikke tilbakebetales. Forfatteren hadde til hensikt å holde seg lavprofilert for å unngå oppdagelse!
- XZ-bakdørsanalyse av @smx-smx (pågående arbeid) – Ytterligere analyse av bakdøren (jeg gikk meg nesten vill i starten 😀)
- xz bakdør dokumentasjonswiki, en annen analyse av 5.6.1-injeksjonsskriptet.
Hvordan hendelsen ble håndtert
Andreas Freunds avsløring var forsiktig fordi, med hans egne ord:«Gitt den tilsynelatende oppstrøms involveringen, har jeg ikke rapportert en oppstrømsfeil. Siden jeg først trodde det var et Debian-spesifikt problem, sendte jeg en mer foreløpig rapport til security@...ian.org. Deretter rapporterte jeg problemet til distros@. CISA ble varslet via en utdeling.
Hvem er under angrepet?
Enten ble GitHub JiaT75-kontoen kompromittert (husk at GitHub nylig påla 2FA), eller så gikk den fysiske brukeren som eide kontoen over til den mørke siden. Men det er overbevisende grunner til å tenke på en avansert vedvarende trussel (APT), kanskje statsstøttet, på grunn av angrepets tekniske kompleksitet. Videre etterforskning fra nettsikkerhetsbyråer og politi vil vise … Denne oppføringen i YCombinator Hacker-nyheter om Jia Tan kaster litt lys over «hvem» og hans aktivitet. Anbefales! Den gir mye informasjon om hvordan skurkene prøver å lure andre brukere ved hjelp av sosial manipulering.«Veldig irriterende – den tilsynelatende forfatteren av bakdøren kommuniserte med meg (rwmj) i flere uker og prøvde å få xz 5.6.x lagt til Fedora 40 og 41 på grunn av de «flotte nye funksjonene». Vi jobbet til og med med ham for å fikse valgrind-problemet (som det nå viser seg var forårsaket av bakdøren han hadde lagt til). Vi måtte kjempe i går kveld for å fikse problemet etter et utilsiktet brudd på embargoen. Han har vært en del av xz-prosjektet i to år og lagt til alle slags binære testfiler, og for å være ærlig med dette nivået av raffinement ville jeg vært mistenksom overfor enda eldre versjoner av xz inntil det motsatte er bevist.»
Jia Tan tok grep for å forhindre sporing: Den ser ut til å ha brukt VPN (vpn.singapore.witopia.net) for å koble til – noe som i seg selv er greit. Og mange endringer ser ut til å være støttet av midlertidige e-poster for én gangs bruk (fra ProtonMail i dette tilfellet) som oppfordrer til å slå sammen endringer.
Aktøren har kanskje tenkt å gå enda dypere, helt opp til Linux-kjernen, som bidragsyter til xy-embedded prosjekt. En innledende analyse fant ingen tegn til spontanabort, per i dag.
Merk: en annen den lavprofilerte XZ-bidragsyteren «Hans Jansen» (GitHub-brukeren «hansjans162») er under granskningKontoen deres hos Debian er nå blokkertHan gjorde mange oppdateringer til Debian Games for å skjule den han ville ha på debian/xz-utils, en oppdatering til oppstrøms 5.6.1 for å fremskynde distribusjonen av bakdøren til debian/ustabil.
Alt vi kan si foreløpig er at dette er en (foreløpig uidentifisert) APT som bruker forskjellige kontoer, som har jobbet i minst to år med denne kampanjen, og som tålmodig jobber med å implantere en RCE i SSH.
I skrivende stund er identiteten bak «Jia Tan» fortsatt ubekreftet. Ingen troverdig henvisning til en spesifikk person, organisasjon eller statlig aktør har blitt offentlig bekreftet, noe som forsterker hvor effektiv personens operative disiplin var.
Var XZ-bakdørsangrepet forhindret?
Ganske vanskelig.
For det første kom deler av den injiserte bakdøren inn i komprimerte testfiler som ikke ble brukt av tester. I ettertid kan det utløse noen (støyende) alarmer, men hvem bryr seg om å sjekke at alle testfiler brukes av faktiske tester i den virkelige verden? For det andre kom deler av den injiserte bakdøren inn i makrofiler i de utgitte tarballene, og det er vanskelig å sjekke manuelt for forskjeller med de forventede tarballene. Automatisering er også komplekst, ettersom det forventede resultatet fra selve byggingen (for alle som vet hvordan automake/autoconf fungerer) er vanskelig å modellere for å analysere om den virkelige tarballen samsvarer med forventningene. Noen stilte det opp as «At tarballene ikke samsvarer med git-treet er en funksjon, ikke en feil»Opprinnelsen til binære tarballer fra kildekoden er et løst problem.
Brukerens omdømme? Vel, JiaTan75 GitHub-kontoen gjorde ikke useriøse ting i henhold til tidligere commits. Den ble suspendert først etter at bevisene hadde samlet seg, men frem til 29. mars var det en vanlig bruker som utførte normal virksomhet. Vel, ikke så normalt. Senere commits (denne, denne, denneog denne som justerte utnyttelseskoden) prøvde å fikse valgrind-feilene og krasjene i noen konfigurasjoner, på grunn av forskjeller med stakkoppsettet som forventes av bakdøren. Commit anmeldelser kunne oppdage dette, men hvem har tålmodighet til å analysere endringer i en binær testfil eller den virkelige motivasjonen for en endring i GCC-attributter i C-kildekoden?
Bør man slå alarm når en SSH login tar 800 ms i stedet for 300 ms? Sannsynligvis bare hyperforsiktige personer ville legge merke til det. Cicero sa, «Utfordringsfullhet hører ungdommen til, klokskap alderdommen.»
ifunc-infrastrukturen ble lagt til i juni 2023 av «Hans Jansen» og «Jia Tan». Dette er den første commit legger til ifunc-støtte til crc64_fast.c (senere brukt til å injisere bakdøren). Måneder før injisering av bakdørsbinærfilene i testfilene!
Merk: Forfatter og commitDet er annerledes her, men dette er normalt: Lasse Collin er prosjektvedlikeholderen, og han slo sammen endringene. Han takker til og med «Hans Jansen» …
Ingen uttrykte bekymringer før Andres Freunds innlegg og CVE-en laget av RedHat. Hvis du ser en rekke verktøy som ville fanget opp dette, oppdager de den berørte komponenten nå. ex post facto.
Sannsynligvis kom den beste forebyggingen fra Linux-distribusjonenes natur, og hvordan ustabile, moderne versjoner bare overføres til stabile distribusjoner nedstrøms etter en tempobasert prosess.
Lærdommer fra XZ bBackdoor-angrepet
Vi har lagt merke til hvor vanskelig det er å oppdage tilsiktet bakdører. Bakdører bør betraktes som en intern trussel, ettersom de er plantet av internt personale eller via kompromitterte interne kontoer. Og disse karene er stort sett klarerte. Og når bakdøren er implantert i den distribuerte artefakten, gjør det den vanskeligere å oppdage.
Noen forfattere som Kevin Beaumont pekte på system, som åpner en stor angrepsflate for tredjepartstjenester til bakdører. Dette er hva den onde aktøren misbrukte her. Systemd har mange øyne, men XZ er et obskurt bibliotek oppover i kjeden. «Når oppstrøms er forurenset, drikker alle forgiftet vann nedstrøms».
En urelatert endringsforespørsel i systemet for dynamisk lasting av komprimeringsbiblioteker, som ville fjerne bakdøren, var allerede slått sammen med systemet, men ikke levert ennå. De ekstra avhengighetene som introduseres av libsystemd kan være kilden til sårbarheter, og i går denne forespørselen ble åpnet.
A kommentere i «xz: Deaktiver ifunc for å fikse problemet» commit ga et skarpt innblikk i hvor vi bør fokusere hvis vi ønsker å forhindre slik aktivitet (min utheving):
«Lærdommen vi bør lære som samfunn er mer å sikre software supply chain security helhetlig, revisjon av byggesystemer utover bare kildekode. Som SolarWinds-bruddet der angripere modifiserte programvareoppdateringer for SolarWinds' lukkede overvåkingsprogramvaretilbud.»
FAQ
Er XZ-bakdøren fortsatt en risiko i dag?
Stort sett inndæmmet, men ikke helt borte. I august 2025 fant forskere bakdøren fortsatt tilstede i flere Debian Docker Hub-avbildninger, behandlet av Debian som inaktive historiske artefakter. Team bør bekrefte at de ikke bygger på utdaterte, uoppdaterte basisavbildninger i stedet for å anta at 2024-oppdateringen lukket døren fullstendig.
