Secure Boot is completely broken on 200+ models from 5 big device makers

In 2012, an industry-wide coalition of hardware and software makers adopted Secure Boot to protect against a long-looming security threat. The threat was the specter of malware that could infect the BIOS, the firmware that loaded the operating system each time a computer booted up. From there, it could remain immune to detection and removal and could load even before the OS and security apps did.

The threat of such BIOS-dwelling malware was largely theoretical and fueled in large part by the creation of ICLord Bioskit by a Chinese researcher in 2007. ICLord was a rootkit, a class of malware that gains and maintains stealthy root access by subverting key protections built into the operating system. The proof of concept demonstrated that such BIOS rootkits weren't only feasible; they were also powerful. In 2011, the threat became a reality with the discovery of Mebromi, the first-known BIOS rootkit to be used in the wild.

Keenly aware of Mebromi and its potential for a devastating new class of attack, the Secure Boot architects hashed out a complex new way to shore up security in the pre-boot environment. Built into UEFI—the Unified Extensible Firmware Interface that would become the successor to BIOS—Secure Boot used public-key cryptography to block the loading of any code that wasn’t signed with a pre-approved digital signature. To this day, key players in security—among them Microsoft and the US National Security Agency—regard Secure Boot as an important, if not essential, foundation of trust in securing devices in some of the most critical environments, including in industrial control and enterprise networks.

An unlimited Secure Boot bypass

On Thursday, researchers from security firm Binarly revealed that Secure Boot is completely compromised on more than 200 device models sold by Acer, Dell, Gigabyte, Intel, and Supermicro. The cause: a cryptographic key underpinning Secure Boot on those models that was compromised in 2022. In a public GitHub repository committed in December of that year, someone working for multiple US-based device manufacturers published what’s known as a platform key, the cryptographic key that forms the root-of-trust anchor between the hardware device and the firmware that runs on it. The repository was located at https://github.com/raywu-aaeon/Ryzen2000_4000.git, and it's not clear when it was taken down.

The repository included the private portion of the platform key in encrypted form. The encrypted file, however, was protected by a four-character password, a decision that made it trivial for Binarly, and anyone else with even a passing curiosity, to crack the passcode and retrieve the corresponding plain text. The disclosure of the key went largely unnoticed until January 2023, when Binarly researchers found it while investigating a supply-chain incident. Now that the leak has come to light, security experts say it effectively torpedoes the security assurances offered by Secure Boot.

“It’s a big problem,” said Martin Smolár, a malware analyst specializing in rootkits who reviewed the Binarly research and spoke to me about it. “It’s basically an unlimited Secure Boot bypass for these devices that use this platform key. So until device manufacturers or OEMs provide firmware updates, anyone can basically… execute any malware or untrusted code during system boot. Of course, privileged access is required, but that’s not a problem in many cases.”

Binarly researchers said their scans of firmware images uncovered 215 devices that use the compromised key, which can be identified by the certificate serial number 55:fb:ef:87:81:23:00:84:47:17:0b:b3:cd:87:3a:f4. A table appearing at the end of this article lists each one.

The researchers soon discovered that the compromise of the key was just the beginning of a much bigger supply-chain breakdown that raises serious doubts about the integrity of Secure Boot on more than 300 additional device models from virtually all major device manufacturers. As is the case with the platform key compromised in the 2022 GitHub leak, an additional 21 platform keys contain the strings “DO NOT SHIP” or “DO NOT TRUST.”

Test certificate provided by AMI.

Credit: Binarly

Not ready for prime time

These keys were created by AMI, one of the three main providers of software developer kits that device makers use to customize their UEFI firmware so it will run on their specific hardware configurations. As the strings suggest, the keys were never intended to be used in production systems. Instead, AMI provided them to customers or prospective customers for testing. For reasons that aren't clear, the test keys made their way into devices from a nearly inexhaustive roster of makers. In addition to the five makers mentioned earlier, they include Aopen, Foremelife, Fujitsu, HP, Lenovo, and Supermicro.

Cryptographic key management best practices call for credentials such as production platform keys to be unique for every product line or, at a minimum, to be unique to a given device manufacturer. Best practices also dictate that keys should be rotated periodically. The test keys discovered by Binarly, by contrast, were shared for more than a decade among more than a dozen independent device makers. The result is that the keys can no longer be trusted because the private portion of them is an open industry secret.

In an interview, Binarly founder and CEO Alex Matrosov wrote:

“Imagine all the people in an apartment building have the same front door lock and key. If anyone loses the key, it could be a problem for the entire building. But what if things are even worse and other buildings have the same lock and the keys?”

Matrosov said his team found identical test platform keys on both client and server-related products. Team members also determined that at least one test key was used in devices sold by three distinct manufacturers.

“If the key will be leaked, it’s impacting the ecosystem,” he explained. “It’s not impacting a single device.”

Binarly has named its discovery PKfail in recognition of the massive supply-chain snafu resulting from the industry-wide failure to properly manage platform keys. The report is available here. Proof-of-concept videos are here and here. Binarly has provided a scanning tool here.

Secure Boot in a nutshell

The four key resources to make Secure Boot work are:

1. The Platform Key, or PK: This provides the root-of-trust anchor in the form of a cryptographic key embedded into the system firmware. It establishes the trust between the platform hardware and all firmware that runs on it.
2. The Key Exchange Key, or KEK: This is the key that establishes trust between the operating system and the platform firmware.
3. The Signature Database, or DB: A database containing trusted signatures and certificates for third-party UEFI components and boot loaders approved by the hardware manufacturer.
4. The Forbidden Signature Database or DBX: A database of signatures and certificates used for revoking previously trusted boot components so they can no longer run during bootup.

