Zadní vrátka pro zvířátka

#1 Zadní vrátka, anglicky backdoor, je způsob obejití zabezpečení nějaké aplikace nebo obecně systému, kdy útočník, nebo někdo, kdo ty zadní vrátka přidal, může ovládat aplikaci nebo systém i bez znalosti například přihlašovacích údajů. Takové ovládnutí systému dovoluje například nainstalovat nějaké zákeřné programy, malware, viry apod. A viry, to jsou zvířátka. A Back doors je (nebo aspoň za mých mladých let byl) taky docela fajn bar v Praze na Andělu a tam to k ránu občas taky vypadalo jak u zvířátek.

#2 I u O₂ ví, že takový zvířátka si do počítačů a serverů pustit nechcete a tak vám na to v době přednášky nabízeli svůj animalware (od přednášky už z toho udělali klasický antimalware). To T mohli vynechat i v tom slově antivir a bylo by to komplet „next gen“!

#3 Představíme si jeden takový dobrý způsob, jak malware distribuovat. Protože i když máte aplikaci relativně dobře zabezpečenou, tak se může furt stát to, že někdo nějak „zaviruje“ a napadne vašeho dodavatele a přes něj nebo spíš díky němu se útočníci dostanou i k vám. Totiž takhle, jak se nejlépe zbavíte agenta 007, když nejde odkráglovat ani krocnout? Přesvědčíte dodavetele jeho „protřepat, nemíchat“, aby do toho pitíčka zamíchal nějakou okenu, nebo něco zhruba stejně dobrýho, a zbytek už se pak zařídí tak nějak sám. Nebo v pekárně Jejího Veličenstva po macgyverovsky vyměníte mouku za ten bílý prášek seškrábaný z kontaktů autobaterie z vašeho starýho žigulíka. Nebo prostě tak nějak nepřímo.

Podobně je to v softwarovém vývoji: dnes snad každá aplikace používá nějaké knihovny, obecně závislosti třetích stran (third-party dependencies), v PHP třeba pomocí Composeru, v JavaScriptu pomocí npm nebo pomocí <script src=https://cdn.example.com/lib.js> tagů. Pak stačí takovou třetí stranu nějak hacknout a ten váš hack se pak dostane i do aplikací, které tu závislost (třeba knihovnu) používají a kam byste se jinak normálně třeba ani nedostali. Takovým útokům se říká supply chain attacks, česky útoky na dodavatelský řetězec.

#4 Některé ty případy supply chain útoků jsou skoro z kategorie sci-fi. V roce 2019 (nejspíš) čínská skupina Barium upravila kompilátor v nějaké konkrétní verzi Microsoft Visual Studia, aby do výsledné binárky přidal něco „na přání“ a Visual Studio s touto úpravou jej nabídla ke stažení z nějakýho ne-úplně-tak-oficiálního zdroje. Tuhle verzi Visual Studia pak stáhla nějaká parta, která ten kompilátor použila pro tvorbu nějaké hry, která se pak dostala na nějaké počítače, kde ten kód „na přání“ mohl ta přání začít plnit. Supply chain útok v supply chain útoku, moc hezký.

#5 Podobná věc se stala i v případě Xcode což je vývojové prostředí pro aplikace pro operační systémy od Applu (macOS, iOS, atdOS). Kdosi na „čínském uložtu“ dal ke stažení upravenou verzi Xcode, která do vytvořených aplikací přidala nějaký zákeřný kód a výsledné aplikace se dostaly až do App Storu a pak až do zařízení uživatelů.

#6 Říká se, že open-source software je bezpečnější, protože si každý může přečíst co dělá. Ta druhá část je pravda, ale aby to k něčemu bylo, tak by „každý“ musel umět ten konkrétní jazyk, ve kterém je daný software napsán a ještě rozumnět bezpečnosti. A navíc to dělat pravidelně, před každou aktualizací. Takových „každých“ moc není. Nehledě na to, tak záleží i na tom, jaká konkrétní zkompilovaná binárka běží na vašem zařízení, protože když si přečtete a porozumíte nějakému kódu, tak to ještě nemusí nutně znamenat, že ten konkrétní kód se i spouští na vašem počítači. Jedna věc je ta, že se aplikace stahují z různých stórů, další pak to, že vlastně ani nevíte, jak má výsledek kompilace vypadat. V kombinaci s kompilátory, které do výsledku přidávají nějaký malware, viz předchozí slajdy, ta domnělá výhoda bezpečnějšího open sourcu mizí v dáli. Jedině že…

