Szabadpingvin.eu

A nyuszi ezúttal nem piros tojást, hanem XZ backdoort hozott húsvétra.

Amit eddig tudunk:

A nyuszi ezúttal nem piros tojást, hanem XZ backdoort hozott húsvétra.

Amit eddig tudunk:

CVE szám: https://nvd.nist.gov/vuln/detail/CVE-2024-3094

(A hír frissül, ha lesz még érdemi információ.)

Érintett rendszerek

Ahhoz, hogy a backdoor működőképes legyen, a következő, viszonylag általános konfigurációnak kell fennállnia:

• Linux
• x86_64 architektúra
• Futó OpenSSH szerver (asztali rendszereknél nem jellemző) + systemd notification patch
• systemd „init” rendszer
• glibc C könyvtár használata
• XZ Utils 5.6.0-s vagy 5.6.1-es verziója telepítve (a régebbiek biztonságosak)

Viszonylag gyakori a fenti felállás, így a fő érdekesség az XZ Utils verziószáma. Azt az xz --version paranccsal derítheted ki:

Nálam (Ubuntu 22.04) pl. így néz ki:

~$ xz --version
xz (XZ Utils) 5.2.5
liblzma 5.2.5

Fontos még, hogy a backdoor akkor, és csak akkor kerül be az alkalmazásba, ha abból Debian vagy RPM csomag készül. Cseles!

Mivel egy szerencsés véletlennek köszönhetően időben észrevették a rosszindulatú módosítást, annak nem volt ideje beszivárogni a nagyobb disztribúciókba.

Kiemelném, hogy a meglévő telepítések nem érintettek, hacsak nem frissítettél kézzel a GitHubon közzétett xz utils verzióra.

Érintett disztribúciók

Az érintett nagyobb disztribúciók közül már mindenki visszavonta a problémás csomagverziókat.

• Debian SID: https://security-tracker.debian.org/tracker/CVE-2024-3094
• Fedora Rawhide: https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users
• OpenSUSE Tumbleweed és MicroOS: https://news.opensuse.org/2024/03/29/xz-backdoor/

Részben érintett nagyobb disztribúciók

• Gentoo: bekerült a rossz verzió, de a backdoor inkompatibilis a disztribúcióval: https://security.gentoo.org/glsa/202403-04
• Arch Linux: bekerült a problémás verzió, de az OpenSSH nincs összekötve az xz-vel, így nem működik a backdoor: https://security.archlinux.org/ASA-202403-1

A nagyobb disztribúciók közül az Ubuntu egyetlen verziója sem érintett: https://ubuntu.com/security/CVE-2024-3094

A backdoor

A backdoor, vagyis hátsóajtó egy olyan megoldás, ami a rendszer azonosítási mechanizmusait megkerülve, alternatív, jogosulatlan hozzáférést nyújt egy adott rendszerhez. Szó szerint úgy kell elképzelni, mint egy nyitva felejtett hátsó ajtót, csak ezúttal valaki szándékosan hagyta nyitva. Az xz-be pont ilyen hátsóajtót helyeztek el, a hogyanra és a feltételezett miértre később térek ki.

Mi az az xz?

Az xz egy általános célú, nagy hatékonyságú, veszteségmentes adattömörítő könyvtár (liblzma). Főfejlesztője Lasse Collin.

Mi kell a backdoor működéséhez?

Ha már fent van az xz 5.6.0-s vagy 5.6.1-es verziója, akkor sem működik egyből a backdoor, további feltételek szükségesek:

systemd: kulcspont, integrálódik az xz-vel, mivel használja a liblzma könyvtárat.

Módosított OpenSSH: az OpenSSH alapból nem integrálódik se az xz-vel, se a systemd-vel, de a nagyobb disztribúciók egy patch segítségével hozzákötik az SSH szervert a systemd-hez, így közvetetten pedig az xz-hez.

Tehát a disztribúciók saját systemd-notify integrációnak hála az OpenSSH sebezhető lett…

Ki és hogyan fedezte fel?

Andres Freund fedezte fel, aki az Openwall levelezőlistán tette közzé a találatát: https://www.openwall.com/lists/oss-security/2024/03/29/4

Véletlenül fedezte fel. Épp bizonyos PostgreSQL változások teljesítményre gyakorolt hatását mérte, mikor azt vette észre, hogy az sshd (OpenSSH szerver) túl sok processzorteljesítményt használ és 0,3 másodperc helyett 0,8-ba kerül a bejelentkezés. Ezért elkezdte profilozni az sshd működését, és abból az derült ki, hogy rengeteg időt tölt az ssh a liblzma könyvtárban, ugyanakkor a profilozó nem tudta megmondani, pontosan hol.

Mindeközben az automatikus tesztek során a legutóbbi frissítés óta a Valgrind is elkezdett furcsa dolgokra panaszkodni…

Ez lett gyanús.

Kik és mikor készíthették a hátsóajtót?

JiaT75 aka. Jia Tan: (ál?)nevű fejlesztő a főkolompos. Ő férkőzött a főfejlesztő bizalmába és vitte a szabotázs oroszlán részét.

