{"id":118325,"date":"2024-07-26T15:43:00","date_gmt":"2024-07-26T13:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/v-806-modelyah-materinskih-plat-vyyavlen-testovyj-klyuch-pozvolyayushhij-obojti-uefi-secure-boot"},"modified":"2024-07-26T15:43:00","modified_gmt":"2024-07-26T13:43:00","slug":"v-806-modelyah-materinskih-plat-vyyavlen-testovyj-klyuch-pozvolyayushhij-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/news\/v-806-modelyah-materinskih-plat-vyyavlen-testovyj-klyuch-pozvolyayushhij-obojti-uefi-secure-boot","title":{"rendered":"In 806 modellen van moederborden is een testsleutel ontdekt die het mogelijk maakt om UEFI Secure Boot te omzeilen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Beveiligingsonderzoekers van het bedrijf Binarly hebben een mogelijkheid ontdekt om de verificatiebootmodus van UEFI Secure Boot te omzeilen op meer dan 800 producten die zijn uitgebracht door bedrijven zoals Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo en Supermicro. Het probleem heeft de codenaam PKfail ontvangen en is gerelateerd aan het gebruik van een onbetrouwbare platformsleutel (PK, Platform Key) in de firmware, die is gegenereerd door AMI (American Megatrends International) en als een proefvoorbeeld is geleverd. De oudste firmwares die de testsleutel gebruikten, zijn uitgebracht in 2012, terwijl de nieuwste dateren van juni 2024. Volgens de onderzoekers is meer dan 10% van alle gecontroleerde firmwares kwetsbaar voor dit probleem. <\/p>\n
In de parameters van de sleutel stond aangegeven dat deze onbetrouwbaar was en niet in hun producten moest worden geleverd. Het was de bedoeling dat deze testsleutel werd vervangen door een eigen sleutel, maar fabrikanten negeerden de waarschuwing en gebruikten in de uiteindelijke firmwares een standaard algemene sleutel die naar alle partners en klanten van AMI werd verzonden. <\/p>\n
Het geheime deel van de testsleutel van AMI, nodig voor het maken van digitale handtekeningen, werd openbaar toegankelijk na een gegevenslek bij een van de hardwarefabrikanten, wiens werknemer per ongeluk de code, die deze sleutel bevatte, in een openbaar repository op GitHub plaatste. De geheime sleutel was in een versleuteld bestand geplaatst, waarbij een eenvoudige 4-cijferige wachtwoord werd gebruikt, dat gemakkelijk te raden was door brute force. <\/p>\n
De sleutel van het platform wordt gebruikt als de root of trust voor het ondertekenen van databases met sleutels voor Secure Boot. Het verkrijgen van het private gedeelte van de platformsleutel leidt tot compromittering van de gehele keten van vertrouwen die betrokken is bij de validatie van de componenten van het opstartende systeem \u2014 door de platformsleutel te kennen kan de beveiliging van Secure Boot worden omzeild en kan men eigen componenten in de opstartfase manipuleren via de KEK-sleutel (Key Exchange Key) en de databases 'db' (Signature Database) en 'dbx' (Forbidden Signature Database). KEK is verantwoordelijk voor het cre\u00ebren van de keten van vertrouwen tussen de firmware en het besturingssysteem, 'db' bevat certificaten en handtekeningen voor de bootloader en externe UEFI-componenten, terwijl 'dbx' ingetrokken handtekeningen van bekende schadelijke componenten omvat. <\/p>\n
Om een aanval uit te voeren, is het voldoende om nieuwe sleutels en certificaten voor KEK en db te genereren en vervolgens de openbaar beschikbare test-sleutel van het platform te gebruiken om de gemaakte KEK-certificaat in de UEFI-firmware te laden. Nadat de KEK-certificaat in de firmware is geladen, kan de bijbehorende priv\u00e9sleutel worden gebruikt om een nieuw certificaat in de db te laden. Na het laden van het db-certificaat kan de bijbehorende priv\u00e9sleutel worden gebruikt voor het ondertekenen van de opstartende EFI-componenten. 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 <\/p>\n
Om de correctheid van de platformsleutel te controleren, hoeft u alleen de utility 'efi-readvar -v PK' uit het efitools-pakket te starten en te verifi\u00ebren dat de platformsleutel geen testsleutel is: efi-readvar -v PK Variable PK, length 862 PK: Lijst 0, type X509 Handtekening 0, grootte 834, eigenaar 26dc4851-195f-4ae1-9a19-fbf883bbb35e Onderwerp: CN=DO NOT TRUST \u2014 AMI Test PK Uitgever: CN=DO NOT TRUST \u2014 AMI Test PK
![\"Video](\"https:\/\/img.youtube.com\/vi\/CveWt3gFQTE\/hqdefault.jpg\")
\r\n