UEFI Bootkit: Bootkitty na Linuxu a odkaz BlackLotus

Informatec Digital » Linux » UEFI Bootkit: Bootkitty na Linuxu a odkaz BlackLotus

Bootkity UEFI se staly jedním z nejznepokojivějších vektorů v moderním prostředí hrozeb: běží před operačním systémem, dokáží deaktivovat obranu a dosáhnout trvalosti se zvýšenými oprávněními. V posledních letech jsme se dostali od pouhých testů konceptu k aktivním reálným případům, jako je BlackLotus ve Windows, a nyní se objevil první design orientovaný na Linux s názvem Bootkitty, který ohlašuje novou éru ekosystému svobodného softwaru.

Tento článek shromažďuje a uspořádává klíčové informace z několika renomovaných zdrojů, aby vysvětlil, jak fungují bootkity UEFI , co odlišuje Bootkitty v Linuxu, proč BlackLotus změnil pravidla hry pro Windows, jaké indikátory kompromitace si všímat a jaká obranná opatření zavést. Diskutuje také relevantní případy, jako jsou LoJax, ESPecter, MoonBounce a MosaicRegressor, a také související pravidla detekce a taktiky MITRE ATT&CK.

Co je to UEFI bootkit a proč představuje vážné riziko?

UEFI bootkit je škodlivý kód, který se spouští v raných fázích bootování, kdy firmware inicializuje zařízení a předtím, než operační systém převezme kontrolu. Tím, že pracuje na tak nízké úrovni, může deaktivovat mechanismy, jako je ověřování podpisu nebo načítání legitimních ovladačů, nasazovat datové části v režimu jádra nebo uživatele a zůstat skrytý před většinou tradičních protiopatření.

Je důležité rozlišovat mezi různými úrovněmi škodlivého bootovacího softwaru: firmwarové implantáty (např. LoJax v roce 2018) přímo upravují SPI flash, zatímco bootkity se obvykle nacházejí v systémovém oddílu EFI (ESP), který je dostupnější, ale má podobné schopnosti převzít včasnou kontrolu nad bootovacím procesem.

Nedávný vývoj zranitelností v UEFI a nedostatečné včasné odvolání vadných binárních souborů v databázi odvolání (dbx) usnadnil útočníkům zneužití podepsaných, ale zranitelných komponent k obejití Secure Boot , jak se stalo v případě zneužití CVE-2022-21894 (Baton Drop) v případě BlackLotus.

Historický kontext: od PoC ve Windows k praktickým případům

První velká veřejná demonstrace moderního bootkitu UEFI se datuje do roku 2012, kdy Andrea Allievi zdokumentoval koncept (PoC) schopný fungovat v prostředí Windows s UEFI. Následovaly další testy – EfiGuard, Boot Backdoor, UEFI-bootkit – které prokázaly technickou proveditelnost tohoto přístupu.

Po této počáteční experimentální fázi trvalo roky, než se aktivní hrozby objevily na reálných systémech. V roce 2021 byly vydány ESPecter (zkoumaný společností ESET) a bootkit FinSpy (analyzovaný společností Kaspersky) a v roce 2023 se objevil BlackLotus, první známý bootkit, který obchází UEFI Secure Boot na plně aktualizovaných systémech Windows 11.

Až donedávna měly všechny tyto případy jeden společný rys: zaměřovaly se výhradně na Windows . Toto paradigma bylo narušeno objevem Bootkitty, který se zaměřuje na Ubuntu, a tedy i na svět Linuxu.

Bootkitty: první UEFI bootkit zaměřený na Linux

V listopadu 2024 se na serveru VirusTotal objevila neznámá aplikace UEFI ( bootkit.efi ). Analýza odhalila, že se jedná o Bootkitty, první bootkit UEFI určený pro Linux , konkrétně pro určité verze Ubuntu. Podle dostupné telemetrie neexistují žádné důkazy o jejím nasazení v divokém světě; vše ukazuje na raný koncept s mnoha vývojovými artefakty.