hansjans162 aka. Hans Jansen: valószínűleg egy eldobható entitás, talán Jia Tan egyik álneve, néhány kellemetlen módosítás hozzá köthető.

Dennis Ens és Jigar Kumar: két további eldobható entitás, amik segítségével nyomást próbáltak helyezni a főfejlesztőre.

Jia Tan 2021 októberében tűnt fel a színen – más projekthez előtte nem járult hozzá – és elkezdett valódi értéket jelentő dolgokon dolgozni a projekten.

2022 júniusában megjelent néhány a „projekt jövőjéért aggódó” arc (Dennis Ens és Jigar Kumar) az xz-devel fejlesztői levelezőlistán, nyomást helyezve az amúgy is túlterhelt főfejlesztőre, hogy adjon/adja át valaki másnak (na vajon kinek?) a karbantartói jogokat, hogy ne „menjen tönkre” a projekt. Így utólag ez nagyon álságos, tudva, hogy a valódi cél az volt, hogy Jia Tan szabadon garázdálkodhasson az xz kódbázisában.

Jia Tan egészen a közelmúltig folyamatosan építette a bizalmat, látszólag nem tett semmi olyat, ami miatt gyanakodni kellett volna arra, hogy mire készül.

2024 februárjában azonban elengedték a szörnyet, bekerült a hátsóajtó az xz kódjába.

A backdoor kiválóan lett álcázva: A rosszindulatú kód a tesztfájlok közé került feltöltésre mint „hibás” archívum. Ami első (és második) ránézésre tényleg hibás, azonban amikor a backdoor bekerül az xz-be, néhány speciális transzformációval „kijavításra kerül”, és a benne lévő backdoor bekerül az xz-be.

Bár az elmúlt időben sok mindent megtudtunk, magának a backdoornak a teljes elemzését még végzi az infosec közösség. Az azonban már most biztos, hogy profi munka. Úgy néz ki, rengeteget dolgoztak azon, hogy elrejtsék a dolgokat, megnehezítsék az analízist és eltüntessék a nyomokat. Az elsődleges célpontok az OpenSSH autentikáció előtti, kriptográfiai folyamatai voltak, melyeknek hála egy sikeres támadás esetén valószínűleg root jogokkal lehetett volna futtatni bármit a célszerveren. Egyféle „mester kulcs" funkcionalitást akartak bevinni a rendszerbe, így akinek megvan a kulcs, észrevétlenül járkálhatott volna a rendszerekben.

Kellemetlen belegondolni, mi lett volna, ha nem fogják meg.

2024 márciusára ugorva, a nagyobb disztribúciók csomagkarbantartóinak „szóltak”, hogy van új xz verzió, ideje lenne frissíteni. Többek közt a Debian és az Ubuntu csomagkarbantartóit is megkörnyékezték.

Kicsoda Jia Tan?

Ez a 100 milliós kérdés. Senki nem tudja, jött, látott, pusztított.

Ugyanakkor van némi nyilvános metaadat, ami segíthet legalább támpontot adni, hogy ki lehet és honnan/kinek dolgozott Jia Tan. A neve nagyon ázsiai hangzású, nemde? Lehet, hogy átverés. Minden git commithoz tartozik két időbélyeg: amikor készült a módosítás és amikor commitolva lett. Ez az időbélyeg természetesen nagyon egyszerűen átírható, sőt, utólag módosítható is.

Csupán az időbélyegeket felületesen nézve Jia Tan a „szokásos rosszfiúk” területén dolgozott: Oroszország, Kína, Észak-Korea. Egyáltalán nem lenne idegen bármiért is őket okolni, hiszen rászolgáltak a kétes hírnevükre. Szóba jöhet még a Fülöp-szigetek és Indonézia is mint lehetséges jelöltek, de ki gondolna rájuk, nemde?

A metaadatok közvetlenül nagyon sok mindenre rá tudnak világítani, de közvetlen bizonyítékokkal nem szolgálnak. Nem kaptál meghívót a lagzira, de a legjobb éttermet lefoglalták, a zenekar aznap nem ér rá, és a virágosnak is van egy nagy megrendelése. Semmi konkrét, de össze lehet kötni a pontokat.

Ha ismerjük a gyanúsított ország ünnepeit, jellemző irodai munkaidejét, akkor abból ki tudjuk következtetni, hogy a célszemély valóban ott tartózkodott-e, ahol mondja magát, vagy hazudik. Hobbiból csinálta a projektet vagy irodai időben, valószínűleg pénzért, dolgozott-e ünnepnapokon vagy sem. JjaT75 GitHub aktivitásának elemzése arról tanúskodik, hogy valami nincs rendben az ázsiai elmélettel.

