- „Bootkitty“ yra pirmasis UEFI įkrovos rinkinys, skirtas „Linux“, turintis ribotą palaikymą ir prisijungimą prie UEFI/GRUB.
- „BlackLotus“ išnaudojo CVE-2022-21894 ataką, kad apeitų saugų paleidimą ir išjungtų apsaugą sistemoje „Windows“.
- IoC, MITRE ATT&CK ir „Sigma“ aptikimai padeda stebėti įkrovos ir branduolio klastojimą.
UEFI įkrovos rinkiniai tapo vienu labiausiai nerimą keliančių vektorių šiuolaikiniame grėsmių pasaulyje: jie paleidžiami prieš operacinę sistemą, gali išjungti apsaugą ir išlaikyti savo veiklą su padidintomis privilegijomis. Pastaraisiais metais nuo paprastų koncepcijos įrodymų perėjome prie aktyvių realaus pasaulio atvejų, tokių kaip „BlackLotus“ sistemoje „Windows“, o dabar atsirado pirmasis į „Linux“ orientuotas dizainas, pavadintas „Bootkitty“, pradėdamas naują laisvosios programinės įrangos ekosistemos erą.
Šiame straipsnyje surinkta ir susisteminta svarbiausia informacija iš kelių patikimų šaltinių, siekiant paaiškinti, kaip veikia UEFI įkrovos rinkiniai , kuo „Bootkitty“ išskiria „Linux“ sistemoje, kodėl „BlackLotus“ pakeitė žaidimo taisykles „Windows“ sistemoje, į kokius įsilaužimo požymius reikia atkreipti dėmesį ir kokias gynybos priemones reikia įdiegti. Taip pat aptariami svarbūs atvejai, tokie kaip „LoJax“, „ESPecter“, „MoonBounce“ ir „MosaicRegressor“, taip pat susijusios aptikimo taisyklės ir MITRE ATT&CK taktika.
Kas yra UEFI įkrovos rinkinys ir kodėl jis kelia rimtą pavojų?
UEFI įkrovos rinkinys yra kenkėjiškas kodas, kuris vykdomas ankstyvuosiuose paleidimo etapuose, kai programinė įranga inicijuoja įrenginį ir prieš operacinei sistemai perimant valdymą. Veikdamas tokiu žemu lygiu, jis gali išjungti tokius mechanizmus kaip parašo tikrinimas ar teisėtų tvarkyklių įkėlimas, diegti naudingąją apkrovą branduolio arba vartotojo režimu ir likti paslėptas nuo daugumos tradicinių atsakomųjų priemonių.
Svarbu atskirti skirtingus kenkėjiškos įkrovos programinės įrangos lygius: programinės įrangos implantai (pvz., „LoJax“ 2018 m.) tiesiogiai modifikuoja SPI atmintinę, o įkrovos rinkiniai paprastai yra EFI sistemos skaidinyje (ESP), kuris yra lengviau prieinamas, tačiau turi panašias galimybes anksti valdyti įkrovos procesą.
Pastaruoju metu evoliucionavus UEFI pažeidžiamumams ir laiku neatlikus defektinių dvejetainių failų atšaukimų atšaukimų duomenų bazėje (dbx), nusikaltėliams buvo lengviau piktnaudžiauti pasirašytais, bet pažeidžiamais komponentais, siekiant apeiti saugų paleidimą , kaip nutiko išnaudojant CVE-2022-21894 (Baton Drop) ataką „BlackLotus“ atveju.
Istorinis kontekstas: nuo PoC sistemoje „Windows“ iki realių atvejų
Pirmasis didelis viešas modernaus UEFI įkrovos rinkinio demonstravimas įvyko 2012 m., kai Andrea Allievi dokumentavo koncepcijos įrodymą (PoC), galintį veikti „Windows“ aplinkose su UEFI. Po to buvo atlikti kiti testai – „EfiGuard“, „Boot Backdoor“, UEFI įkrovos rinkinys – kurie pademonstravo šio metodo techninį įgyvendinamumą.
Po šio pradinio eksperimentinio etapo prireikė metų, kol aktyvios grėsmės pasirodė realiose sistemose. 2021 m. buvo išleistas „ESPecter“ (tirtas „ESET“) ir „FinSpy“ įkrovos rinkinys (analizuotas „Kaspersky“), o 2023 m. pasirodė „BlackLotus“ – pirmasis žinomas įkrovos rinkinys, apeinantis „UEFI Secure Boot“ visiškai atnaujintose „Windows 11“ sistemose.
Iki pat neseniai visi šie atvejai turėjo bendrą bruožą: jie buvo išskirtinai skirti „Windows“ . Ši paradigma buvo sulaužyta atradus „Bootkitty“, kuri yra skirta „Ubuntu“ ir todėl „Linux“ pasauliui.
„Bootkitty“: pirmasis UEFI įkrovos rinkinys, skirtas „Linux“
2024 m. lapkritį „VirusTotal“ svetainėje pasirodė nežinoma UEFI programa ( „bootkit.efi “). Analizė parodė, kad tai „Bootkitty“ – pirmasis UEFI įkrovos rinkinys, sukurtas „Linux“ , ypač tam tikroms „Ubuntu“ versijoms. Remiantis turimais telemetrijos duomenimis, nėra jokių įrodymų apie diegimą nelegalioje aplinkoje; viskas rodo ankstyvą koncepcijos įrodymą su daugybe kūrimo artefaktų.
Svarbus atnaujinimas: 2024 m. gruodžio pradžioje buvo patvirtinta, kad tai akademinis projektas, kurį sukūrė Korėjos „Best of the Best“ (BoB) programos dalyviai. Jo deklaruojamas tikslas buvo didinti informuotumą apie rizikas ir skatinti imtis aktyvių priemonių. Tai atitinka analitikų pastebėjimus: tai veikiantis rinkinys su ribota parama ir koncepcijos įrodymo požymiais, o ne baigtas ginklas masinėms kampanijoms.
PoC suderinamumas, parašas ir signalai
„Bootkitty“ turi savarankiškai pasirašytą sertifikatą , todėl negali veikti, jei įjungtas saugus įkrovimas, nebent užpuoliko sertifikatai pridedami rankiniu būdu. Nepaisant to, jo logika bando leisti branduolio įkrovimo procesui tęstis įprastai, pataisydama tikrinimo funkcijas atmintyje prieš GRUB perleidžiant kontrolę.
Jo suderinamumas yra ribotas. Norėdamas rasti modifikuojamas funkcijas, jis naudoja užkoduotus baitų šablonus , kurie neapima kelių branduolio ar GRUB versijų, todėl veikia tik tam tikrose konfigūracijose ir gali sukelti gedimus, jei poslinkis neatitinka dabartinės versijos.
Tarp koncepcijos įrodymo artefaktų yra dvi programos, kurios atspausdina ASCII iliustraciją su pavadinimu „Bootkitty“ ir galimų autorių sąrašu; be to, paleidžiant ji rodo konkrečias eilutes ir nuorodas, pvz., „BlackCat“, nesusijusias su ALPHV/BlackCat išpirkos reikalaujančių programų grupe. Dvejetainis failas taip pat perrašo „Linux“ versijos eilutę ir reklamjuostę tekstu „BoB13“.
Vykdymo grandinė ir kabliukai UEFI ir GRUB
Paleidimo metu „Bootkitty“ patikrina „SecureBoot“ būseną nuskaitydama atitinkamą UEFI kintamąjį. Tada ji įdiegia kabliukus UEFI autentifikavimo protokoluose – EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication ir EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState – kad būtų priverstas gauti EFI_SUCCESS kaip rezultatą, nepaisydama faktinio UEFI PE atvaizdo vientisumo įvertinimo.
Toliau iš ESP, esančio užkoduotame kelyje /EFI/ubuntu/grubx64-real.efi , įkeliamas teisėtas GRUB (tikėtina, užpuoliko pateikta kopija). Kai GRUB yra atmintyje, bet dar nėra paleistas, įkrovos rinkinys pataiso ir prijungia kelis svarbius taškus, įskaitant:
- peimage::pradinis_vaizdas (įterptas į GRUB), kad būtų sustabdytas momentas, kai branduolio EFI fragmentas (vmlinuz.efi) įkeliamas į atmintį. Iš čia „Bootkitty“ suranda ir pataiso rutiną, atsakingą už branduolio dekompresiją, greičiausiai zstd_decompress_dctx priklausomai nuo konstrukcijos.
- shim_lock_verifier_init, GRUB shim_lock dalis, nors pritaikytas kabliukas yra nesvarbus, nes kitas kabliukas neleidžia jo vykdyti, o modifikacija taip pat įveda vėliavėlę GRUB_VERIFY_FLAGS_SINGLE_CHUNK, kuri teoriškai sukietėja patikrinimas.
- grub_verifiers_open, kuris pakeičiamas taip, kad grąžintų nedelsiant, nereikalaujant parašo patikrinimų, taip neutralizuojant įprastą srautą patikrinimas GRUB'e.
Branduolio dekompresijos kabliukas ir atminties pataisymai
Branduolio dekompresijos užkabinimas laikinai atkuria originalius baitus, leidžia autentiškai funkcijai dekompresuoti atvaizdą ir tada pritaiko pataisas išplėsto branduolio atmintyje . Šis etapas yra labai svarbus norint išjungti valdiklius ir pasiruošti įkelti papildomus modulius ar dvejetainius failus.
Tiksliau sakant, stebima logika perrašo versijos eilutę į „BoB13“ , modifikuoja module_sig_check funkciją , kad ji grąžintų 0 (taigi branduolys priima nepasirašytus modulius net ir įjungus saugų įkrovimą, su CONFIG_MODULE_SIG_FORCE arba su module.sig_enforce=1) ir pakeičia pirmąjį init proceso aplinkos kintamąjį į „LD_PRELOAD=/opt/injector.so /init“.
LD_PRELOAD idėja yra priversti prioritetiniu būdu įkelti bendrai naudojamą ELF failą , kad būtų perrašyti funkcijos arba įterpta papildoma logika – tai įprasta technika vartotojų atakose. Verta paminėti „/init“ buvimą LD_PRELOAD reikšmėje; tiksli jos reikšmė nėra iki galo aiški ir sustiprina interpretaciją, kad tai ankstyvas kūrimo etapas.
Laboratorinių bandymų metu sistema parodė, kad branduolys po paleidimo su „Bootkitty“ yra užkrėstas ; be to, modifikuotos LD_PRELOAD kintamojo eilutės ir pėdsakai buvo matomi faile „dmesg“, kurį taip pat buvo galima pamatyti faile /proc/1/environ . Sistemose, kuriose įjungtas saugus paleidimas, empirinis požymis yra tas, kad branduolys vykdymo metu priima nepasirašyto modulio įkėlimą , o tai neturėtų įvykti be išankstinio pataisymo.
BCDropper ir BCObserver: susijusios pagalbinės dalys
Lygiagrečiai buvo aptiktas nepasirašytas branduolio modulis, pravarde BCDropper , kurį į „VirusTotal“ įkėlė tas pats siuntėjas kaip ir įkrovos rinkinį. Jame yra nuorodos į „BlackCat“ derinimo eilutėse ir keliuose bei failų slėpimo funkcija (pavadinimai filtruojami su prefiksais, tokiais kaip „ injector “, pagal LD_PRELOAD, nukreipiantį į /opt/injector.so).
„BCDropper“ iš /opt/observer išskleidžia įterptąjį ELF failą, vadinamą „BCObserver“ , ir vykdo jį naudodamas /bin/bash. Jis taip pat pašalina savo pėdsakus iš įkeltų modulių sąrašo ir teikia tipines rootkit funkcijas (failų, procesų, prievadų slėpimas), nors „dropper“ tiesiogiai neišnaudoja visų jų.
Savo ruožtu „BCObserver“ laukia, kol bus paleistas „gdm3“ ekrano tvarkyklė , ir tada bando įkelti /opt/rootkit_loader.ko naudodamas „finit_module“ sistemos iškvietimą , užtikrindamas, kad modulis būtų įterptas, kai sistema jau bus baigusi grafinį paleidimą.
Nėra absoliutaus tikrumo, kad šie fragmentai susieti su tuo pačiu autoriumi kaip ir „Bootkitty“, tačiau „module_sig_check“ pataisymas rodo, kad tikslas buvo leisti įkelti nepasirašytus modulius, atitinkančius BCDropper/BCObserver veikimą.
Atitinkami MITRE ATT&CK IoC ir metodai
Šie įsitraukimo ir klasifikacijų rodikliai gali padėti ieškant pradinių signalų Linux aplinkose, kuriose galėjo būti išbandytas PoC:
| SHA-1 | Vardas | Aptikimas | aprašymas |
| 35ADF3AED60440DA7B80F3C452047079E54364C1 | bootkit.efi | EFI/Agentas.A | Bootkitty UEFI įkrovos rinkinys. |
| BDDF2A7B3152942D3A829E63C03C7427F038B86D | lašintuvas.ko | Linux/Rootkit.Agent.FM | BCDropper. |
| E8AF4ED17F293665136E17612D856FA62F96702D | stebėti | Linux/Rootkit.Agent.FM | BCObserveris. |
Ryškiausias šio dalių rinkinio ir stebimo elgesio MITRE ATT&CK atvaizdavimas, naudingas pagrindiniam grėsmių modeliui :
| Taktika | ID | Vardas | aprašymas |
| Išteklių plėtra | T1587.001 | Sukurti galimybes: kenkėjiška programa | Bootkitty yra UEFI įkrovos rinkinys nauja |
| T1587.002 | Sukurti galimybes: kodo pasirašymo sertifikatai | Pavyzdys pasirašytas su sertifikatas savarankiškai pasirašytas. | |
| Vykdymas | T1106 | Native API | BCObserver naudoja finit_module įkelti LKM. |
| T1129 | Bendri moduliai | „Bootkitty“ stiprybė LD_IŠANKSTINIO ĮKAUTI inicializacijoje. | |
| Atkaklumas | T1574.006 | Užgrobimo vykdymo srautas: dinaminio susiejimo užgrobimas | Aplinkos pataisymas init su LD_PRELOAD. |
| T1542.003 | Paleidimas prieš OS: „Bootkit“ | Dislokavimas ESP. | |
| Gynybos vengimas | T1014 | Šaknų rinkinys | BCDropper kaip LMC dėl slėpimo. |
| T1562 | Sumažinti gynybą | Išjungti patvirtinimą parašų GRUB ir branduolyje. | |
| T1564 | Slėpti artefaktus | Paslėpti modulį sąraše moduliai branduolio. |
Pėdsakai „Linux“ sistemose ir jų mažinimo pasiūlymai
Pažeistose „Ubuntu“ instaliacijose buvo pastebėti teismo ekspertizės įrodymai, tokie kaip branduolio versijos eilutė pakeista į BoB13 (matoma su `uname -v`), modifikuota įkrovos juosta („dmesg`) ir `LD_PRELOAD` buvimas faile `/proc/1/environ` . Branduolys gali būti pažymėtas kaip užterštas – elgesys, kuris nepasireiškia be įkrovos rinkinio.
Greitas sprendimas, kai įkrovos rinkinys pakeičia GRUB, yra atkurti teisėtą failą iš /EFI/ubuntu/grubx64-real.efi į pradinę vietą /EFI/ubuntu/grubx64.efi, kad įkrovos rinkinys paleistų tikrąjį GRUB. Atminkite, kad tai taikoma tik konkrečiam scenarijui , kai diegimas buvo tiksliai toks, kaip aprašyta.
„BlackLotus“: paradigminis atvejis sistemoje „Windows“
„BlackLotus“ išgarsėjo dėl savo gebėjimo paleisti savo UEFI įkrovos rinkinį net ir visiškai atnaujintoje „Windows 11“ sistemoje su įjungtu saugiu įkrovimu. Jis buvo prieinamas už 5.000 USD (200 USD už atnaujinimą) nuo 2022 m. spalio mėn., su geofencingu , kuris neleidžia pasiekti sistemų Armėnijoje, Baltarusijoje, Kazachstane, Moldovoje, Rumunijoje, Rusijoje ir Ukrainoje.
Jis išnaudojo CVE-2022-21894 („Baton Drop“) pažeidžiamumą , kurį „Microsoft“ ištaisė 2022 m. sausio mėn., tačiau kuriuo vis dar buvo galima pasinaudoti vėliau, nes pažeidžiami, pasirašyti dvejetainiai failai vis dar nebuvo įtraukti į UEFI atšaukimų sąrašą (dbx). Diegimo programa įdiegia teisėtai pasirašytas pažeidžiamų įkrovos įkroviklių kopijas, kad būtų užtikrintas nuoseklumas ir būtų apeitas saugus paleidimas.
Be kitų funkcijų, jis galėjo išjungti „BitLocker“, atminties vientisumo (HVCI) ir „Microsoft Defender“; diegti branduolio tvarkyklę , kuri apsaugojo įkrovos rinkinio failus ESP; ir paleisti vartotojo režimo HTTP atsisiuntimo programą faile „winlogon.exe“ , naudodamas anti-VM, anti-debugging ir obfuscation metodus. Įkrovos rinkinio dydis buvo mažas (apie 80 KB), o tai prisidėjo prie jo slaptumo.
Buvo dokumentuoti vidiniai kodai ir įdomūs artefaktai, pavyzdžiui, nuorodos į „Higurashi“ seriją komponentų pavadinimuose ir savarankiškai pasirašytas sertifikatas, taip pat nenaudojami užmaskuoti pranešimai. Šios detalės nesumažina jo pavojingumo, tačiau suteikia konteksto apie jo vystymąsi.
Kaip „Windows“ apsaugo įkrovą: saugus įkrovos režimas, patikimas įkrovos režimas, ELAM ir išmatuotas įkrovos režimas
„Windows“ sistemoje įkrovos patikimumo grandinė remiasi keliais sluoksniais. „Secure Boot“ patikrina programinės įrangos ir įkrovos tvarkyklės parašus; „Trusted Boot“ patikrina branduolio ir įkrovos komponentų vientisumą; ELAM teikia pirmenybę kenkėjiškų programų tvarkyklės įkėlimui, palyginti su kitomis ne „Microsoft“ įkrovos tvarkyklėmis; o „Measured Boot“ įrašo maišos kodus TPM nuotoliniam patvirtinimui.
Pagal numatytuosius nustatymus sertifikuotuose įrenginiuose įjungtas saugus įkrovimas ir jie pasitiki „Microsoft“ sertifikatu bei kitais patvirtintais įkrovos įkrovikliais. Tačiau palikus įjungtą „Microsoft“ trečiosios šalies UEFI CA, atakų paviršius išplečiamas, nes pasitikima įkrovos įkrovikliais iš kelių platinimų, įskaitant tuos, kurie turi žinomų pažeidžiamumų. Daugeliui apsaugoto branduolio įrenginių reikia išjungti pasitikėjimą šiuo trečiosios šalies CA, kad būtų sustiprinta numatytoji saugumo padėtis .
Norint leisti „Linux“ veikti apsaugotose aplinkose, rekomenduojama aiškiai pridėti norimą įkrovos tvarkyklės parašą prie UEFI duomenų bazės arba, kaip paskutinę išeitį, išjungti saugų įkrovą – priemonę, kuri žymiai sumažina apsaugą nuo įkrovos rinkinių . Bet kuriuo atveju šiems pakeitimams atlikti reikia rankiniu būdu modifikuoti programinę įrangą ir jų negali automatizuoti kenkėjiška programinė įranga.
Išmatuoto įkrovos patikrinimas leidžia patikimam serveriui įvertinti, ar galinis taškas palaiko nepažeistą įkrovos grandinę. TPM pasirašo įrodymus ir kartu su papildoma telemetrija leidžia izoliuoti pažeistus įrenginius karantino tinkluose, kol bus pašalinti gedimai.
Iniciatyvaus aptikimo ir stebėjimo taisyklės
Be „Windows“ integruotos įrangos, bendruomenė paskelbė naudingas „Sigma“ taisykles , skirtas aptikti su šiais scenarijais susijusią veiklą. Tai apima programinės įrangos failo sukūrimą „System32“ aplinkoje naudojant nesisteminį procesą ir „ High-VCI“ atminties vientisumo išjungimą naudojant registro raktus (MITRE ATT&CK metodai T1562 ir T1112). Šie aptikimai susieti su keliomis SIEM/EDR/XDR sistemomis.
„Linux“ sistemoje patartina susieti įkrovos įvykius („journald“ / „dmesg“), PID 1 aplinkos kintamųjų pakeitimus naudojant „uname -vy“ ir tikrinti, ar nėra nepasirašytų modulių įkėlimų arba įtartinų ESP operacijų . Šių pėdsakų integravimas su elgesio taisyklėmis EDR padidina ankstyvo bandymo išsaugoti duomenis aptikimo tikimybę.
Platesnis vaizdas: „LoJax“, „ESPecter“, „MoonBounce“, „MosaicRegressor“ ir nauji signalai
Pirmasis pastebėtas UEFI programinės įrangos implantas buvo „LoJax“ (2018 m.), po kurio sekė kampanijos su „MosaicRegressor“ ir „MoonBounce“, pastarasis žinomas dėl to, kad pakėlė UEFI rootkit'ų sudėtingumo kartelę . 2021 m. „ESPecter“ ir „FinSpy“ įkrovos rinkinys pademonstravo, kad ikioperacinės sistemos kūrimo etapas išliko patraukliu taikiniu pažengusiems veikėjams.
„Linux“ arenoje „Bootkitty“ buvo pirmasis tokio pobūdžio funkcinis testas , nors ir ribotos apimties. Jau 2025 m. pasirodė nuorodos į „ HybridPetya “ kaip „Petya“ šeimos evoliuciją su UEFI įkrovos rinkinio galimybėmis, o pavyzdžiai į „VirusTotal“ buvo įkelti iš Lenkijos . Nors analizė vis dar preliminari, ji primena, kad ši grėsmių kategorija toliau plečiasi.
Praktiniai patarimai, kaip sumažinti riziką
„Linux“ aplinkose saugaus įkrovimo įjungimas, programinės įrangos (UEFI) ir branduolio atnaujinimų diegimas bei atšauktų programų sąrašo (dbx) atnaujinimo užtikrinimas yra nekeičiami principai. Stebėkite, ar `module.sig_enforce` yra nustatytas į 1 arba ar `CONFIG_MODULE_SIG_FORCE` yra įjungtas, kai tai tinka, ir venkite modulių įkėlimo iš nepatikimų šaltinių.
Reguliariai tikrinkite ESP skaidinį , ar nėra neleistinų kelių, tokių kaip /EFI/ubuntu/grubx64.efi, pakeitimų, ir patikrinkite, ar nėra įtartinų „kopijų“ (grubx64-real.efi). Reikėtų ištirti bet kokius GRUB patikros srauto pakeitimus.
„Windows“ sistemoje, be saugaus įkrovos, ji sustiprina patikimą įkrovą, įjungia HVCI , kai tai palaiko aparatinė įranga, ir priima TPM pagrįstą nuotolinį atestavimą su sąlyginės prieigos politika. Tai sumažina priklausomybę nuo trečiųjų šalių CA, jei tai nėra būtina, ir pagreitina atšaukimų taikymą, kai jie praneša apie gedimus įkrovos komponentuose.
Kai kuriuose komerciniuose sprendimuose integruoti UEFI skaitytuvai, galintys nuskaityti programinę-aparatinę įrangą ir ieškoti kenkėjiškų komponentų . ESET teigia esanti vienintelė iš 20 geriausių galinių įrenginių tiekėjų pagal pajamas, siūlanti šią integruotą funkciją savo klientams – metodą, kuris gali padidinti vertę nuodugniai aparatinės įrangos apsaugai .
Pastarųjų kampanijų trajektorija aiškiai rodo, kad įkrovos nuoroda išlieka pagrindiniu taikiniu. Tinkamai naudojant telemetriją , programinės įrangos / įkrovos įkrovos programos apsaugos priemones ir sistemingus vientisumo patikrinimus, galima gerokai pakelti kartelę ir gerokai apsunkinti priešininkų darbą.
UEFI įkrovos rinkinių pažangiausia versija patvirtina, kad riba tarp koncepcijos įrodymo (PoC) ir realaus veikimo peržengiama vis greičiau: „Bootkitty“ rodo, kad „Linux“ jau yra taikiklyje, „BlackLotus“ įtvirtino gyvybingumą „Windows“ sistemoje, o gynybos ekosistema turi teikti pirmenybę įkrovos higienai, duomenų bazių atnaujinimams, IoC stebėjimui ir nuotoliniam atestavimui, kad būtų galima sustabdyti bet kokius bandymus išsaugoti duomenis prieš OS diegimą.