Důležitá aktualizace: Začátkem prosince 2024 bylo potvrzeno, že se jedná o akademický projekt vyvinutý účastníky korejského programu Best of the Best (BoB). Jeho deklarovaným cílem bylo zvýšit povědomí o rizicích a podpořit proaktivní opatření. To se shoduje s pozorováním analytiků: funkční bootkit s omezenou podporou a známkami ověření konceptu, nikoli hotová zbraň pro masové kampaně.

Kompatibilita, podpis a signály PoC

Bootkitty je dodáván s certifikátem s vlastním podpisem , takže jej nelze spustit, pokud je povoleno Secure Boot, pokud nejsou certifikáty útočníka přidány ručně. Jeho logika se i tak pokouší umožnit normální pokračování procesu spouštění jádra tím, že předtím, než GRUB předá kontrolu, nainstaluje ověřovací funkce do paměti.

Jeho kompatibilita je omezená. Pro nalezení funkcí k úpravě používá kódované bajtové vzory , které nepokrývají více verzí jádra nebo GRUBu, takže je funkční pouze v určitých konfiguracích a pravděpodobně způsobí pády, pokud offset neodpovídá aktuální verzi.

Mezi artefakty dokazující koncept jsou dvě rutiny, které vypisují ASCII obrázek s názvem Bootkitty a seznamem možných autorů; navíc při spuštění zobrazuje specifické řetězce a odkazy, jako například „BlackCat“, které nesouvisejí se skupinou ransomwaru ALPHV/BlackCat. Binární soubor také přepisuje řetězec a banner verze pro Linux textem „BoB13“.

Řetězec spouštění a hooky v UEFI a GRUB

Po spuštění Bootkitty kontroluje stav SecureBoot přečtením odpovídající proměnné UEFI. Poté nainstaluje hooky na ověřovací protokoly UEFI – EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication a EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState – aby vynutil EFI_SUCCESS jako výsledek a přepsal skutečné vyhodnocení integrity obrazu UEFI PE.

Dále načte legitimní GRUB z ESP, který se nachází v pevně zakódované cestě /EFI/ubuntu/grubx64-real.efi (pravděpodobně kopie uložená útočníkem). S GRUBem v paměti, ale ještě nespuštěným, bootkit opraví a zachytí několik kritických bodů, včetně:

• peimage::start_image (vložený do GRUBu), aby zachytil okamžik, kdy je do paměti načten EFI stub jádra (vmlinuz.efi). Odtud Bootkitty vyhledá a opraví rutinu zodpovědnou za dekompresi jádra, s největší pravděpodobností zstd_decompress_dctx v závislosti na sestavení.
• shim_lock_verifier_init, součást shim_lock v GRUBu, ačkoli použitý hook je irelevantní, protože jiný hook brání jeho spuštění, a modifikace také zavádí příznak GRUB_VERIFY_FLAGS_SINGLE_CHUNK, který teoreticky ztvrdne ověření.
• grub_verifiers_open, který je upraven tak, aby se vrátil okamžitě bez vyvolání kontrol podpisů, čímž se neutralizuje normální tok ověación v GRUBu.

Dekompresní hook pro jádro a záplaty paměti

Dekomprese jádra pomocí hooku dočasně obnoví původní bajty, umožní funkci Authentique dekomprimovat obraz a poté aplikuje záplaty do paměti nyní rozšířeného jádra. Tato fáze je kritická pro deaktivaci ovládacích prvků a přípravu na načtení dalších modulů nebo binárních souborů.

Konkrétně pozorovaná logika přepisuje řetězec verze na „BoB13“ , upravuje funkci module_sig_check tak, aby vracela hodnotu 0 (jádro tedy akceptuje nepodepsané moduly i s povoleným Secure Boot, s CONFIG_MODULE_SIG_FORCE nebo s module.sig_enforce=1) a nahrazuje první proměnnou prostředí procesu init na „LD_PRELOAD=/opt/injector.so /init“.

Myšlenkou LD_PRELOAD je vynutit prioritní načítání sdíleného souboru ELF za účelem přepsání funkcí nebo vložení další logiky, což je běžná technika při útocích v uživatelském prostředí. Přítomnost „/init“ v hodnotě LD_PRELOAD je pozoruhodná; její přesný význam není zcela jasný a posiluje interpretaci, že se jedná o ranou fázi vývoje.

