UEFI Bootkit: van laboratorium naar realiteit, met focus op Bootkitty en BlackLotus

De UEFI-bootkits In slechts een paar jaar tijd zijn ze van een laboratoriumconcept uitgegroeid tot een ware hoofdpijn voor verdedigers en fabrikanten. Op dit gebied is de grens tussen proof of concept en operationele dreiging vaag, en gevallen zoals Zwarte Lotus of de recente ontdekking van Bootkitty op Linux Ze bewijzen het ruimschoots.

Dit artikel brengt de volgende onderwerpen samen en legt ze uit: duidelijke taal en technische details wanneer ze waarde toevoegen, de meest relevante gepubliceerd door onderzoekers en bedrijven in de sector: van de eerste PoC in 2012 tot moderne campagnes, inclusief kwetsbaarheden zoals CVE-2024-7344 waarmee u Secure Boot, ontwijkingstechnieken, IoC's en detectie- en mitigatiemaatregelen kunt omzeilen die in de praktijk daadwerkelijk werken.

Wat is een UEFI-bootkit en waarom is het zo problematisch?

Een UEFI-bootkit is een implantaat dat draait vóór het besturingssysteem, met het vermogen om de stroom van Boot, schakel controles uit en laad componenten met hoge privileges. Door op zo'n laag niveau te werken, kunt u traditioneel antivirusprogramma en zelfs bepaalde "veilige startmaatregelen" als er misbruik wordt gemaakt van gebreken of permissieve configuraties.

In de echte wereld zijn al persistente UEFI-implantaten en -technieken waargenomen, zoals LoJax, MozaïekRegressor o Maan stuiterenmijlpalen die laten zien hoe een acteur kan bezetten de firmware en de kritieke fasen van de laars beheersen, waardoor de forensische analyse en sanering.