Jedině že byste věděli, jak má výsledek vypadat. Třeba kdyby někde na webu daného programu bylo napsáno, že když si aplikaci zkompilujete, tak kontrolní součet toho exáče má být 0xrazdvatři, tak byste si to mohli celkem jednoduše zkontrolovat. Takovému procesu se říká reproducible builds a celý trik je v tom, že výsledek každé kompilace daného programu pro danou platformu bude vždy stejný nehledě na to, kde nebo kdy a na jaké platformě se kompilace provedla. Programy vytvořené ve skriptovacích jazycích jako např. v PHP nebo Pythonu to mají v tomto případě o něco jednodušší, protože si odněkud stahujete zdrojáky, ne nějak zkompilované binárky.

#7 Reproducible buildy (ale jen pro Android) má třeba oblíbený kecálek Signal Není to úplně pětiminutová procházka růžovým sadem, potřebujete na to nemálo času i znalostí. Kromě obvyklého Gitu a Pythonu potřebujete i Docker pro zkompilování Signalu, Android Debug Bridge (adb) pro stažení nainstalovaného Signalu z vašeho telefonu a Bundletool, abyste si vytvořili přesně takový balíček (Android Package, APK), jaký by byl nahrán do Google Play Storu – ten se pak ve finále porovná s balíčkem z vašeho telefonu. V návodu jsou manuální kroky, protože třeba názvy souborů, které vytvoří Bundletool, se mohou lišit dle toho, jaký telefon máte připojen apod.

Sám jsem si to chtěl vyzkoušet, ale tak ve třech čtvrtinách jsem to vzdal, navíc bych to měl dělat s každou aktualizací, uff, takže můžu jen doufat, že můj Signal není 信号. Ale (jednodušší) reproducible buildy jsou cesta, jak se bránit různým hacknutým kompilátorům apod.

#8 Ale nejsou to jen kompilátory, který mohou otevřít ta pomyslná zadní vrátka. V roce 2013 se kriminální živlové dostali do společnosti Target, což je takové americké Tesco, a podařilo se jim na pokladny nainstalovat malware, který kradl čísla platebních karet. Za tři týdny získali cca 40 milionů karet. Jak se těm živlům povedlo do Targetu dostat? Dodavateli topení a klimatizací ukradli přístupové údaje do sítě Targetu. Asi lepší si tu vzduchotechniku začít dělat sám. Nebo si dávat pozor na to, koho pouštím do sítě. Obojí se ale celkem lehko řekne, ale evidentně už hůř dělá.

#9 V roce 2017 někdo napadl ukrajinskou firmu, která vytváří účetní program M.E.Doc, a upravil aktualizační balíček, který když si uživatelé toho programu stáhli, tak si zároveň stáhli i malware NotPetya. Firma na zabezpečení prý docela kašlala, mimojiné používala zastaralý FTP server s veřejně známými vážnými chybami. Údajně na problémy zabezpečení byli několikrát upozorňováni a měli se z toho zodpovídat, což je relativní novinka: firma, kvůli které hacknuli mnoho dalších firem, by měla nést následky. Ponaučení? Neaktualizujte rychle, abyste si nestáhli nějakou nechtěnou novinku. Ale aktualizujte rychle, aby někdo nestihl zneužít již opravené chyby. Neaktualizujte rychle, ale aktualizujte rychle, chápeme se, žejo‽

#10 Na konci roku 2020 kdosi získal přístup ke zdrojovému kódu Microsoftu, konkrétně ke kódu nějakých Exchange (a pár dalších) komponent. V těch zdrojácích naštěstí nebyly žádné přístupové údaje, žádné klíče, hesla apod. (taky je tam nemáte, že?) V lednu a únoru 2021 se pak začaly objevovat útoky na Exchange, které zneužívaly dosud neznámé chyby, na které Microsoft vydal záplaty 2. března, ale do 5. března je nainstalovalo údajně jen 10 % provozovatelů Exchange. Takže záplatovat rychle, v některých případech chvíli počkat, sledovat kdy nečekat a vědět kdy čekat, mít testovací prostředí, který ale taky nemusí pomoci, protože útok přijde až po úspěšném otestování, že to nic nerozbije. Jednoduchý jak facka. A nebo možná taky ne.