Během laboratorních testů systém po spuštění pomocí Bootkitty ukázal, že jádro je poškozené ; navíc byly v souboru dmesg viditelné upravené řetězce a stopy proměnné LD_PRELOAD, což bylo možné vidět i v souboru /proc/1/environ . Na systémech se zapnutým Secure Bootem je empirickým ukazatelem, že jádro akceptuje načítání nepodepsaného modulu za běhu, což by se nemělo stát bez předchozí aktualizace.

BCDropper a BCObserver: související pomocné součásti

Souběžně byl objeven nepodepsaný modul jádra s přezdívkou BCDropper , který nahrál na VirusTotal stejný odesílatel jako bootkit. Obsahuje odkazy na „BlackCat“ v ladicích řetězcích a cestách a funkci skrytí souborů (filtrování názvů s předponami jako „ injector “, v souladu s LD_PRELOAD odkazujícím na /opt/injector.so).

BCDropper extrahuje vložený ELF soubor s názvem BCObserver z /opt/observer a spouští ho pomocí /bin/bash. Také odstraňuje vlastní trasování ze seznamu načtených modulů a poskytuje typické funkce rootkitu (skrývání souborů, procesů, portů), ačkoli dropper je všechny přímo nevyužívá.

BCObserver čeká na spuštění správce zobrazení gdm3 a poté se pokusí načíst /opt/rootkit_loader.ko pomocí systémového volání finit_module , čímž zajistí, že modul bude vložen, jakmile systém již dokončí grafické spuštění.

Není absolutní jistota, že tyto části jsou spojeny se stejným autorem jako Bootkitty, ale záplata module_sig_check naznačuje, že účelem bylo umožnit načítání nepodepsaných modulů, což odpovídá tomu, co dělá BCDropper/BCObserver.

Relevantní IoC a techniky pro MITRE ATT&CK

Následující indikátory zapojení a klasifikace mohou pomoci při hledání počátečních signálů v prostředích Linuxu, kde mohl být PoC testován:

SHA-1	název	Detekce	popis
35ADF3AED60440DA7B80F3C452047079E54364C1	bootkit.efi	EFI/Agent.A	Bootkitty Bootkit UEFI.
BDDF2A7B3152942D3A829E63C03C7427F038B86D	kapátko.ko	Linux/Rootkit.Agent.FM	BCDropper.
E8AF4ED17F293665136E17612D856FA62F96702D	pozorovatel	Linux/Rootkit.Agent.FM	BCObserver.

Nejvýznamnější mapování MITRE ATT&CK pro tuto sadu částí a pozorovaného chování, užitečné pro základní model hrozby :

Taktika	ID	název	popis
Rozvoj zdrojů	T1587.001	Rozvoj schopností: Malware	Bootkitty je Bootkit UEFI nový.
	T1587.002	Rozvíjet schopnosti: Certifikáty pro podepisování kódu	Vzorek podepsaný certifikované s vlastním podpisem.
Provedení	T1106	Nativní API	BCObserver používá finit_module načíst LKM.
	T1129	Sdílené moduly	Síla Bootkitty LD_PRELOAD v inicializaci.
Perzistence	T1574.006	Tok provádění únosu: Únos dynamického linkeru	Opravy prostředí init s LD_PRELOAD.
	T1542.003	Spuštění před spuštěním operačního systému: Bootkit	Nasazení v ESP.
Obranný únik	T1014	Rootkit	BCDropper jako LKM pro utajení.
	T1562	Oslabit obranyschopnost	Zakázat ověřování firmy v GRUBu a jádře.
	T1564	Skrýt artefakty	Skrýt modul ze seznamu moduly del kernel.

Trasování na systémech Linux a návrhy na zmírnění problémů

V postižených instalacích Ubuntu byly pozorovány forenzní důkazy, jako například změna řetězce verze jádra na BoB13 (viditelné pomocí `uname -v`), úpravy bootovacího banneru (`dmesg`) a přítomnost `LD_PRELOAD` v `/proc/1/environ` . Jádro může být označeno jako poškozené, což je chování, ke kterému bez bootkitu nedochází.

