Sikkerhedsforskere fra Binarly har afsløret en mulighed for at omgå UEFI Secure Boot's verificerede opstart på mere end 800 produkter fra Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo og Supermicro. Problemet har kodenavnet PKfail og er relateret til brugen af en usikker platformnøgle (PK, Platform Key), der blev genereret af AMI (American Megatrends International) og leveret som et testeksempel. De ældste firmwares, der anvendte testnøglen, blev udgivet i 2012, mens de nyeste er dateret juni 2024. Ifølge forskerne er over 10% af alle verificerede firmwares sårbare over for problemet.
I nøgleparametrene blev det angivet, at den ikke var pålidelig, og at den ikke skulle leveres i deres produkter. Det var meningen, at denne testnøgle skulle erstattes med en egen, men producenterne ignorerede advarslen og brugte i de endelige firmwares en generisk fællesnøgle, der blev sendt til alle AMIs partnere og kunder.
Den lukkede del af AMIs testnøgle, der var nødvendig for at skabe digitale underskrifter, blev offentligt tilgængelig efter en lækage fra en hardwareproducent, hvis medarbejder fejlagtigt uploadede kode, der indeholdt denne nøgle, til et offentligt repository på GitHub. Den lukkede nøgle blev gemt i en krypteret fil, hvor en simpel 4-tegns adgangskode blev brugt til krypteringen, og denne nøgle var let at gætte ved brute force.
Platformnøglen bruges som roden til tillid til at attestere databaser med nøgler til Secure Boot. Adgang til den lukkede del af platformnøglen kompromitterer hele tillidskæden, der er involveret i valideringen af komponenter i det indlæste system. Ved at kende platformnøglen kan man omgå Secure Boot-beskyttelsen og indsætte egne komponenter ved at manipulere KEK (Key Exchange Key) og databaserne "db" (Signature Database) og "dbx" (Forbidden Signature Database). KEK er ansvarlig for at skabe tillidskæden mellem firmwaren og operativsystemet, "db" indeholder certifikater og digitale underskrifter til bootloadere og tredjeparts UEFI-komponenter, mens "dbx" inkluderer tilbagekaldte underskrifter for kendte skadelige komponenter.
For an attack, it is enough to generate new keys and certificates for KEK and db, after which the test key of the platform, which has become publicly available, can be used to load the created KEK certificate into the UEFI firmware. Once the KEK certificate is loaded into the firmware, the associated private key can be used to load the new db certificate into the db. After the db certificate is loaded, its associated private key can be used to sign the loaded EFI components. 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
To check the validity of the platform key, simply run the utility "efi-readvar -v PK" from the efitools package and ensure that the platform key is not a test key: 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
Kilde: opennet.ru
