Bezpečnostní výzkumníci z firmy Binarly odhalili možnost obejití režimu ověřeného zavádění UEFI Secure Boot na více než 800 produktech vydaných společnostmi Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo a Supermicro. Problém dostal kódové jméno PKfail a je spojen s používáním nedůvěryhodného klíče platformy (PK, Platform Key), vygenerovaného společností AMI (American Megatrends International) a dodávaného jako testovací vzorek. Nejsou starší firmware, ve kterých byl použit testovací klíč, vydány v roce 2012, zatímco nejnovější pocházejí z června 2024. Podle výzkumníků je více než 10 % všech ověřených firmware zasaženo tímto problémem.
V parametrech klíče bylo uvedeno, že není důvěryhodný a neměl by být dodáván v produktech. Předpokládalo se, že tento testovací klíč by měl být nahrazen vlastním, ale výrobci si varování nevšimli a použili v konečných firmware typický sdílený klíč, zaslaný všem partnerům a zákazníkům společnosti AMI.
Uzavřená část testovacího klíče AMI, nezbytná pro vytváření digitálních podpisů, se stala veřejně dostupnou po úniku informací od jednoho z výrobců hardwaru, jehož zaměstnanec omylem zveřejnil v veřejném repozitáři na GitHubu kód, který tento klíč obsahoval. Uzavřený klíč byl umístěn v zašifrovaném souboru, přičemž při šifrování byl použit jednoduchý 4-znakový heslo, které bylo snadno uhodnutelné metodou hrubé síly.
Klíč platformy se používá jako kořen důvěry pro zabezpečení databáze klíčů pro Secure Boot. Získání uzavřené části klíče platformy vede ke kompromitaci celého řetězce důvěry, který se podílí na ověřování platnosti komponentů zaváděného systému — s znalostí klíče platformy lze obejít ochranu Secure Boot a provést podvody při zavádění vlastních komponent pomocí manipulace s klíčem KEK (Key Exchange Key) a databázemi „db“ (Signature Database) a „dbx“ (Forbidden Signature Database). KEK zajišťuje vytvoření řetězce důvěry mezi firmwarem a operačním systémem, „db“ obsahuje certifikáty a podpisy pro zaváděč a externí komponenty UEFI, zatímco „dbx“ zahrnuje odvolané podpisy známých škodlivých komponent.
K provedení útoku stačí vygenerovat nové klíče a certifikáty pro KEK a db, poté využít na veřejnost propuštěný testovací klíč platformy pro načtení vytvořeného KEK certifikátu do UEFI firmware. Po načtení KEK certifikátu do firmware lze použít s ním spojený soukromý klíč k načtení nového certifikátu do databáze db. Po načtení certifikátu db může být s ním spojený soukromý klíč použit k podepisování načítaných EFI komponentů. openssl req -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj "\/CN=BRLY KEK\/" -out KEK.crt openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days 3650 -subj "\/CN=BRLY db\/" -out db.crt efi-updatevar -a -c KEK.crt -k PK.key KEK efi-updatevar -a -c db.crt -k KEK.key db sbsign —key db.key —cert db.crt —output rogue.efi.signed rogue.efi
Pro ověření správnosti klíče platformy stačí spustit nástroj "efi-readvar -v PK" z balíčku efitools a ujistit se, že klíč platformy není testovací: efi-readvar -v PK Proměnná PK, délka 862 PK: Seznam 0, typ X509 Podpis 0, velikost 834, vlastník 26dc4851-195f-4ae1-9a19-fbf883bbb35e Předmět: CN=NE DŮVĚŘUJTE — AMI Test PK Vydavatel: CN=NE DŮVĚŘUJTE — AMI Test PK
Zdroj: opennet.ru