Rychlým řešením situace, kdy bootkit nahradí GRUB, je obnovit legitimní soubor z /EFI/ubuntu/grubx64-real.efi do jeho původního umístění na adrese /EFI/ubuntu/grubx64.efi, aby bootkit spustil skutečný GRUB. Mějte na paměti, že se to týká pouze konkrétního scénáře , kdy nasazení proběhlo přesně tak, jak je popsáno.

BlackLotus: paradigmatický případ ve Windows

BlackLotus se proslavil svou schopností spouštět bootkit UEFI i na plně aktualizovaném Windows 11 s povoleným Secure Boot. Od října 2022 byl k dispozici za 5 000 dolarů (200 dolarů za upgrade) s geofencingu , který měl zabránit přístupu k systémům v Arménii, Bělorusku, Kazachstánu, Moldavsku, Rumunsku, Rusku a na Ukrajině.

Zneužívala zranitelnost CVE-2022-21894 (Baton Drop) , kterou Microsoft opravil v lednu 2022, ale která byla i poté stále zneužitelná, protože zranitelné, podepsané binární soubory stále nebyly přidány do seznamu zneplatněných souborů UEFI (dbx). Instalační program zavádí platně podepsané kopie zranitelných zavaděčů, aby dosáhl perzistence a obešel zabezpečené spouštění.

Mezi jeho funkce patřilo zakázání BitLockeru, integrity paměti (HVCI) a Microsoft Defenderu; nasazení ovladače jádra , který chránil soubory bootkitu na ESP; a spuštění uživatelského režimu HTTP downloaderu v souboru winlogon.exe s využitím technik anti-VM, anti-debugging a obfuscation. Velikost bootkitu byla malá (kolem 80 KB), což přispívalo k jeho nenápadnosti.

Byly zdokumentovány interní kódy a kuriózní artefakty, jako například odkazy na řadu Higurashi v názvech komponent a certifikátu s vlastním podpisem, a také nepoužívané zmatené zprávy. Tyto podrobnosti nesnižují jeho nebezpečí, ale poskytují kontext o jeho vývoji.

Jak systém Windows chrání spouštění: Bezpečné spouštění, Důvěryhodné spouštění, ELAM a Měřené spouštění

Ve Windows se řetězec důvěryhodnosti zavádění opírá o několik vrstev. Secure Boot ověřuje podpisy firmwaru a zavaděče; Trusted Boot ověřuje integritu jádra a komponent zavádění; ELAM upřednostňuje načítání antimalwarového ovladače před jinými ovladači zavádění od jiných společností než Microsoft; a Measured Boot zaznamenává hash hodnoty v TPM pro vzdálenou ověření.

Certifikovaná zařízení mají ve výchozím nastavení povoleno Secure Boot a důvěřují certifikátu společnosti Microsoft a dalším schváleným bootloaderům. Ponechání povolené certifikační autority UEFI od třetí strany od společnosti Microsoft však rozšiřuje oblast útoku tím, že důvěřuje bootloaderům z více distribucí, včetně těch se známými zranitelnostmi. Mnoho zařízení s chráněným jádrem vyžaduje zakázání důvěryhodnosti v tuto certifikační autoritu třetí strany, aby se posílila výchozí bezpečnostní situace .

Pro povolení provozu Linuxu v chráněných prostředích se doporučuje explicitně přidat podpis požadovaného bootloaderu do databáze UEFI nebo v krajním případě zakázat funkci Secure Boot – opatření, které výrazně snižuje ochranu před bootkity . V obou případech tyto změny vyžadují ruční úpravu firmwaru a nelze je automatizovat škodlivým softwarem.

Ověřování měřeného spouštění umožňuje důvěryhodnému serveru posoudit, zda koncový bod udržuje neporušený řetězec spouštění. TPM podepisuje důkazy a v kombinaci s další telemetrií umožňuje izolaci napadených zařízení v karanténních sítích až do nápravy.

Pravidla proaktivní detekce a sledování

