Názory k článku
Bootkitty je první UEFI bootkit určený pro Linux

A jak se mi ten bootkit do počítače dostane? Resp. musím spustit nějakou binárku jako root, nebo jak?

Podle odkazovaneho clanku je malicious soubor upraveny "grubx64.efi". A ten se nachazi na ESP, coz je FAT32 partisna - takze se tam nehraje na uzivatelske prava.

Kdyz vidim ze flowchart pouziva windows bootloader, tak je mozne ze se ten utok odehraje z dualbootu - z win na ESP lehce zapise jakakoliv aplikace, v pripade linuxu by musel byt /efi mountnut s user priznakem a pak roota nepotrebujete.

To by mě zajímalo, kterej tydýt by si to takhle namountoval :-)

Problem je, ze to ESP je proste slaby prvek (volne pristupny), a hraje se na chain-of-trust jednotlivych dilcich elementu.

Zde bych tedy nehledal problem v tom, co dela onen payload - ale jak je sakra mozne, ze chain of trust toho secure-bootu nefunguje. To je to hlavni, co by se melo resit, a ne to, ze pak vam to rozbije OS.

Anebo jinak: pokud vam MS (omylem/podvodem) digitalne podepise vir - jedna se porad o problem, nebo je to najednou featura?

Nevím v čem je ESP slabší než ext4, pokud se bavíme o offline útoku. Rozdíl může být v tom, že ext4 může být na luksu. Pokud bude Secure boot vyplý, tak se dá zaútočit na nezašifrovaný ext4 (nebo jiný fs) úplně stejně jako na ESP. Eventuálně přímo na grub, pokud už grub řeší heslo při bootování... Ale jako jo, ESP nemůže být šifrovaná. Ale to je tak všechno. Prostě ta představa tohoto útoku je dost hypotetická. Naštěstí.

Ale chain of trust funguje. Veď aj článok hovorí, že opatrenie na nápravu je zapnúť Secure Boot.

Nahradiť efi binárku na ESP sa dá vtedy, keď sa nekontroluje ich podpis, teda Secure Boot je vypnutý.

"ze chain of trust toho secure-bootu nefunguje."

Protoze to od sameho pocatku nikdy nefungovalo a ani fungovat nemuze. A to principielne. Je to presne totez, jak kdyz se snazis sifrovat data, ale zaroven chces, aby meli pristup vsichni. To je proste oxymoron, stejne jako cela idea "secure"bootu.

Musel bys zacit treba tim, ze do toho HW nekde na zacatku natvrdo nesmazatelne napalis nejaky klic. A tim bys taky skoncil, protoze ten HW by byl nepouzitelny.

Edit: Alternativne bys dopad presne stejne jako dvd/brd/... a jine pokusy na to tema.

28. 11. 2024, 16:58 editováno autorem komentáře

Z Windows tam také tak lehce nezapíšeš. EFI partišna není standardně připojená. Na připojení i přístup do ní potřebuješ zvýšená oprávnění. Totéž pokud by měl malware zapisovat do blok. zařízení napřímo (např. by byl linkovaný s nějakou malou knihovnu pro práci s FAT32).
Takže pokud si uživatel explicitně nevypne UAC a zároveň není ve skupině Administrators, tak by se ho to mělo minimálně vcelku výrazně zeptat. Nenasype se mu to tam někde na pozadí, pokud to nebude sideloadované třeba v nějakém instalátoru, který by pak potvrdil, aniž by o tom věděl. Ale v tomhle případě už pak malware ze systémem může stejně udělat téměř úplně cokoliv.

Jinak to podle mě nemá úplně jednoduché řešení, pokud by ta partišna byla nějakým mechanismem pro OS úplně zamčená, tak by se velice obtížně realizovaly aktualizace a jakékoliv (i chtěné) změny.

Tak z principu - zapsat muze, ale existuje secure boot a ten by mel zabranit spusteni toho skodliveho kodu. Podepsany skodlivy kod prece neni zranitelnost, ale normalni fungovani.

Dokazal jsi zjistit jakym zpusobem tedy ten utok dosahne sveho spusteni, kdyz se hraje spravne na secure boot ?

Já jsem reagoval jen na to, jak jsi zmiňoval, že se ve Windows lehce zapíše do EFI, jen že mi to nepřijde nijak zásadně odlišné od jiných systémů, když nějakému programu dáš plná práva.

Jestli jsem pochopil správně ten článek z ESETu, tak tenhle konkrétní útok (resp. spíš PoC) se při zapnutém SB spustit nedovede, protože není podepsaný MS nebo jinou autoritou, jejichž klíče by byly distribuovány v normálních PC.
Takže, kdyžtak mě oprav, ale podle mě to nijak fundamentálně nerozbíjí SB.
Ty předchozí věci, které byly reálně zneužitelné - jako BlackLotus, používaly jiné zranitelnosti ve Windows a nějaké nerevokované klíče.
Případně, jestli si to dobře pamatuju, byly ještě na určitém hardware platform klíče pro vývoj z AMI, co tam vendoři zapomněli.
Takže aby byl se případně z toho udělal funkční exploit, muselo by se nejspíš zneužít víc věcí dohromady.

Ano propto mam zakazany UEFI boot, nebot ten bordel fakt ne, nemam UEFI part. a v UEFI rikam bootuj istarou metodou - a do MBR se uz jen tak nejaky virus nevejde a hlavne nic pozdeji neupravi v linuxu ;-)

MBR ti tezko nataha kernel :D k utoku se zde pouzil modifikovanej grub a ten tam porad zrejme mas.

a ten bordel je to ze UEFI+SecureBoot ZNEMOZNI start upraveneho/za­kerneho zavedece? :-D

1. Grub nemas jen v MBR, ale i mezi MBR a prvnim oddilem
2. Pokud nemas sifrovanej /boot tak upravene Grub moduly muze nahrat do /boot/grub "kdokoliv"
3. Pouze pokud mas sifrovanej /boot a odemykas to Grubem (jeho casti za MBR), tak by byla potreba implementovat keyloger primo do toho (zda by pak odchycene heslo slo protlacit do nejake userspace pro odeslani netusim)