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.
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 proc tak slozite, kdyz v tom pripade muzete nahradit kernel nebo initrd :D (hlavne kdyz to pouziva specificke offsety a je to tedy urceny na malou podmnozinu cilovych instalaci).
Z poslednich par zkusenosti, kdy se me grub2 podelal, protoze EFI binarka byla stara, ale later-stage moduly uz nove a upgradovane a neslo to slinkovat, uz razim pristup ze pri instalaci noveho kernelu rovnou instaluji i ten grub nanovo. Takze neobstoji moc ani argumentace ze se grub prece tak casto neupdatuje jako kernel.
Je to tedy spis cista kuriozita (a mozna prezentace, ze zlomyslny bootloader bude moct mit porad moznost/vliv na jinak samostatny next-stage kernel)
"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
To jiste, v 1 promily ... me se treba (na nekterym HW) zepta, estli chci pokracovat, na jinym se nepta vubec a pokracuje, nekde kdyz mu predhodim podepsanej bootloader, tak si ho proste prida mezi ty spravny ...
Pokracovat pak muzem treba tim, ze kdyz uz neco spustis, co ti tam nakopiruje loader, tak to neco taky muze prepsat bios, a to i v pripade, ze ho mas zaheslovany
A naopak, jsou stim jen problemy ... minuly mesic sem kupoval nejaky nb od hp ... a narozdil od vsech predchozich tam se zapnutym timhle kramem nejde dat veracrypt ...
Coz je jeste vpohode, mnohem vic k popukani bylo, kdyz soudruzi v MS vydali nejaky ty "aktualizace", a vsechncy stroje ve vmware se zapnutym securebootem nenastarovaly. Pak se soudruzi navzajem obvinovali kdo za to muze ...
Edit: Navic to do celyho tartu systemu vnasi hromadu jak reseto deraveho kodu, ktery neni jak aktualizovat. Ukaz mi dodavatele HW ktery ti vyda aktualizaci biosu po vic nez 1/2 roce ...
30. 11. 2024, 11: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.
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.