Commitjai nagy része (440 darab) látszólag kínai időzónában (UTC+8) készült, hajnali vagy kora reggeli időben, hétköznapokon. Nem lehetetlen, de elég elhivatottnak kell lenni ahhoz, hogy hétköznapokon hajnalig dolgozz valamin. Ugyanakkor, ha ezeket az időpontokat átkonvertáljuk valami közelebbi időre, akkor kiderül, hogy kelet-európai időzónában nagyjából lefedik a normál, 9-től 17-ig tartó irodai időt. Ezt támasztja alá az is, hogy a kínai ünnepeken mindig dolgozott, de az európaiakon (karácsony, újév) nem. Ha kínai lenne az illető, akkor ez nem fordítva lenne? :) Ezen kívül nem dolgozott hétvégén, a legtöbb változást hét közben – kedden, szerdán, csütörtökön és pénteken – vitte be. Irodai időben, kelet-európai időzóna szerint. Érdekes „kínai”.

Konkrét ClickHouse elemzés arról, hogy mikor, mennyi commitot küldött be itt olvasható. Az időt UTC időzóna szerint kell értelmezni. Ha feltételezzük, hogy európai kártevőről van szó, akkor ő is délután szereti beküldeni az aznapi munkát.

Ezen kívül előfordult, hogy néha kelet-európai időzónából küldött be módosítást. 3-at UTC+2-ből (téli idő), 6-ot UTC+3-ból (nyári idő). Repülés kizárva, mert az adatok alapján nem telt el két commit között elég idő, hogy átrepülhesse a fél bolygót.

Nyáron kik vannak UTC+3-ban? Oroszország és Fehéroroszország kiesett, ők egész évben UTC+3-ban vannak, nem állítgatják az órát (szerencsések!). Akkor maradt Bulgária, Ciprus, Észtország, Finnország, Görögország, Lettország, Litvánia, Moldova, Románia, Ukrajna, Izrael, Libanon, Palesztina. Van miből válogatni, még úgy is, ha kiszűrjük azokat, akik nem tartják a mi ünnepeinket.

Mindenféle bizonyíték nélkül, pusztán megérzés alapján azt mondanám, hogy az akció gyökereit Izraelben kell keresni. Tőlük egyáltalán nem lenne idegen egy ilyen szintű, alattomos és sunyi támadás mindenki ellen. Izrael – és elnézést a kifejezésért, de – államilag erősen támogatott, digitális terrorista állam. Kiberfegyverek egész sorát szállítják és mindenki megkaphatja, aki eleget fizet. A Pegazus is az ő termékük volt.

A commitok időbélyegeinek az elemzését a Rhea's Substack blog végezte.

Miért?

Ha a hátsóajtó észrevétlen marad (nem sokon múlott), akkor bekerülhetett volna a nagyobb Linux disztribúciókba. Hamarosan itt az Ubuntu 24.04 LTS, a Fedora 40 és jövőre már „elég stabil” lehetett volna a fertőzött xz verzió ahhoz, hogy bekerüljön a RHEL 10-be is.

Nyilvánvalóan a cél az volt, hogy a lehető legtöbb disztribúcióba bekerüljön, majd bizonyos kormányzati érdekeltségek ki-be járkáljanak szerverek millióin anélkül, hogy bárkinek feltűnne. Hogy ezzel mit lehet kezdeni, azt a (piszkos) fantáziádra bízom.

Mert kétségeink ne legyen afelől, hogy ez egy profin kivitelezett művelet volt, amit nem ugratásból vagy szórakozásból hajtottak végre. Mind a backdoor komplexitása, mind annak elrejtése komoly szakértelemre utal. Bár lehetséges, hogy valaki csak heccből csinálja, sokkal valószínűbb, hogy kormányzati támogatás volt mögötte.

Tanulság?

A nyomozás még közel sem ért véget, sok érdekes információ napvilágra kerülhet még.

Általánosságként elmondható, hogy újra követni kéne a KISS (Keep It Short Simple) elvet, azaz egy alkalmazás csak egy valamit csináljon, de azt jól. Sokak megénekelték már, hogy indokolatlan komplexitást bevezetni egy rendszerbe rossz dolog, kerülendő. A disztribúciók mégis direktben hozzákötötték az OpenSSH-t a systemd-hez, ami pedig integrálódik az xz-vel és baj lett. Sokkal-sokkal nagyobb is lehetett volna.

A másik, legalább ilyen fontos, hogy a szabad szoftverek sem önfejlesztőek, nem tartják magukat karban. Kiemelt prioritással kellene kezelni azokat a projekteket, melyek a mindennapi életünk részei. Az xz lényegében egy két fős műsor (volt), amit Lasse Collin a szabad idejében, hobbi projektként csinál, és már 2022-ben is probléma volt, hogy nem talál új karbantartót. Ideje lenne mindenkinek, de különösen a szabad szoftverekből nagy profitot szakító vállalatoknak jobban odafigyelni az ilyen kritikus szerepű, mégis elhanyagolt projektekre. Mi lenne, ha legalább a főfejlesztőt támogatnánk és teljes munkaidőben alkalmaznánk?

Ezúttal szerencsénk volt. De lesz-e legközelebb? Vagy egyáltalán: lehet, hogy már valamilyen komponensen keresztül bejutott egy backdoor, csak még senki nem vette észre?