Pozor na novou verzi XZ
Vše začalo varováním společnosti Red Hat, jejíž vývojáři vyzvali uživatele k okamžitému odstavení systémů s vývojovými a experimentálními verzemi Fedory. Byla totiž objevena zadní vrátka v kompresním nástroji a knihovnách XZ. PLEASE IMMEDIATELY STOP USAGE OF ANY FEDORA RAWHIDE INSTANCES for work or personal activity,
velmi důrazně varoval Red Hat v pátek.
Ukázalo se totiž, že nejnovější verze nástrojů a knihoven XZ obsahují škodlivý kód, který zřejmě umožňuje neoprávněný přístup do operačního systému. Konkrétně se tento kód nachází ve verzích 5.6.0 a 5.6.1. Tyto verze se už začaly přes aktualizační kanály dostávat do vývojových větví některých distribucí, takže už je úzká skupina uživatelů mohla mít nainstalované. Zranitelnosti bylo přiřazeno označení CVE-2024–3094.
XZ je univerzální formát pro kompresi dat, který se vyskytuje téměř ve všech linuxových distribucích, a to jak v komunitních projektech, tak v komerčních produktech. V podstatě pomáhá komprimovat a dekomprimovat velké soubory do menších, lépe zvládnutelných velikostí vhodných například pro přenos po síti.
Víme, že se nové verze balíčků dostaly do Debianu unstable (Sid) a do Fedory Rawhide, tedy do průběžně aktualizovaných distribucí, které slouží jako vývojové prostředí pro příští vydání. Do produkční Fedory ani Debianu se tyto balíčky nedostaly a vývojáři se vrátili k předchozím verzím.
Chytře ukrytý kód
Repozitář s původním kódem je už na GitHubu zablokovaný, protože porušoval místní pravidla. Od správců balíčků ale víme, o jaký kód se jednalo a jak pracoval. Jeho přesné dopady na operační systém nejsou zatím známy, protože kód byl silně obfuskovaný, tedy zamlžoval svou funkci a snažil se tím předejít jednoduchému odhalení.
Škodlivý kód také nebyl součástí zdrojových kódů uvnitř gitovského repozitáře a automaticky generované tarbally ho proto neobsahovaly. Tvůrci software ale nabízeli ke stažení vlastní tarbally obsahující příslušnou verzi a v nich už se kód nacházel.
Pokud je z těchto napadených zdrojových kódů balíček sestaven, dostává se nepozorovaně do operačního systému. Začne ovšem pracovat jen v případě, že cílový operační systém používá systemd a zároveň má upraveného SSH démona tak, že používá systemd-notify a umožňuje tak dostávat informace o stavu jednotlivých částí systému.
Pro zavolání zákeřného kódu je totiž potřeba, aby SSH natahovalo jako závislost také knihovnu liblzma. Tu ovšem obvykle SSH nepoužívá, ovšem zmíněná distribuční úprava do SSH démona přidá volání knihovny libsystemd, která pak už zavolá liblzma a dílo může být dokonáno.
Pozoruhodné také je, že hlavní část zákeřného kódu není přímo součástí programu, ale skrývá se v testovacích datech. O použití se pak stará část skriptu configure uvnitř tarballů vydaných verzí. Při sestavování binárního balíčku ve správném prostředí se pak škodlivý kód použije. Kromě už zmíněné podmínky použití systemd je tu také nutnost vytvářet balíček deb nebo rpm. Pokud se vytváří jiný typ balíčku nebo se používá jiný init systém, kód se neprovede a výsledek backdoor neobsahuje.
O schopnostech backdooru víme jen tolik, že kód pak zasahuje do procesu autentizace uživatele a umožní neoprávněné přihlášení do systému znalému útočníkovi. Kód zřejmě přesměrovává funkci RSA_public_decrypt na vlastní děravou implementaci. Zřejmě tedy ovlivňuje přihlašování pomocí klíčů.
Je ale také možné, že má program další skryté funkce, které se použijí za jiných okolností. Až bude dokončena komplikovaná analýza obfuskovaného kódu, budeme vědět více. Tvůrci distribucí také diskutují o tom, zda se nevrátit ke starším verzím XZ, které vznikly ještě před zásahy nového správce. Můžeme předpokládat, že celý software projde důkladnou kontrolou.
Roky příprav
Na případu je zajímavé to, že nešlo o jednorázový pokus něco někam propašovat, ale poměrně náročný a dlouhodobý proces. Jeden z vývojářů Red Hatu mi řekl, že takhle promyšlený backdoor ještě neviděli, a zarazil je také způsob, jakým útočník pracoval.
Celou historii zmapoval a na svém blogu popsal Evan Boehs, který uvádí, že uživatel JiaT75 (Jia Tan) si na GitHubu vytvořil účet už v roce 2021. Hned také začal pracovat na své diverzní činnosti. Nejprve ne v projektu XZ, ale nahrál úpravu pro bsdtar, která zaváděla rozšířené hlášení chyb. Ovšem ne pomocí funkce safe_fprintf, ale jen fprintf. To může vypadat jako běžné opomenutí nováčka, s tím co ale víme teď, to nejspíš byla příprava pro budoucí exploit speciálně upraveným poškozeným archivem. Tato úprava bez diskusí prošla do ostrého kódu a byla později opravena.
V dubnu roku 2022 zaslal stejný uživatel nepodstatnou úpravu do mailing listu XZ. Zároveň se objevilo další jméno, Jigar Kumar, který začal tlačit na vývojáře, aby úpravu přijali a požadoval, aby Lasse Collin přidal do repozitáře dalšího správce. To se také stalo a JiaT75 se stal jedním ze správců. Od té doby se Jigar Kumar už nikdy neozval.
JiaT75 začal zařazovat do projektů kód 7. ledna 2023, tou dobou tedy získal plnou důvěru ostatních vývojářů. V březnu pak byl změněn kontaktní e-mail hlavního vývojáře z původního Collinova na Tanův. V červnu se pak objevilo další jméno: Hans Jansen. Ten začal odesílat vlastní úpravy, které pak do repozitáře commitoval Tan. Šlo konkrétně o novou implementaci funkce ifunc v souboru crc64_fast.c.
V červenci pak byl v oss-fuzz otevřen pull request pro zákaz nové implementace funkce ifunc ve fuzzingových sestaveních kvůli problémům, které přinesly výše uvedené změny. Zdá se, že cílem bylo zamaskovat škodlivé změny, které budou později zavedeny.
Následně byly na začátku roku 2024 přidány nové části kódu, které byly přijaty a staly se součástí XZ. Díky výše uvedeným změnám už je nikdo neřešil, automatické testy neodhalily problém a výsledek se stal součástí projektu.
Tvůrce backdooru pak cíleně komunikoval s vývojáři distribucí ve snaze dostat do balíčků novou verzi upraveného nástroje a překonat různá varování, která byla odhalena v průběhu standardních procesů. Autor backdooru se mnou byl průběžně v kontaktu několik týdnů se snažil dostat xz 5.6.x do Fedory 40 a 41, protože obsahuje ‚skvělé nové funkce‘. Dokonce jsme s ním spolupracovali na opravě problému s Valgrindem, který, jak se nyní ukazuje, byl způsoben backdoorem, který přidal,
píše Richard Jones.
Přišlo se na to náhodou
Všechno běželo jako po drátkách a útočníkovi se podařilo propašovat zákeřný kód až do vývojových větví některých distribucí. Shodou okolností ale Andres Freund z Microsoftu kvůli testům PostgreSQL potřeboval co nejvíce snížit zátěž systému, aby omezil šum. Všiml si při tom, že proces sshd příliš intenzivně zatěžuje procesor.
Začal se tedy pídit po tom, čím je neobvyklá zátěž způsobena. Profiloval jsem sshd, což ukázalo spoustu času CPU v liblzma, přičemž perf to nedokázal přiřadit ke konkrétnímu symbolu. Začal jsem mít podezření. Vzpomněl jsem si, že jsem před několika týdny po aktualizacích balíčků viděl podivnou stížnost Valgrindu při automatickém testování Postgresu,
vysvětluje Freund, který také nakonec na backdoor přišel a varoval ostatní. Opravdu to vyžadovalo spoustu náhod,
dodává.
Přestože tu byly předem různé varovné signály, podařilo se je útočníkovi obejít nebo banalizovat. Jednak chytrou postupnou dlouhodobou přípravou nebo spoluprací s dalšími klíčovými vývojáři. Ty mělo varovat už to, že se kolem projektu rojí spousta nových uživatelských účtů bez historie, které tlačí na rychlé přijímání podezřelých nových změn.
Jaké si vzít ponaučení?
Solène Rapennová, jedna z vývojářek OpenBSD k tomu sepsala vlastní blogpost, ve kterém shrnuje ochranná opatření, která by měla být napříště nasazena.
- Balíčky by měly být sestavovány z repozitáře zdrojových kódů namísto tarballů, kdykoli je to možné Někdy tarbally obsahují kód, který by jinak bylo těžkopádné stahovat. Alespoň bychom věděli, co očekávat.
- Veřejné síťové služby, které by měli používat pouze známí uživatelé (jako OpenSSH, IMAP server v malých firmách atd.), by měly být provozovány za VPN.
- Přístup OpenBSD mít základní systém vyvíjený jako celek jedním týmem je skvělý, takový druh zranitelnosti se pak sotva může objevit. To se týká pouze základního systému, porty nejsou auditovány.
- Pokud je to možné, měli byste oddělit každou síťovou službu v rámci vlastní instance operačního systému (pomocí hardwarových strojů, virtuálních strojů nebo dokonce kontejnerů).
- Pokud možno se vyhněte démonům spuštěným pod rootem.
- Na pracovních stanicích používejte OpenSnitch (pouze v Linuxu).
- Kontrolujte odchozí provoz, kdykoli můžete.