Verdedigen WindowsMicrosoft koppelt verschillende lagen aan elkaar: Beveiligd Opstarten (UEFI valideert de loader met vertrouwde certificaten), Trusted Boot (de kernel valideert de rest van de componenten), ELAM (Early Launch Antimalware, dat opstartstuurprogramma's inspecteert) en Gemeten laars (TPM-metingen en attestatie op afstand). Dit zijn nuttige, maar niet onfeilbare, barrières voor kwetsbaarheden van het ecosysteem zelf UEFI of te brede vertrouwensinstellingen. Daarnaast is het mogelijk schild Windows met Credential Guard, BitLocker en WDAC om het risico op persistentie op de lange termijn te verminderen.

Van PoC's tot het echte leven: tijdlijn en belangrijkste spelers

De reis begint in 2012 met de PoC van Andrea Allievi voor Windows op UEFI, gevolgd door projecten zoals EfiGuard, Boot Backdoor of UEFI-bootkit. Het duurde jaren voordat er gevallen in het wild werden gedocumenteerd, zoals ESPecter (ESET, 2021) of de FinSpy bootkit (Kaspersky, 2021), en in 2023 barstte het op het toneel los Zwarte Lotus, de eerste UEFI-bootkit die in staat is Secure Boot omzeilen op volledig bijgewerkte systemenIn laboratoriumomgevingen is het gebruikelijk malware testen op een virtuele machine om PoC's en detecties te evalueren zonder de productieve infrastructuur in gevaar te brengen.

Eén ding was tot nu toe constant gebleven: het doel was uitsluitend Windows-computersDie veronderstelling werd aan diggelen geslagen toen in november 2024 een UEFI-app genaamd VirusTotal op VirusTotal verscheen. bootkit.efiUit de analyse bleek dat er een bootkit bestond, die door de auteurs werd omschreven als Bootkitty, ontworpen om Linux (Ubuntu)Volgens de telemetrie is er geen daadwerkelijke inzet bevestigd; en de auteurs zelf, verbonden aan het Koreaanse trainingsprogramma Het beste van het beste (BoB), verduidelijkten ze dat het een proof of concept met als doel bewustzijn te creëren.

Het Bootkitty-binaire bestand is ondertekend met een zelfondertekend certificaatDit betekent dat het niet zal werken met Secure Boot ingeschakeld, tenzij de certificaten van de aanvaller installerenNiettemin illustreert de logica ervan hoe een actor in het geheugen componenten van de lader (GRUB) en linux-kernel om controles te omzeilen.

Bootkitty in detail: artefacten, compatibiliteit en wat het wijzigt

De bootkit bevat ongebruikte functies die ASCII-kunst afdrukken met de naam Bootkitty en een lijst met mogelijke auteurs. Het toont ook tekstreeksen bij elke start en verwijzingen naar Zwarte kat in de uitvoer ervan en in een gerelateerde kernelmodule, die geen verband houdt met de ALPHV/BlackCat-ransomware; deels omdat Bootkitty is geschreven in C, terwijl ALPHV zich ontwikkelt in Rust.

De compatibiliteit is beperkt. Om te vinden welke functies u moet aanraken, gebruikt u gecodeerde bytepatronen (een klassieke bootkit-techniek), maar de gekozen patronen dekken meerdere kernel- of GRUB-versies niet goed. Het resultaat is dat het implantaat slechts in een zeer beperkte set configuraties functioneel is, en bovendien, patches vaste offsets na kerneldecompressie: als de offsets niet overeenkomen met de versie, kan het willekeurige gegevens overschrijven en ophangen in plaats van een verbintenis.

De laars begint met shim Bootkitty uitvoeren, dat eerst de status van opvraagt SecureBoot en plaatst hooks in twee UEFI-authenticatieprotocollen: EFI_SECURITY2_ARCH_PROTOCOL.Bestandsauthenticatie y EFI_SECURITY_ARCH_PROTOCOL.Bestandsauthenticatiestatus. In beide gevallen moet de uitvoer worden ingesteld op return EFI_SUCCES, waardoor de PE-beeldintegriteitscontrole tijdens de pre-OS effectief wordt genegeerd.

Bootkitty laadt vervolgens een legitieme GRUB vanaf een hardgecodeerd pad op de ESP (/EFI/ubuntu/grubx64-real.efi), patch het in het geheugen en haken sleutelfuncties voordat het wordt uitgevoerd.

Aansluiten op GRUB en de Linux-kernel uitpakken

Het implantaat verandert de functie start_afbeelding van de module afbeelding van GRUB, verantwoordelijk voor het lanceren van reeds geladen PE-binaries (zoals de EFI-kernelstub, vmlinuz.efi/vmlinuz). Maak gebruik van het feit dat de kernel al in het geheugen staat en plaats een hook in de routine die de daadwerkelijke kernelimage decomprimeert (waarschijnlijk zstd_decomprimeren_dctx (afhankelijk van de build), dus zodra het is uitgepakt, kunt u hot patch het.

Het wijzigt ook de functie grub_verifiers_open, die beslist of de integriteit van elk geladen bestand (modules, kernel, configuratie, enz.) moet worden gecontroleerd. De hook retourneert onmiddellijk, en dus, vermijdt elke verificatie van de handtekening. De aanpassing van zijn kant in shim_lock_verifier_init Het is verwarrend: het dwingt een strengere verificatievlag af (GRUB_VERIFY_FLAGS_ENKELE_STUK), maar deze functie wordt niet eens aangeroepen door de andere haak, waardoor Irrelevant.

Zodra de kernel is gedecomprimeerd, past de Bootkitty-code drie geheugenwijzigingen toe: het herschrijft de versie/banner string vanuit de kernel met de tekst "BoB13"; forceer dat module_sig_check() retourneer 0 voor de kernel om te laden niet-ondertekende modules; en vervangt de eerste omgevingsvariabele van het proces init injecteren LD_PRELOAD=/opt/injector.so /init aan het begin van de gebruikersruimte.

Injectie door LD_PRELOAD Dit is een klassieke tactiek om een ​​gedeeld ELF-object te prioriteren en functies te overschrijven. De keten heeft hier een eigenaardigheid (er staat "/init" naast LD_PRELOAD), een detail dat het karakter van de keten versterkt. Onvoltooide PoC in plaats van een gepolijste operatie. De zogenaamd geïnjecteerde binaire bestanden werden niet waargenomen, hoewel een latere publicatie van een derde partij aangaf dat ze alleen worden gebruikt voor een extra fase laden.

Indicatoren, symptomen en een eenvoudige oplossing

Als Bootkitty aanwezig is, zijn er zichtbare hints te zien. Het commando uname -v zal de kernelversie weergeven met de tekst gewijzigd en in dmesg De banner kan ook gewijzigd lijken. Daarnaast is het mogelijk om te detecteren dat het proces PID1 (init) werd uitgebracht met LD_PRELOAD inspecteren /proc/1/omgeving, een afwijkend signaal in legitieme systemen.

Bij laboratoriumtests verschijnt de kernel bedorven na het opstarten met Bootkitty, en een andere empirische controle op computers met Secure Boot ingeschakeld, is om te proberen een ongetekende module: Als warm laden is toegestaan, suggereert dit dat module_sig_controle is gepatcht.

Als de bootkit is geïnstalleerd door het GRUB-binaire bestand te vervangen door een tussenliggend bestand (waargenomen gedrag), is een eenvoudige manier om te herstellen het verplaatsen van de Legitieme GRUB van /EFI/ubuntu/grubx64-real.efi naar zijn oorspronkelijke route /EFI/ubuntu/grubx64.efi voor shim voer het uit en de opstartketen gaat door zonder de implantaat.

BCDropper en BCObserver: samenhangende puzzelstukjes of gewoon toeval?

Er werd een niet-ondertekende kernelmodule met de bijnaam Bootkitty gevonden naast Bootkitty BCDropper, die aanwijzingen deelt met de bootkit: strings Zwarte kat/zwarte kat in metadata en debugpaden, en een functie van bestand verbergen waarvan de voorvoegsels "injector" bevatten (in overeenstemming met de variabele LD_PRELOAD verwijzend naar /opt/injector.so).

BCDropper laat in /opt/observer een ingebedde ELF (genoemd BCO-server) en lanceert het via / bin / bashDit vrij eenvoudige onderdeel wacht op gdm3 is actief en laadt vervolgens een kernelmodule van /opt/rootkit_loader.ko gebruik eindige_module, en zorg ervoor dat u dit doet nadat het systeem volledig is opgestart.

Hoewel er tekenen zijn van een relatie, is het niet mogelijk om te garanderen dat beide elementen van dezelfde auteur afkomstig zijn of dat ze ontworpen zijn om samen te werken. Om het nog erger te maken, de kernelversie die in de metadata wordt genoemd (6.8.0-48-generic) wordt niet eens genoemd onder de door de bootkit.

Geassocieerde IoC's

De volgende artefacten zijn in verband gebracht met de besproken bevindingen. Hun waarde is voornamelijk: verwijzing en laboratorium:

BlackLotus en CVE-2022-21894: de mijlpaal die de sluizen opende

BlackLotus is sinds 2022 op de markt met een prijs van ongeveer 5.000 USD (plus extra's per upgrade) en bevat technieken voor anti-VM/anti-debug ontwijking, geofencing om bepaalde landen te vermijden (Armenië, Wit-Rusland, Kazachstan, Moldavië, Roemenië, Rusland en Oekraïne) en, nog belangrijker, de uitbuiting van CVE-2022-21894 (Baton Drop) voor Secure Boot omzeilen en een robuuste persistentie bereiken op volledig gepatchte Windows 10/11-machines.

De door de veiligheidsgemeenschap beschreven stroom omvat een eerste fase met deactivering van beveiligingen van het besturingssysteem, het misbruiken van de verouderde kwetsbaarheid in Secure Boot en de het registreren van een machine-eigenaarssleutel gecontroleerd door de aanvaller. Na verdere herstarts zet het implantaat een kernel driver en een gebruikersmoduscomponenttype downloader om de commando- en controlecommunicatie te beheren en extra kosten.

Voor proactieve verdediging heeft de community operationele regels gepubliceerd. Zo biedt SOC Prime Sigma-detecties die zoeken naar de verdachte aanmaak van firmwarebestanden in System32 door niet-systeemprocessen of de HVCI-deactivering via logging. Deze typen signalen, gekoppeld aan MITRE ATT&CK (bijv. T0857, T1562, T1112), helpen om jacht op afwijkende activiteit die meestal bij bootkits wordt geleverd; er zijn ook praktische handleidingen voor Detecteer kwaadaardige processen met Process Explorer in Windows-omgevingen.

CVE-2024-7344: Niet-vertrouwde UEFI-binaries laden via "reloader.efi"

In 2024 werd een bijzonder gevoelige kwetsbaarheid ontdekt, CVE-2024-7344, wat van invloed is op meerdere herstelsuites die door het certificaat zijn ondertekend Microsoft Corporation UEFI CA 2011De kern van het probleem is het gebruik van een aangepaste PE-lader in de UEFI-applicatie herlader.efi, in plaats van veilige API's LoadImage/StartImage. Het binaire bestand decodeert en voert inhoud uit van een bestand mantel.dat zonder de handtekeningen te verifiëren volgens het beleid van Beveiligd Opstarten.

De vector is niet beperkt tot computers waarop de software is geïnstalleerd, aangezien een aanvaller met verhoogde privileges de kwetsbare binaire in de ESP (EFI-partitie) van elk systeem dat de UEFI CA van derden van Microsoft vertrouwt en de uitvoering van een UEFI niet ondertekend tijdens het opstarten. De getroffen producten omvatten suites van Howyar, Greenware, Radix, SANFONG, Wasay, CES en Signal Computer, evenals gecorrigeerd en ingetrokken op 14 januari 2025.

Om de bescherming te verifiëren en PowerShell met verhoogde privileges en in Linux (LVFS/dbxtool):

# ¿El sistema confía en la UEFI CA 2011 de Microsoft? (posible exposición)
::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Corporation UEFI CA 2011'

# Revocación instalada (64 bits)
::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'

# Revocación instalada (32 bits)
::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'

# Linux (dbxtool)
dbxtool --list | grep 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'
dbxtool --list | grep 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'

Deze zaak heropent het debat over de keten van vertrouwen: Microsoft onderhoudt twee certificaten die algemeen beschikbaar zijn op consumenten- en zakelijke UEFI-computers (Windows Productie CA 2011 y UEFI CA 2011 voor derden). Het plan is om te migreren naar certificaten 2023, na incidenten zoals BlackLotus en de proliferatie van kwetsbare bootloaders die jaren geleden zijn ondertekend. Op computers Beveiligde kern, UEFI CA van derden wordt meestal geleverd standaard uitgeschakeld.

Praktische bescherming en aanpassing van Secure Boot

Verder dan het toepassen UEFI-intrekkingen en houd de firmware/OS up-to-date (Windows update en LVFS) zijn er maatregelen die het aanvalsoppervlak verkleinen: het beheersen van de toegang tot ESP met beveiligingsregels, aanpassen Beveiligd Opstarten om het vertrouwen te beperken tot wat noodzakelijk is (volgens richtlijnen zoals die van de NSA) en implementeren attestatie met TPM om de opstartstatus op afstand te valideren ten opzichte van referentiewaarden.

In Windows is de combinatie van Veilige opstart + vertrouwde opstart + ELAM + gemeten opstart Het biedt gelaagde barrières: ladervalidatie, bootcontrollers die vóór de rest worden geïnspecteerd en een door de TPM waardoor de firewall 'schone' computers kan scheiden van computers met afwijkingen. In beheerde omgevingen vermindert dit de tijd de detectie en inperking.

Op Linux is het, naast intrekkingen en ESP-controle, de moeite waard om te letten op signalen zoals LD_PRELOAD in het proces initde staat bedorven van de kernel en correleren modulelaadgebeurtenissen (bijv. eindige_module) met ongewone routes (/opt/*.ko) om pogingen te detecteren om volharding vroeg.

Gereedschap, dekking en MITRE ATT&CK

Volgens ESET is het de enige leverancier in de top 20 eindpunten qua omzet die een UEFI-firmwarescanner in hun apparatuurbeschermingsoplossingen. Hoewel andere fabrikanten UEFI-gerelateerde technologieën aanbieden, komt hun doel niet altijd overeen met de directe firmware-inspectie. Aangezien UEFI-aanvallen, hoewel sporadisch, totale controle en doorzettingsvermogen Het is bijna absoluut waar, investeren in deze laag kan het verschil maken.

Wat MITRE ATT&CK betreft, passen de geobserveerde gedragingen bij verschillende technieken: Opstarten vóór besturingssysteem: Bootkit (T1542.003), Gedeelde modules/LD_PRELOAD (T1129), ontwikkeling van Malware (T1587.001) en gebruik van certificaten (T1587.002), Plus Rootkit (T1014), Vermindering van de verdediging (T1562) y Artefacten verbergen (T1564) in het geval van kernelmodules die ze verstoppen zich zich.

• T1542.003: Bootkit op de ESP voor pre-OS persistentie.
• T1129: Laad vooraf met LD_PRELOAD tijdens het init-proces.
• T1014: Kernelmodules met rootkitfunctionaliteit.
• T1562 / T1564: Schakel controles uit en verberg ze in het systeem.

Linux is niet onkwetsbaar: de Bootkitty-zaak en nieuwe namen op de radar

Jarenlang heeft het populaire verhaal de toegenomen blootstelling van Windows vergeleken met de veronderstelde "ondoordringbaarheid" van macOS of LinuxDe werkelijkheid is genuanceerder: hun model en aandeel maken hen tot verschillende doelwitten, maar niet immuun. De opkomst van Bootkitty in Linux blijkt dat de kennis om bootkits te maken ook voor dit ecosysteem bestaat, hoewel we het in dit specifieke geval hebben over een Academische PoC met beperkte ondersteuning.

Er is zelfs melding gemaakt van een ransomware-variant, HybridePetya, die UEFI-bootkit-mogelijkheden zou integreren. De voorbeelden die zijn geüpload naar VirusTotal in 2025 uit Polen duiden op een recente ontwikkeling, hoewel ze met de nodige voorzichtigheid moeten worden benaderd. voorzichtigheid totdat er een onafhankelijke analyse en solide toeschrijving is.

Het belangrijkste is om te internaliseren dat de verdediging de volledige bootketen moet bestrijken en het standaardvertrouwen in de bootketen moet minimaliseren. handtekeningen van derden die niet worden gebruikt, controleer de EFI-partitie en consolideer nuttige telemetrie (besmette kernel, modulegebeurtenissen, wijzigingen in GRUB-controleprogramma's of gevoelige UEFI-variabelen) om op tijd te detecteren.

Het huidige beeld van het UEFI-risico combineert PoC's voor educatieve doeleinden, bootkits die als een dienst op de markt worden gebracht en kwetsbaarheden in ondertekende componenten die, als ze niet op tijd worden ingetrokken, de deur openen voor niet-vertrouwde pre-OS-uitvoeringHet up-to-date houden van firmware en intrekkingslijsten, het verkleinen van de vertrouwenscirkel en het monitoren van ESP zijn maatregelen die verdedigers samen een veel sterkere positie geven tegen dit soort bedreigingen.

Gerelateerd artikel:

Windows beveiligen met Credential Guard, BitLocker, AppLocker, Device Guard en WDAC

Isaac

Gepassioneerd schrijver over de wereld van bytes en technologie in het algemeen. Ik deel mijn kennis graag door te schrijven, en dat is wat ik in deze blog ga doen: je de meest interessante dingen laten zien over gadgets, software, hardware, technologische trends en meer. Mijn doel is om u te helpen op een eenvoudige en onderhoudende manier door de digitale wereld te navigeren.