Kromě nativní instrumentace systému Windows publikovala komunita užitečná pravidla Sigma pro detekci aktivity spojené s těmito scénáři. Patří mezi ně vytvoření souboru firmwaru v System32 nesystémovým procesem a deaktivace integrity paměti High-VCI pomocí klíčů registru (techniky MITRE ATT&CK T1562 a T1112). Tyto detekce jsou mapovány na více systémů SIEM/EDR/XDR.

V Linuxu je vhodné korelovat události spouštění (journald/dmesg), změny proměnných prostředí PID 1 pomocí uname -vy a kontrolovat načítání nepodepsaných modulů nebo podezřelé operace ESP . Integrace těchto tras s pravidly chování v EDR zvyšuje pravděpodobnost detekce včasného pokusu o perzistenci.

Širší obrázek: LoJax, ESPecter, MoonBounce, MosaicRegressor a nové signály

Prvním pozorovaným implantátem firmwaru UEFI byl LoJax (2018), následovaný kampaněmi s MosaicRegressor a MoonBounce, přičemž druhý jmenovaný byl pozoruhodný tím, že zvýšil laťku sofistikovanosti rootkitů UEFI . V roce 2021 ESPecter a bootkit FinSpy ukázaly, že fáze před operačním systémem zůstává atraktivním cílem pro pokročilé aktéry.

V linuxové aréně byl Bootkitty prvním funkčním testem svého druhu, i když s omezeným rozsahem. A již v roce 2025 se objevily zmínky o „ HybridPetya “ jako o vývoji rodiny Petya s funkcemi UEFI bootkitu, přičemž vzorky byly na VirusTotal nahrány z Polska . Ačkoli je analýza stále předběžná, slouží jako připomínka toho, že tato kategorie hrozeb se neustále rozšiřuje.

Praktická doporučení ke snížení rizika

V prostředí Linuxu jsou nedílnou součástí udržování zapnutého Secure Boot , používání aktualizací firmwaru (UEFI) a jádra a zajištění aktuálního seznamu zneplatněných modulů (dbx). Sledujte, zda je `module.sig_enforce` nastaveno na 1 nebo zda je `CONFIG_MODULE_SIG_FORCE` povoleno, když je to vhodné, a vyhněte se načítání modulů z nedůvěryhodných zdrojů.

Pravidelně auditujte oddíl ESP , zda nedošlo k neoprávněným změnám cest, jako například /EFI/ubuntu/grubx64.efi, a ověřujte, zda neexistují žádné podezřelé „kopie“ (grubx64-real.efi). Jakákoli změna v ověřovacím procesu GRUB by měla být prošetřena.

Ve Windows kromě Secure Boot posiluje Trusted Boot, umožňuje HVCI , pokud je hardwarem podporováno, a využívá vzdálenou atestaci založenou na TPM se zásadami podmíněného přístupu . Minimalizuje závislost na certifikačních autoritách třetích stran, pokud to není nezbytně nutné, a urychluje přijetí odvolání , když hlásí selhání v komponentách spouštění.

Některá komerční řešení integrují skenery UEFI schopné skenovat firmware a vyhledat škodlivé komponenty . Společnost ESET tvrdí, že je jediným dodavatelem koncových zařízení z 20 nejlepších tržeb, který tuto integrovanou funkci nabízí svým zákazníkům. Tento přístup může přidat hodnotu k hloubkové hardwarové ochraně .

Trajektorie nedávných kampaní jasně ukazuje, že bootlink zůstává hlavním cílem. Se správnou telemetrií , posílením firmwaru/bootloaderu a systematickými kontrolami integrity je možné výrazně zvýšit laťku a ztížit život protivníkům.

Nejmodernější UEFI bootkity potvrzují, že hranice mezi Proof of Concept (PoC) a reálným provozem se překračují stále rychleji: Bootkitty ukazuje, že Linux je již v hledáčku, BlackLotus upevnil životaschopnost na Windows a obranný ekosystém musí upřednostňovat hygienu bootování, aktualizace dbx, monitorování IoC a vzdálenou atestaci, aby se v zárodku potlačily jakékoli pokusy o perzistenci před spuštěním operačního systému.