.webp)
Secure Boot has always been the holy grail of platform security, and many security features at the operating system layer depend on its integrity. The first implementations originally appeared as a proposal in UEFI reference code called Tianocore EDK2 in the early 2000’s but have been easily circumvented due to weak designs. In 2014, additional security technologies like Intel Boot Guard were introduced to anchor secure boot security to the hardware but the high-level components of the original EDK2 implementation have not evolved significantly, leaving us with a major weakness in platform security.
.png)
In 2023, the Binarly REsearch Team discovered a significant supply chain security incident when leaked private keys from Intel Boot Guard distributed by Intel in their reference code were used in production, an issue that impacted multiple vendors. Binarly documented all the impacted device manufacturers from this MSI/Insyde data breach and added the early detection of leaked keys to help the industry recover from this repeatable failure in supply chain security.
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 incident occurred at an ODM 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.
The figure below shows the chronological order of the events that led to the investigation of PKfail by The Binarly REsearch Team.
The PKfail issue highlights multiple security problems related to device supply chain security:
To help the industry mitigate this threat, Binarly team has created a free scanning tool available to the entire security community to help expose vulnerable devices and system firmware updates as well as malicious payloads. The detection method we use has close to zero false positive rate.
The PKfail scanner is based on the Binary Intelligence technology announced earlier this year and is available for free at PK.fail.
Binarly customers and partners received early threat intelligence notifications and detection logic to detect PKfail has been successfully deployed to Binarly Transparency platform to help scope the vulnerable devices and mitigate the threat.
Binarly REsearch is always committed to following the best practices in the responsible disclosure process, and our team has been closely working with the CERT/CC team on VU#455367 to help mitigate PKfail industry-wide.
We had great synergy during the disclosure process with our customer, Dell. They use the Binarly Transparency Platform to protect multiple product lines. Initially, we found the default non-production Platform Key (PK) from AMI inside the Dell XPS 8960 Desktop firmware image, making this and other product lines exposed to the PKfail vulnerability. These products initialize Secure Boot variables with non-production values from AMI and are thus vulnerable to PKfail. We have confirmed this finding by checking the NVRAM variables content in live firmware dumps of affected products:
Upon further investigation and analysis, the Binarly REsearch Team found that in other product lines Dell correctly implemented a mitigation to PKfail. This mitigation is implemented in the module DellSecureBootSmm {d54a91f0-4547-4380-8890-17c19937f853}, which sets the Secure Boot variables with values from Dell. These values are hardcoded in the data section of the module itself:
This finding was also confirmed by checking the NVRAM variables content in live firmware dumps for products containing DellSecureBootSmm module:
An important part of responsible disclosure is collaboration with the vendor and we commend Dell for the partnership on this research.
Be among the first to be notified of zero day disclosures and other vulnerabilities detected by the Binarly REsearch Team by subscribing to our newsletter, The Binarly Bulletin.
PKfail is a firmware supply-chain issue affecting hundreds of device models in the UEFI ecosystem. The problem arises from the Secure Boot "master key," known as the Platform Key (PK) in UEFI terminology, which is untrusted because it is generated by Independent BIOS Vendors (IBVs) and shared among different vendors.
This Platform Key, which manages the Secure Boot databases and maintains the chain of trust from firmware to the operating system, is often not replaced by OEMs or device vendors, resulting in devices shipping with untrusted keys.
An attacker with access to the private part of the PK can easily bypass Secure Boot by manipulating the Key Exchange Key (KEK) database, the Signature Database (db), and the Forbidden Signature Database (dbx).
PKfail represents yet another example of cross-silicon issue, as it affects both x86 and ARM devices.
The Binarly research team discovered that hundreds of products use a test Platform Key generated by American Megatrends International (AMI). 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 test keys are shared with commercial partners and vendors with the expectation they be treated as completely untrusted.
By scanning an internal dataset of firmware images, we confirm that devices from unrelated vendors contain the same Platform Key, meaning that these keys must have been generated at the root of the firmware supply-chain.
These test keys have strong indications of being untrusted (for example, the certificate issuer contains the “DO NOT TRUST” or “DO NOT SHIP“ strings).
We discovered the private component of one Platform Key in a data leak where a suspected ODM employee published the source code containing the PK on a public GitHub repository. The private key was stored in an encrypted file, which was “protected” by a weak 4-character-long password and thus easily guessable with any password-cracking tool.
To understand the actual scope of PKfail and its historical patterns, we scanned an internal dataset of UEFI firmware images using the Binarly Transparency Platform. This dataset is representative of the UEFI ecosystem and contains tens of thousands of images released in the last decade by all the major device vendors, including Lenovo, Dell, HP, HPE, Supermicro, Intel, MSI and Gigabyte.
The macro results of this scan are quite alarming: more than 10% of firmware images in our dataset use an untrusted Platform Key and are thus vulnerable to PKfail. When only looking at firmware released in the past 4 years, the percentage reduces to 8%, though remaining at concerning levels.
The first firmware vulnerable to PKfail was released back in May 2012, while the latest was released in June 2024. Overall, this makes this supply-chain issue one of the longest-lasting of its kind, spanning over 12 years. The list of affected devices, which at the moment contains almost 900 devices, can be found in our BRLY-2024-005 advisory.
A closer look at the scan results revealed that our platform extracted and identified 22 unique untrusted keys.
Exploiting PKfail allows attackers to run untrusted code during the boot process, even with Secure Boot enabled. This compromises the entire security chain, from firmware to the operating system.
Attackers with access to a device vulnerable to PKfail can bypass Secure Boot by signing malicious code, allowing them to deliver any sort of UEFI bootkit, such as the recently discovered BlackLotus
The PKfail issue highlights multiple security problems related to device supply chain security:
Device vendors should ensure that they generate and manage the Platform Key following best practices for cryptographic key management, such as using Hardware Security Modules. They should replace any test keys provided by IBVs with securely generated keys.
Users should stay informed about firmware updates from their device vendors and apply any security patches that address PKfail vulnerabilities. It's also important to follow best practices for securing their devices and networks. Check for signs of Pkfail on your devices by visiting https://pk.fail/
.svg)
