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.
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.
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.
De platformsleutel wordt gebruikt als de root of trust voor het ondertekenen van databases met sleutels voor Secure Boot. Het verkrijgen van het geheime deel van de platformsleutel leidt tot compromittering van de gehele keten van vertrouwen die betrokken is bij het verifiëren van de geldigheid van de onderdelen van het opstartende systeem — met de platformsleutel kan de beveiliging van Secure Boot worden omzeild en kunnen eigen componenten worden ingeladen door manipulatie van de KEK (Key Exchange Key) en de databases ‘db’ (Signature Database) en ‘dbx’ (Forbidden Signature Database). KEK is verantwoordelijk voor het creëren van de keten van vertrouwen tussen de firmware en het besturingssysteem, 'db' bevat certificaten en handtekeningen voor de opstarter en externe UEFI-componenten, terwijl 'dbx' ingetrokken handtekeningen van bekende kwaadaardige componenten omvat.
Voor een aanval is het voldoende om nieuwe sleutels en certificaten voor KEK en db te genereren, en vervolgens de openbare testsleutel van het platform te gebruiken om het gemaakte KEK-certificaat in de UEFI-firmware te laden. Na het laden van het KEK-certificaat in de firmware kan de bijbehorende privésleutel worden gebruikt om in de database db een nieuw certificaat te laden. Na het laden van het db-certificaat kan de bijbehorende privésleutel worden gebruikt voor het ondertekenen van de geladen 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
Om de correctheid van de platformsleutel te controleren, volstaat het om de utility "efi-readvar -v PK" uit het pakket efitools uit te voeren en te controleren of de platformsleutel geen testversie is: efi-readvar -v PK Variabele PK, lengte 862 PK: Lijst 0, type X509 Handtekening 0, grootte 834, eigenaar 26dc4851-195f-4ae1-9a19-fbf883bbb35e Onderwerp: CN=DO NOT TRUST — AMI Test PK Uitgever: CN=DO NOT TRUST — AMI Test PK
Bron: opennet.ru