Updates to both the DB and DBX must be signed by a KEK in the Secure Boot KEK database.

The following three images—provided by Binarly, Microsoft, and the NSA respectively—give a visual overview of these four main resources.

Binarly

Binarly

Microsoft

Microsoft

NSA

NSA

Microsoft

NSA

Owning Secure Boot

The threat posed by PKfail is that anyone with (1) knowledge of the private portion of an affected platform key and (2) administrative system rights to an affected device can completely bypass Secure Boot protections. The threat is most immediate for devices that use the platform key compromised in the 2022 leak on GitHub.

As ESET’s Smolár explained:

The problem with the leaked private portion of this platform key is that anyone who owns this private key owns Secure Boot on that specific device. He cannot only modify these revocations to remove revoked binaries but can also create his own key exchange key and then also add his own certificates into the DB database. The DB database specifies everything that can be executed during the boot. So they can make any binary compatible with UEFI Secure Boot on these machines where the attacker controls this platform key.

Last year, Smolár uncovered BlackLotus, the world’s first-known instance of real-world UEFI-dwelling malware that bypassed Secure Boot. The discovery resulted in the addition of several new entries in the forbidden DBX database. An attacker with knowledge of the private platform key material can “not only make BlackLotus work again but create other malware and enable it on all these devices,” he said.

PKfail has parallels to at least two recent supply-chain mishaps. The first was in 2016, when a different AMI-supplied platform key stamped "DO NOT TRUST" was found in devices sold by Lenovo. The discovery led to the publishing of CVE-2016-5242 and at least one snarky social media post.

The second parallel occurred last year, when a ransomware threat group breached hardware maker MSI and published two of its private cryptography keys. One of the keys was for digitally signing MSI firmware updates to cryptographically prove that they are legitimate ones from MSI rather than a malicious impostor from a threat actor. MSI used the second compromised key to secure Intel Boot Guard, The leak of this second key made it possible for attackers to bypass this alternate code-signing protection.

In Thursday’s report, members of the Binarly Research team wrote:

The PKfail issue highlights multiple security problems related to device supply chain security:

• Poor cryptographic materials management and appearance of the private keys directly in the code repositories with the hardcoded path from the build scripts.
• Usage of the non-production cryptographic keys responsible for the platform security of production firmware and devices.
• No rotation of the platform security cryptographic keys per product line. For example, the same cryptographic keys were confirmed on client and server-related products. Similar behavior was detected with Intel Boot Guard reference code key leakage.
• The same OEM used the same platform security-related cryptographic keys for firmware produced for different device manufactures. Similar behavior was detected with Intel Boot Guard reference code key leakage.

Four of the affected device makers responded to questions prior to this article going live. An Intel spokeswoman said that the affected Intel Server Board has since been discontinued.

She continued:

However, the chipset and CPU they support, 246 and Coffee Lake, are still in service.

The distinction here–and why this isn’t an Intel issue in currently shipped products and may be causing some confusion–is the key in question was in the BIOS provided and generated by the system manufacturer, in this case AMI, for these server boards.

Key usage, generation, and management is something we take very seriously here at Intel. As a result of the MSI leak that happened back in May of last year, we posted a blog and technical paper describing key usage in integrated firmware images to help clarify how and where keys are used.

Supermicro issued a statement saying, “Supermicro has addressed Platform Key issues mostly in older generation systems with BIOS updates. Additional details can be found at Supermicro's Security Center.”

An HP spokeswoman wrote: “To date we have ascertained that this issue is contained to certain end-of-service commercial systems, and we can confirm that it does not impact any consumer devices or any commercial devices either within service life or running on HP BIOS. Security is a top priority for HP and we continue to investigate this issue further.”

A statement issued by Lenovo said: “Lenovo has investigated and determined that no supported Lenovo systems are exposed to the scenario Binarly claims in its PKFail research paper.”

Fujitsu: “We would like to inform you that our server business was transferred to our subsidiary, Fsas Technologies Inc (FTI), in April this year. We have confirmed with FTI that the products you inquired about have already completed their sales and maintenance services.”

None of the companies answered questions asking how their products came to be using test keys clearly marked as untrusted. All of the companies declined to outline the steps they take to ensure platform keys in their products are managed using best practices in the industry.

Am I affected?

The table below lists all products known to use the test key compromised in the 2022 leak on GitHub. An appendix at the end of the Binarly report lists all products known to have used that key or any of the other test keys.

People who want to know if their Windows device uses one of the test platform keys can run the following powershell command:

> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI
PK).bytes) -match "DO NOT TRUST|DO NOT SHIP"
True

Linux users can detect one of the test certificates by displaying 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

There's little that users of an affected device can do other than install a patch if one becomes available from the manufacturer. In the meantime, it's worth remembering that Secure Boot has a history of not living up to its promises. The most recent reminder came late last year with the disclosure of LogoFAIL, a constellation of image-parsing vulnerabilities in UEFI libraries from just about every device maker. By replacing the legitimate logo images with identical-looking ones that have been specially crafted to exploit these bugs, LogoFAIL makes it possible to execute malicious code at the most sensitive stage of the boot process, which is known as DXE, short for Driver Execution Environment.