SSH hátsó ajtón keresztül
Egy rosszindulatú vagy feltört karbantartó rosszindulatú viselkedést hajtott végre a következő nevű könyvtárban: liblzma, az xz tömörítőeszközök és könyvtárak része, ami egy hátsó ajtót eredményezett SSH-ban. Ez egy fejlett szoftverellátási lánc támadás, mivel a könyvtárat szándékosan módosították a hátsó ajtóhoz, obfuszkálási és lopakodó technikákkal elrejtve a támadási adatokat a felülvizsgálók elől.
Nemrégiben (március 29-e után) fedezték fel és hozták nyilvánosságra, és a támadás kezelése folyamatban van. A támadást azonban gyorsan sikerült megfékezni, mivel úgy tűnik, hogy csak korlátozott számú környezet (DEB és RPM csomagok, x86_64 architektúrához, és GCC-vel készült) kiadás előtti verzióit érinti. Mindenesetre a CVE kapott egy CVSS alappontszám 10-es érték, amely a legkritikusabb kiberbiztonsági sebezhetőségekre van fenntartva. Ha stabil disztribúciókba kerül, a hatása elsöprő lenne.
A támadás technikai elemzése, beleértve a Az xz hátsó ajtó részletes magyarázata, máshol már elemezték. Ez a bejegyzés a támadás idővonalára, annak észlelésére, az incidens naprakész kezelésére és a támadásból levonható tanulságokra összpontosít.
A hátsó ajtó hosszú farka jóval a kezdeti javítás után is folytatódott. 2025 augusztusában, több mint egy évvel a CVE-2024-3094 felfedése után, a Binarly biztonsági kutatói azt találták, hogy a hátsó ajtó még mindig jelen van egy tucat Debian Docker képben, amelyet a Docker Hubon tettek közzé, mivel a Debian csapata nem volt hajlandó eltávolítani ezeket, inkább történelmi fejlesztési műtermékként, mint aktív kockázatként kezelve azokat. Különben, OpenSSF és az OpenJS közös figyelmeztetést adott ki röviddel az XZ incidens után, miszerint hasonló szociális mérnöki alapú felvásárlási kísérletek már célba vettek JavaScript projekteket, ami arra utal, hogy az itt használt karbantartói bizalom támadási mintát máshol is újra felhasználják.
Hogyan fecskendezték be az XZ hátsó ajtót
Megjegyzés: A git repository itt található: git.tukaani.org. Azonban, volt egy GitHub által üzemeltetett adattár (jelenleg blokkolva), ahol a GitHub-fiók közzétette a később a Git-tárházba integrált módosításokat.
A hátsó ajtó egy része úgy tűnik, hogy csak az 5.6.0 és 5.6.1 verziók elosztott tarballjaiban található meg, a git repository-kban nem, és egy egyetlen sor a build-to-host.m4 fájlban az autoconf által használt makrófájl. A másik rész két feltételezett tesztfájlban volt. bad-3-corrupt_lzma2.xz és a jó-nagy_tömörített.lzma
az volt committed a „Jia Tan” GitHub fiók által (JiaT75) ban,-ben xz adattár február 23-án. Ez egy ártalmatlan változtatás volt, ami tesztfájlokat adott hozzá (állítólag .lzma és .xz tömörített blokkokat). Érdekes módon a tesztfájlokat nem használták a tesztek! Az .m4 fájlban található sor egy obfuszkált szkriptet (amely a tarballban található) injektál, amely a configure végén végrehajtódik, ha bizonyos feltételek teljesülnek. Módosítja a Makefile-t a következőhöz: liblzma könyvtár, amely olyan kódot tartalmaz, amely adatokat nyer ki az .xz fájlból, és a deobfuszkáció után véget ér ebben a szkriptben, a configure végén kerül meghívásra. Eldönti, hogy módosítsa-e a fordítási folyamatot a kód befecskendezéséhez: csak GCC és a GCC linker alatt, Debian vagy rpm alatt, és csak x86_64 Linux alatt. Egyezés esetén a befecskendezett kód két elemet helyettesít a végrehajtás során. ifunc feloldók, így bizonyos hívások lecserélődnek. Ez a szimbólumtáblák memória-elemzését okozza (ez időt vesz igénybe, ami a későbbiekben ismertetett módon az észleléshez vezetett).
Aztán érdekessé válik a dolog: A hátsó ajtó egy audit hook-ot telepít a dinamikus linkerbe, várva az RSA_public_decrypt függvény szimbólumának megérkezését, amelyet átirányít a hátsó ajtó kódjában lévő pontra, amely viszont visszahívja a libcrypto, feltehetően a normál hitelesítés végrehajtásához. És a hasznos adat akkor aktiválódik, ha a futó program rendelkezik a folyamatnévvel /usr/sbin/sshdEgyértelmű volt, hogy az SSH szerverek voltak a célpontok. Hagyományosan, sshd olyan szerverek, mint az OpenSSH, nem voltak összekapcsolva liblzma, de az sshd az gyakran foltozott hogy támogassa a systemd-notify-t, így más szolgáltatások is elindulhatnak, amikor az sshd fut. Ezután a liblzma közvetve betöltődik a systemd, bezárva a kört.
A hátsó ajtót még nem elemezték teljesen, de úgy tűnik, igen. távoli parancsfuttatás engedélyezése (RCE) az sshd démon jogosultságaival, egy előhitelesítési környezetben fut. A távoli tanúsítványból származó információkat, amikor a hátsó ajtó egyezik velük, a ChaCha20 segítségével dekódolja, és sikeres dekódolás esetén továbbítja a rendszer()Tehát ez lényegében egy kapuzott RCE, sokkal rosszabb, mint egy egyszerű nyilvános kulcsú megkerülő támadás.
Egy későbbi 5.6.1-es tarball további erőfeszítéseket mutatott be a nyomok elrejtésére, a szimbólumnevek további obfuszkálását és a tapasztalt hibák kijavítását. hosszabbító mechanizmus ahol további tesztfájlokat kerestek bizonyos aláírások után kutatva a hátsó ajtóhoz való hozzáadáshoz, szintén bevezetésre került.
Ez a meglehetősen kifinomult támadás észrevétlen maradhat, amíg stabil Linux disztribúciók nem elérhetők. Szerencsére egyesek szeretik ellenőrizni, hogy miért történnek rendellenes dolgok.
Az XZ hátsó ajtós támadás felfedezése
Sokszor a beágyazott rosszindulatú viselkedés véletlenül vagy véletlen balesetből kerül napvilágra. Jó példa erre egy elavulási figyelmeztetés („Kit érdekelnek a figyelmeztetések?”), ami a felfedezéséhez vezetett eseményfolyam-támadás 2018 októberében. Egy másik felhasználó figyelmeztetett Codecov 2021 áprilisában a bash feltöltő szkriptjük nem ment át az ellenőrzőösszegen („Ki ellenőrzi az ellenőrzőösszegekkel a műtermékek integritását?”) SSH-val kapcsolatos rendellenességek és furcsa tünetek logins (loginsok CPU-t igényel és megnöveli az eltelt időt, valgrind hibákat okoz) felkeltette a kíváncsiságot Andres Freund, egy éber PostgreSQL fejlesztő, de nem biztonsági elemző (ahogy állította). Miután némi vizsgálatot végzett az OpenSSH-val Debian Sid-en, arra a következtetésre jutott, hogy a válaszidő problémája egy könyvtáron múlik, liblzma, része a xz-utils tömörítőkönyvtár. Az ok: „az upstream xz repository és az xz tarball fájlok hátsó ajtóval lettek ellátva„Ez a diagnózis annyira pontos volt!” 2024. március 29-én Andres közzétette az Openwallban az első elemzést: „hátsó ajtó az xz/liblzma upstream ágában, ami ssh szerver feltörését okozza„A tény: Az XZ Utils 5.6.0 és 5.6.1 tarballjai hátsó ajtót tartalmaznak. Ezeket a tarballokat a fent említett Jia Tan fiók hozta létre és írta alá. He Mastodonban közzétéve később, még aznap, felismerve, hogy a felfedezés véletlen volt, és sok véletlen egybeesésre volt szükség. Érdemes elolvasni a többi felhasználó hozzászólásait is. GitHub felhasználó ugyanazok (más néven Sam James) közzétett egy szép összefoglalót GYIK az xz-utils hátsó ajtóval kapcsolatban ahol a támadást összefoglalták, és további linkeket is tartalmaztak mélyreható elemzéseket a támadás hasznos teherének. Ezek az elemzések technikailag tartalmasak voltak, és segítettek jobban megérteni a rendkívül kidolgozott injekciót:- xz/liblzma: Bash-fázisú obfuszkáció magyarázataSzép elemzés a befecskendező szkript általi deobfuszkációról, négy „szakaszban”.
- Filippo Valsorda kékeszöld szála Magának a hátsó ajtónak az RSA_public_decrypt fájlban történő elemzése, amely bemutatja a természetét: egy RCE, nem hitelesítés-megkerülő, és kapuzott (elfogadja a szerző privát kulcsát, és ha nem, akkor visszatér a normál viselkedéshez) / nem fizethető ki. A szerző szándékosan titokban tartotta magát, hogy elkerülje az észlelést!
- XZ hátsó ajtó elemzés @smx-smx által (folyamatban lévő gyártás) – A hátsó ajtó további elemzése (majdnem az elején elvesztettem a fonalat 😀)
- xz hátsó ajtó dokumentáció wiki, az 5.6.1-es injektálási szkript egy másik elemzése.
Hogyan kezelték az incidenst
Andreas Freund óvatosan fogalmazott a nyilvánosságra hozatalával, mert saját szavaival élve:„Tekintettel a látszólagos upstream érintettségre, nem jelentettem upstream hibát. Mivel kezdetben azt hittem, hogy ez egy Debian-specifikus probléma, egy előzetesebb jelentést küldtem a security@...ian.org címre. Ezt követően jelentettem a problémát a distros@ címre.” CIS„A-t egy elosztás értesítette.”
Ki van támadás alatt?
Vagy a GitHub JiaT75 fiókot lopták fel (ne feledjük, hogy a GitHub nemrégiben kötelezővé tette a 2FA-t), vagy a fiók fizikai tulajdonosa átállt a sötét oldalra. De nyomós okok vannak arra, hogy egy fejlett, esetleg államilag támogatott perzisztens fenyegetésre (APT) gondoljunk a támadás technikai kifinomultsága miatt. A kiberbiztonsági ügynökségek és a bűnüldöző szervek további vizsgálata fogja megmondani… Ez a bejegyzés A YCombinator Hacker hírekben Jia Tanról Rávilágít a kilétére és a tevékenységére. Ajánlott! Sok információt nyújt arról, hogyan próbálják a rosszfiúk megtéveszteni a többi felhasználót a társadalmi manipuláció segítségével.„Nagyon bosszantó – a hátsó ajtó látszólagos szerzője több héten keresztül kommunikált velem (rwmj), hogy az xz 5.6.x-et hozzátegyék a Fedora 40-hez és 41-hez a „nagyszerű új funkciói” miatt. Még a valgrind probléma megoldásán is dolgoztunk vele (amiről most kiderült, hogy az általa hozzáadott hátsó ajtó okozta). Tegnap este rohannunk kellett a probléma megoldásával, miután véletlenül megszegtük az embargót. Két éve részese az xz projektnek, mindenféle bináris tesztfájlt ad hozzá, és őszintén szólva, ezzel a kifinomultsági szinttel még az xz régebbi verzióival is gyanakodnék, amíg az ellenkezője be nem bizonyosodik.”
Jia Tan intézkedéseket tett a követés megakadályozása érdekében: Úgy tűnik, VPN-t (vpn.singapore.witopia.net) használt a csatlakozáshoz – ami önmagában rendben van. És úgy tűnik, hogy sok változtatást időleges, egyszer használatos e-mailek (jelen esetben a ProtonMailtől) támasztanak alá, amelyek a változtatások egyesítésére szólítanak fel.
A szereplő akár még mélyebbre is merészkedhet, egészen a Linux kernelig, mint a közreműködő. xy-beágyazott projekt. A kezdeti elemzés a mai napig nem talált vetélésre utaló jelet.
Megjegyzés: egy másik az XZ kevésbé ismert munkatársa, „Hans Jansen” (GitHub felhasználó: „hansjans162”) vizsgálat alattA Debianon lévő fiókja mostantól a következő: zároltSzámos frissítést hajtott végre a Debian Games-en, hogy elrejtse azt, amelyet a debian/xz-utils-on szeretett volna, egy frissítést az 5.6.1-es verzióra, hogy felgyorsítsa a hátsó ajtó terjesztését. debian/instabil.
Egyelőre csak annyit mondhatunk, hogy ez egy (egyelőre azonosítatlan) APT, aki különböző fiókokat használ, legalább két éve dolgozik ezen a kampányon, és türelmesen dolgozik egy RCE SSH-ba való beültetésén.
Jelen írás pillanatában a „Jia Tan” mögött álló személyazonosság továbbra sem erősített meg. Nem erősítettek meg nyilvánosan hiteles forrást egyetlen konkrét személyről, szervezetről vagy állami szereplőről sem, ami megerősíti, hogy mennyire hatékony volt a személy operatív fegyelme.
Megelőzhető lett volna az XZ hátsó ajtós támadása?
Meglehetősen nehéz.
Először is, a befecskendezett hátsó ajtó egy része tömörített tesztfájlokba került, amelyeket a tesztek nem használtak. Visszatekintve ez okozhatott volna néhány (zajos) riasztást, de kit érdekel annak ellenőrzése, hogy az összes tesztfájlt használják-e a valós világban zajló tesztek? Másodszor, a befecskendezett hátsó ajtó egy része makrófájlokban érkezett a kiadási tarballokba, és nehéz manuálisan ellenőrizni az eltéréseket a várt tarballoktól. Az automatizálás is összetett, mivel a build várható eredményét (bárki számára, aki tudja, hogyan működik az automake/autoconf) nehéz modellezni annak elemzéséhez, hogy a valódi tarball megfelel-e az elvárásoknak. Néhányan feltették as „A git fától eltérő tarball fájlok egy funkció, nem hiba.”A bináris tarballok eredete a forráskódjukból egy megoldatlan probléma.
Felhasználói hírnév? Nos, a JiaTan75 GitHub fiók a múltbeli információk szerint nem csinált tisztességtelen dolgokat. commits. Csak a bizonyítékok felhalmozódása után függesztették fel, de március 29-ig ez egy rendszeres felhasználó volt, aki normál üzleti tevékenységet folytatott. Nos, nem annyira normális. Később commits (ezt, ezt, eztés ezt (amely módosította a sérülékenységet kihasználó kódot) megpróbálta kijavítani a valgrind hibákat és összeomlásokat bizonyos konfigurációkban, amelyek a hátsó ajtó által várt verem elrendezéstől való eltérések miatt jelentkeztek. Commit A kritikák ezt kimutathatnák, de kinek van türelme elemezni egy bináris tesztfájl változásait, vagy a C forráskód GCC attribútumainak megváltoztatásának valódi motivációját?
Riasztást kell leadni, ha egy SSH login 800 ms-ot vesz igénybe 300 ms helyett? Valószínűleg csak a hiper-óvatos emberek vennék észre. Cicero azt mondta, „A meggondolatlanság az ifjúsághoz tartozik, az óvatosság az öregséghez.”
Az ifunc infrastruktúráját 2023 júniusában „Hans Jansen” és „Jia Tan” építették. Ez az első commit ifunc támogatás hozzáadása a crc64_fast.c fájlhoz (később a hátsó ajtó befecskendezésére használták). Hónapokkal azelőtt, hogy a hátsó ajtó binárisait befecskendezték volna a tesztfájlokba!
Megjegyzés: Szerző és commitVannak itt különbségek, de ez normális: Lasse Collin a projekt karbantartója, és ő egyesítette a változtatásokat. Még „Hans Jansennek” is köszönetet mond...
Andres Freund bejegyzése és a RedHat által létrehozott CVE előtt senki sem aggodalmát fejezte ki. Ha olyan eszközök sorozatát látjuk, amelyek ezt észlelnék, akkor most észlelik az érintett komponenst. utólagosan.
A legjobb megelőzés valószínűleg a Linux disztribúciók természetéből adódott, és abból, hogy az instabil, legújabb verziók csak egy ütemezett folyamatot követően jutnak el a stabil disztribúciókhoz.
Az XZ bBackdoor támadásból levont tanulságok
Észrevettük, milyen nehéz észrevenni szándékos hátsó ajtók. A hátsó ajtókat belső fenyegetésnek kell tekinteni, mivel belső személyzet helyezi el őket, vagy feltört belső fiókokon keresztül. És ezekben a srácokban többnyire megbíznak. És amikor a hátsó ajtót beépítik az elosztott eszközbe, az megnehezíti az észlelését.
Néhány szerző, mint például Kevin Beaumont mutatott rendszer, ami nagy támadási felületet nyit harmadik féltől származó szolgáltatások számára a hátsó ajtó számára. Ezzel élt vissza a rosszindulatú szereplő. A Systemd-nek sok szeme van, de az XZ egy homályos könyvtár a lánc tetején. „Amikor a felső lánc szennyezett, mindenki mérgezett vizet iszik a következő láncban”.
Egy kapcsolódó módosítási kérés a rendszerben a következőhöz: dinamikusan betöltő tömörítési könyvtárakA , amely eltávolítaná a hátsó ajtót, már beépült a rendszerbe, de még nem került leszállításra. A libsystemd által bevezetett extra függőségek sebezhetőségek forrásai lehetnek, és tegnap ezt a kérést megnyitották.
A megjegyzés az „xz: Kapcsolja ki az ifunc-ot a probléma megoldásához” részben commit éles meglátásokat adott arról, hogy hová kell összpontosítani, ha meg akarjuk előzni az ilyen tevékenységeket (kiemelés tőlem):
„A közösségként meg kell tanulnunk a biztonságot.” software supply chain security holisztikusan, a forráskódon túlmutató build rendszerek auditálásával. Mint például a SolarWinds incidens, ahol a támadók módosították a SolarWinds zárt forráskódú monitorozó szoftverajánlatának szoftverfrissítéseit.”
FAQ
Az XZ hátsó ajtó ma is kockázatos?
Nagyrészt elzárva, de nem teljesen eltűnt. 2025 augusztusában a kutatók felfedezték, hogy a hátsó ajtó továbbra is jelen van számos Debian Docker Hub rendszerképben, amelyeket a Debian inaktív történelmi tárgyként kezelt. A csapatoknak ellenőrizniük kell, hogy nem elavult, nem javított alaprendszerképekre építenek, ahelyett, hogy feltételeznék, hogy a 2024-es javítás teljesen bezárta az ajtót.
