I 806 modeller av moderkort har en testnyckel upptäckts som gör det möjligt att kringgå UEFI Secure Boot.

Säkerhetsexperter från företaget Binarly har upptäckt en möjlighet att kringgå den verifierade UEFI Secure Boot-läget på mer än 800 produkter som släppts av Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo och Supermicro. Problemet har kodnamnet PKfail och är kopplat till användningen av en osäker plattformsnyckel (PK, Platform Key) i firmware, som genererats av AMI (American Megatrends International) och levererats som ett testexempel. De äldsta firmwareversionerna som använde testnyckeln släpptes 2012, medan de nyaste är daterade i juni 2024. Enligt forskarna är mer än 10% av alla verifierade firmwareversioner sårbara för detta problem.

I nyckelinställningarna angavs att den var osäker och inte skulle levereras i sina produkter. Det antyddes att denna testnyckel skulle ersättas med en egen, men tillverkarna bortsåg från varningen och använde istället en typisk gemensam nyckel som skickades till alla partners och kunder hos AMI.

Den slutna delen av AMI:s testnyckel, som krävs för att skapa digitala signaturer, blev offentligt tillgänglig efter en informationsläcka från en av hårdvarutillverkarna, vars anställd av misstag lade upp koden som innehöll denna nyckel i ett offentligt GitHub-repo. Den slutna nyckeln var placerad i en krypterad fil, vars kryptering använde ett enkelt 4-teckens lösenord, vilket var lätt att knäcka genom en enkel provning.

Plattformsnyckeln används som en grund för tillit för att verifiera databaser med nycklar för Secure Boot. Att få tillgång till den slutna delen av plattformsnyckeln komprometterar hela tillitskedjan som är involverad i valideringen av komponenter i det inlästa systemet — genom att känna till plattformsnyckeln kan man kringgå skyddet av Secure Boot och organisera inläsning av egna komponenter genom att manipulera KEK (Key Exchange Key) och databaserna 'db' (Signature Database) och 'dbx' (Forbidden Signature Database). KEK ansvarar för att skapa en tillitskedja mellan firmware och operativsystem, 'db' innehåller certifikat och signaturer för bootloaders och tredjeparts UEFI-komponenter, medan 'dbx' inkluderar återkallade signaturer från kända skadliga komponenter.

För att genomföra en attack räcker det med att generera nya nycklar och certifikat för KEK och db, och sedan använda den testnyckel för plattformen som har blivit offentlig för att ladda in det skapade KEK-certifikatet i UEFI-firmware. När KEK-certifikatet har laddats in i firmware kan den relaterade privata nyckeln användas för att ladda in det nya certifikatet i databasen db. Efter att certifikatet db har laddats, kan den relaterade privata nyckeln användas för att signera de laddade EFI-komponenterna. 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

För att kontrollera korrektheten av plattformens nyckel räcker det att köra verktyget "efi-readvar -v PK" från paketet efitools och kontrollera att plattformens nyckel inte är en testnyckel: efi-readvar -v PK Variabel PK, längd 862 PK: Lista 0, typ X509 Signatur 0, storlek 834, ägare 26dc4851-195f-4ae1-9a19-fbf883bbb35e Ämne: CN=DO NOT TRUST — AMI Test PK Utfärdare: CN=DO NOT TRUST — AMI Test PK

Källa: opennet.ru