Security researchers warn that some PC and server manufacturers are using insecure cryptographic keys as the root of trust for Secure Boot, an important security feature in modern computers that prevents malware from injecting itself early into the boot process.
One of those keys has been leaked accidentally, potentially breaking Secure Boot guarantees for hundreds of computer models from seven manufacturers. However, almost 900 models produced over the past 12 years are using keys that were likely generated for testing purposes and should have never been used in production, according to a report from security firm Binarly, which dubbed this issue PKfail.
“Earlier this year, we noticed that the private key from American Megatrends International (AMI) related to the Secure Boot ‘master key,’ called Platform Key (PK), was publicly exposed in a data leak,” the researchers wrote. “The incident occurred at an ODM [original design manufacturer] responsible for firmware development for multiple device vendors, including US-based enterprise device manufacturers. The devices corresponding to this key are still deployed in the field, and the key is also being used in recently released enterprise devices.”
Why is the Platform Key?
Secure Boot is a feature of the Unified Extensible Firmware Interface (UEFI) specification — the modern BIOS — that performs cryptographic signature verification for all the components loaded during the boot process, from the early stages initiated by UEFI, until the booting process is taken over by the OS bootloader to start the OS kernel.
Ensuring the integrity of the startup process is vital because malicious code executing at such early stages gain complete control over the operating system, disabling or bypassing its security features. Before Secure Boot received wide adoption, there were many malware threats that injected code into the bootloader of compromised computers or into BIOS/UEFI itself. These bootkits — boot-level rootkits — give attackers high-level persistence on compromised systems and the ability to hide files and processes from any endpoint security products running on them.
Secure Boot uses public-key cryptography, with public keys stored inside UEFI used to validate components signed with corresponding private keys. At the core is a public key known as Platform Key. This key is supposed to be generated by the computer manufacturer and, according to Binarly researchers, should be rotated periodically and ideally not be reused across product lines to limit the impact of a compromise. Moreover, the private key component should be stored securely in hardware security modules (HSMs) from where it cannot easily be stolen or leaked.
In no case should the root private key for such an important security feature make its way into a public repository on GitHub like the AMI Platform Key found by Binarly did. That’s not the only issue. AMI is one of three independent BIOS vendors (IBVs) that produce reference UEFI implementations for PC manufactures and OEMs, which then customize those implementations for their products.
Binarly argues that generating new Platform Keys should be part of that customization process, as it is the PC manufacturers who should be responsible for their “platforms,” not a third party. The public key certificate for the leaked private key has a Common Name field that reads “DO NOT TRUST – AMI Test PK”. Yet it was used in hundreds of models from seven separate vendors.
“This key was likely included in their reference implementation with the expectation that it would be replaced with another safely-generated key by downstream entities in the supply chain,” the researchers wrote. “The test keys are shared with commercial partners and vendors with the expectation they be treated as completely untrusted.”
Moreover, the leaked AMI key has been used across many product ranges, from gaming laptops to server motherboards, significantly increasing the impact of the leak across industries and user types.
How can attackers abuse the leaked key?
Secure Boot has four key stores and databases in UEFI. At the core is the Platform Key, which is used to validate all firmware components and another key known as the Key Exchange Key (KEK). KEK can be used to update a database called db that contains signatures for bootloaders and other third-party EFI components that are allowed to be executed, for example the Windows bootloader or Linux bootloader. It can also be used to update dbx, a database that contains a blacklist of signatures, for example for vulnerable bootloaders.
An attacker with privileged access to the OS on a computer that uses the leaked PK can use it to generate a new KEK, then sign and insert it into the KEK store by using command-line utilities such as efi-updatevar. They can then use their new KEK to modify the db signature database to add the signature for a malicious .efi module they created and placed in the EFI partition on disk. This module will then be executed on boot, giving it control over the Windows startup and kernel.
Attackers are already exploiting known Secure Boot vulnerabilities to deploy bootkits. Last year, researchers from ESET warned about a new UEFI bootkit called BlackLotus that exploits a Windows vulnerability known as Baton Drop (CVE-2022-21894) to bypass Secure Boot via vulnerable bootloader components. It therefore wouldn’t be surprising if attackers would start abusing a leaked Platform Key. Two years ago, researchers from Eclypsium discovered vulnerabilities that could be used to bypass Secure Boot, while Binarly presented 12 more flaws that could lead to pre-boot remote code execution in UEFI implementations.
The possibility that the AMI test PK has fallen into the wrong hands can’t be ruled out. According to Binarly researchers, the repository containing the key was removed after four months but it took five months to delete all forks. The private key was not stored in plaintext and was encrypted, but protected only by a 4-character password that could be cracked in seconds with basic password-guessing tools.
Use of test AMI Platform Keys in firmware binaries is common
After finding the leaked key, Binarly researchers discovered reports dating back to 2016 that some Platform Keys contain words like “DO NOT TRUST” and “test key.” There was even a vulnerability ID (CVE-2016-5247) generated at the time for multiple Lenovo models using AMI test keys.
But the leaked key was found in firmware released as early as 2018 and as recently as this year. To find out how common the practice still is, Binarly’s researchers scanned their database of tens of thousands of firmware binaries collected over the years and identified 22 different AMI test PKs with warnings “DO NOT TRUST” or “DO NOT SHIP.” Those keys were found in UEFI firmware binaries for almost 900 different computer and server motherboards from over 10 vendors, including Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo, and Supermicro. Combined, they accounted for more than 10% of the firmware images in the dataset.
Those keys cannot be trusted, as they were likely shared with many vendors, OEMs, ODMs, and developers — and were likely stored insecurely. Any of them may already have been leaked or stolen in undiscovered incidents. Last year, a data dump published by an extortion gang from motherboard and computer manufacturer Micro-Star International (MSI) included an Intel OEM private key and a year before a data leak from Lenovo included firmware source code and Intel Boot Guard signing keys.
Binarly has released an online scanner where users can submit copies of their motherboard firmware to check whether it uses a test key, and a list of affected motherboard models is included in the company’s advisory. Unfortunately, there’s not much users can do until vendors provide firmware updates with new, securely generated PKs, assuming their motherboard models are still under support. The earliest use of such test keys found by Binarly goes back to 2012.