Obecně o důveře

V minulém týdnu toho bylo o úspěšné a na poslední chvíli objevené infiltraci do zdrojového kódu xz napsáno dostatek, dokonce i mimo technicky zaměřené zpravodajské weby. 

Celá událost pro hodně lidí působí trochu jako sci-fi. Něco, co se může dít jen ve filmu nebo v seriálu. Útočník, pravděpodobně člen větší skupiny, v roce 2022 začal přispívat vlastními úpravami do zdrojového kódu xz (utility a knihovny pro komprimaci dat). Choval se normálně. Úpravy kódu byly užitečné, v pořádku, a procházely schvalováním správce projektu. V průběhu času se mu podařilo získat důvěru v rámci projektu (za pomoci dalších identit, které jeho prospěšnost podsouvaly dalším členům), až se nakonec sám stal jedním ze správců a mohl tak další úpravy schvalovat sám. Následně začal po kouscích budovat infrastrukturu, kterou se mu podařilo do balíku se zdrojovým kódem vložit dílky skládačky, které při kompilaci do výsledné knihovny vkládaly škodlivý kód. Vše probíhalo po nenápadných malých změnách, tak aby nebylo zřejmé, že se děje něco podezřelého. 

Neméně sci-fi je náhodné objevení těchto zadních vrátek, které podle všeho cílily na SSH server. K objevení došlo pět minut po dvanácté, kdy se napadená verze knihovny dostala do několika verzí linuxových distribucí používajících nejnovější verze balíků (tzv. rolling update distribuce, např. Fedora Rawhide nebo Debian Sid). Jeden z vývojářů PostgreSQL serveru pracoval na testování performance databáze. A aby mohl porovnávat relevantní data, připravil minimalistické testovací prostředí, postavené na Debian Sid, aby odstínil vliv dalších běžících aplikací. Ovšem během následného testování si všiml, že dochází k nestandardnímu nárůstu zatížení procesoru při navázání spojení na SSH server. Po dalším zkoumání se mu podařilo lokalizovat zdroj vytížení v knihovně xz a následně pak i s dalšími vývojáři potvrdit, že poslední verze projektu xz obsahuje zadní vrátka. 

Takto ve zkratce to působí, že vše prošlo až moc snadno. Reálně to ale ze strany útočníka byla dlouhodobě a pečlivě provedená akce, která zahrnovala i hodně social engineeringu pro ovlivnění jednotlivých členů projektu. Rozhodně nemá význam vynášet ukvapené závěry o tom, že open source není tak bezpečný, jak všichni doufali, nebo že by mělo dojít ke změně vývoje jednotlivých projektů. Naprosto stejná situace může nastat i v případě produktu vyvíjeného jako closed source. Dnešní doba, kdy firmy nabírají vývojáře na full-remote spolupráci, případně najímají freelancery, a daného člověka nikdo fyzicky ani neviděl, tomu jen nahrává. 

Celé je to ale varování, a připomenutí toho, že není dobré spoléhat se na snadná a krátkodobě efektivní řešení. Existuje mnoho míst v prostředí vývoje aplikací, kde infrastruktura vznikala od vývojářů pro vývojáře, v dobré víře, že bude použitá jen pro to, pro co je určená. V průběhu let se ale opakovaně ukazuje, že řešení pro distribuci modulů jednotlivých jazyků (PHP – Composer, Python – PyPi, Node.js – npm) lze vždy zneužít pro šíření škodlivého kódu. Obdobná rizika mohou nastat i v případě image staženého z Docker registry. 

Neznamená to, že by si vývojáři měli vše naprogramovat sami. Ale měli by přemýšlet, jestli to co jim jako řešení doporučí Stack Overflow nebo ChatGPT, je to nejvhodnější, a zkusit si alespoň ověřit historii a konzistenci daného projektu. 

Je ještě jedno odvětví, kde v poslední době pozoruji slepou důvěru. Trochu překvapivě je to oblast kybernetické bezpečnosti. Situaci akceleruje obzvlášť v posledním roce, v rámci přípravy a implementace zavedení směrnice NIS2. Doteď si každý řešil kyberbezpečnost po svém, a samotná realizace se většinou odvíjela od velikosti konkrétní společnosti. V rámci NIS2 by se mělo řešení více sjednotit, ale hlavně dopadne i na společnosti, které na komplexnější řešení zatím nepomyslely, většinou z důvodu úspory nákladů. 

V takové situaci logicky vzroste poptávka po rychlých řešeních, ideálně s minimálními náklady. Kde je poptávka, vzroste i nabídka. A nezávisle na tom, jestli společnost zvolí některé řešení zdarma, nebo již zaběhnuté komerční řešení, často zapomíná na obezřetnost. Aby daný monitorovací nástroj mohl spolehlivě fungovat, často vyžaduje úplná práva k sledovanému systému. Případně nevyžaduje, ale snáze a rychleji ho lze zprovoznit, pokud mu je dáte. A jakmile začne data sbírat, shromažďuje je v jednom místě. Vzniká tedy několik bodů, kde je potřeba zpozornět a zamyslet se, jaká jsou nově vznikající rizika plynoucí z jejich předcházení. Dá se to shrnout klasickým úslovím, kdo hlídá hlídače? 

Jsou to zdánlivě nesouvisející problémy, ale ve všech případech platí, že občas je lepší se zastavit a zamyslet. Protože když vám přijde e-mail, který vám oznamuje pohádkové dědictví, nebo jistotu desetinásobku, pokud odesílateli sdělíte údaje ke své platební kartě, tak se pravděpodobně nachytat nenecháte. Ale co když narazíte na lákavý kus kódu, který slibuje vyřešit za vás integraci s některým systémem? Co když na vás vyskočí reklama na zboží téměř zdarma, pod podmínkou, že si nainstalujete aplikaci do telefonu a udělíte jí poměrně široká oprávnění? Když vám někdo nabídne aplikaci pro hlídání systému, které udělíte přístup úplně ke všemu? Incident s xz určitě nebyl ojedinělý. Vždy je lepší počítat s tím, že k něčemu takovému může dojít, a snažit se minimalizovat rizika a dopady předem.