#11 Tenhle rok se objevil supply chain útok pomocí JavaScriptové knihovny polyfill.io. To je knihovna, která dodává moderní vlastnosti do starších browserů, které je nativně nepodporují. Takovému kódu, díky kterému můžete psát moderněji a bude to fungovat i ve starších browserech, se říká polyfill. Polyfill.io byla nejen oblíbená knihovna, ale vlastně celá služba, která prohlížeči naservírovala takový polyfill, který zrovna potřeboval.

Moderním prohlížečům vracela prázdnou odpověď, protože moderní prohlížeče už všechno umí, a čím starší prohlížeč, tím dostal obsáhlejší polyfill. Každá odpověď tedy mohla být jiná a tudíž nešlo použít Subresource Integrity (SRI) hashe v HTML atributu integrity, pomocí kterých browsery kontrolují, jestli náhodou např. na CDN nedošlo k nějaké neautorizované změně, třeba jako v roce 2013 v případě Video.js, ke kterému také došlo kvůli supply chain útoku na aktualizaci nějakého doplňku v browseru.

Polyfill.io byl útočníkem dobře vybraný cíl. Doménu polyfill.io koupila čínská společnost Funnull a tvůrce služby vyjádřil obavy, jestli náhodou nechystají nějakou lumpárnu. Na základě toho v únoru firma Cloudflare spustila vlastní mirror podobně jako Fastly

V červnu začal Google zamítat reklamy webům, které polyfill.io (a další) používaly, protože se přes tuto doménu začal distribuovat do prohlížečů nějaký malware. V repozitáři služby polyfill.io na GitHubu se mazaly issues, nejspíš proto, že obsahovaly odhalení toho problému. Nový majitel samozřejmě všechno popřel, ale i přesto doména po chvíli přestala fungovat, zablokovaly ji mimo jiné i ad blockery, které už dlouho jsou spíše security nástroj, než jen blokátor reklam. Firma spustila novou domiénu [sic], ale s tou to dopadlo úplně stejně.

V roce 2024 žádný polyfill pro JavaScript není potřeba a pokud používáte jakoukoliv JS knihovnu z nějaké CDN, tak určitě používejte integrity hashe. Pokud je služba nenabízí, tak ji nepoužívejte. Domén a služeb, které byly součástí tohoto útoku, bylo a je víc (např. bootcdn.net a staticfile.net), ale všechny patřily stejnému útočníkovi nebo skupině.

#12 Tohle je první mergnutý commit od uživatele Jia Tan, který se mu povedlo dostat do knihovny libarchive na GitHubu v roce 2021. Knihovna libarchive slouží pro práci s archívy typu .zip, .bzip2 a mnoha dalšími. Jia Tan sice tvrdí, že commit přidává nějakou chybovou hlášku, ale je taky vidět, že nahradil volání safe_fprintf za volání jen fprintf, bez toho safe_. A to trochu smrdí, jak ostatně o tři roky později potvrzují i komentáře v pull requestu. Úplně první Jia Tanovo dílo nebylo mergnuto, ale trochu podezřelé je taky – údajně přidává barvičky do výstupu, ale taky zároveň mění nějakou funkci, aby si délku řetězce nezjišťovala sama, ale aby se správná délka musela předat. Když se předá špatná, tak to obvykle vede k chybám typu buffer overflow nebo out-of-bounds read.

#14 Před pár lety jsem začal používat PHP knihovnu „phpgangsta/go­ogleauthentica­tor“ pro vytváření TOTP (Time-based one-time password) kódů, které se každých 30 vteřin mění a používají se pro 2FA. Název „google authenticator“ odkazuje na mobilní aplikaci Google Authenticator, která tyhle kódy dostala do povědomí širší veřejnosti. V PHP se pro instalaci balíčků používá Composer a balíčky se defaultně stahují z repozitáře Packagist. Když jsem chtěl použít nejnovější verzi phpgangsta/go­ogleauthentica­tor 1.0.1, tak jsem zjistil, že v Packagistu není uvedená. Udělal jsem issue a o den později pro jistotu napsal autorovi e-mail.

Jeho odpověď mě moc nepotěšila: prý to uživatelské jméno na Packagist vlastní někdo jiný, nějaký jiný phpgangsta. Ok, vyřešíte si to jinak, budete instalovat poslední commit, ne poslední otagovanou verzi, ale když se na to podíváte optikou značky Paranoia, Inc., tak zjistíte, že kdyby tomu jinýmu phpgangstovi trochu ruplo v CPU, nebo kdyby ho nějakej ten Jia Tan trochu správně „najal“, tak by se mohlo stát, že nová verze by ty kódy, nebo spíš secrety, ze kterých se počítají, mohla někam „zákeřně zálohovat“. A pokud by ty zálohovací vrátka byly podobně dobře udělané jako v případě XZ, tak by to mohlo nějakou dobu trvat, než by se někomu zase něco nezdálo. Tohle konkrétně jsem vyřešil tak, že jsem tu knihovnu přesunul/zkopíroval do našeho vlastního repozitáře a stala se tak součástí celé té aplikace, která ji používala. Přestala to být 3rd-party závislost, ale byla to najednou „naše“ knihovna. To z různých důvodů nejde dělat se všemi knihovnami, ale tahle se naštěstí moc nerozvíjí, není k tomu vlastně ani žádný důvod.

#15 Možná si říkáte, že tu knihovnu neznáte, nebo že je to nějaká obskurní věc. No, spíš není. Má 2 miliony instalací a každých 24 hodin se instaluje zhruba 1000×. Něco z toho budou nějaký testy a CI pajplajny, ale ten stoupající trend je poměrně jasný.

#16 V další aplikaci jsme na to samé, na generování a ověřování 2FA kódů, použili jinou knihovnu. Do ní jsem v únoru 2023 přidal atributy SensitiveParameter, aby ve výjimkách nebyly vidět secrety v parametrech ve stack tracu, akorát jsem tam někde dal čárku na konec řádku navíc, což se nelíbí starším PHP. Bohužel se automaticky nespouštěly testy ve všech podporovaných PHP verzích, takže se na to nepřišlo včas. Obojí jsem o pár týdnů později vyřešil, ale trvalo to do září, než se ty opravy zamergovaly. Ještě v den přednášky v říjnu 2024 některé moje pull requesty nebyly mergnuté, ale Antonio to hned druhý den udělal. Asi jsem to tou přednáškou přivolal, dobrý vědět jak to funguje. Antonio sám přiznává, že další rozvoj už dělat nechce. Tohle není nic proti Antoniovi, spolupráce nad pull requesty s ním byla v pohodě, ale je to jen další z mnoha příkladů a případů, které čekají na svého Jia Tana. V tomto případě skrytě doufám, že bych se jím mohl stát já, samozřejmě jen s těmi nejlepšími úmysly – což je přesně to, co by řekl úplně každý Jia Tan.

#17 I tato knihovna je docela používaná, skoro 44 milionů instalací celkem, denně 50 tisíc, trend je ještě o něco dramatičtější, než u té předchozí knihovny. Už se úplně těším, až budu vybírat další knihovnu na 2FA. Ten algoritmus vytváření a ověřování těch měnících se kódů je celkem jednoduchý, takže na to možná žádná knihovna ani není potřeba. Ale na vytvoření QR kódů apod. už spíš jo.

#18 Charles Bukowski, původem německý básník a spisovatel, jednoho dne prý určil komu patří svět (ve skutečnosti neurčil, ale mohl by), ale popravdě řečeno, já bych se z toho někdy vážně podělal. A to jsem ani nezmínil jak se v PHP zdrojácích na chvilku ocitl backdoor využívající HTTP hlavičku User-Agentt (s dvěma t) a jak k tomu došlo (btw, podepisování commitů je s 1Passwordem hračka), ani o SolarWinds, ani o TeamCity od JetBrains, ani o Okta a jaký vliv to mělo na další firmy třeba jako právě 1Password (i kvůli tý jejich až brutální transparentnosti je mám rád i jako firmu), ani o …, nebo o …

Na druhou stranu, problém se mnozí snaží řešit na různých úrovních: GitHub má Dependabota, který umí upozornit na nové verze, které opravují bezpečnostní chyby. Na GitHubu můžete třeba i kontrolovat kde jaká binárka byla sestavená. V PHP můžete kontrolovat balíčky pomocí composer audit a podobně v JavaScriptu pomocí npm audit. Bezpečnost dodavatelského řetězce do nějaké míry řeší i evropská směrnice NIS2.

O důležitosti dodavatelů se mohli na vlastní kůži přesvědčit i kriminálníci, na které cílila Operace Trojský štít (Operation Trojan Shield), ve které údajně zabezpečenou komunikační síť ANOM ve skutečnosti provozovala FBI – jak to dopadlo si asi dokážete představit, ale kdyby náhodou ne, tak Joseph Cox o tom napsal knížku Dark Wire a udělal přednášku na DEF CONu.

Už možná chápete proč bych se z toho občas poto, že jo.