.webp)
Binarly researchers find that Boot Guard key misuse is a recurring problem and affects the entire computing software supply chain.
This is the continuation of the Binarly REsearch team’s comprehensive analysis of the Intel and MSI source code leaks that occurred earlier this year.
When Intel published its recent paper "Introduction to Key Usage in Integrated Firmware Images", the Binarly research team was expecting a post-mortem on recent data breaches with MSI and Lenovo/LCFC and a step-by-step explanation of the gaps in the key management process and how to avoid them.
Unfortunately, this didn’t happen. The Intel paper, while still a good source of information, leaves a lot of gaps in the story. After seeing these gaps in Intel’s publication, our research team decided to shed more light on both incidents that happened with Lenovo/LCFC in September 2022 and MSI in April 2023. This blog augments our previous story, "Leaked MSI source code with Intel OEM keys: How does this affect industry-wide software supply chain?" with additional details and feedback on Intel’s paper.
The major disagreement is related to the missing validation of products that shipped to customers. The vendors can have perfect documentation, but without validation, it’s hard to understand if it applies or not, or whether specific device manufacturers ignored this guidance and invented their own “wheel.” For example, most of the tools involved in signing key generation for security technologies, like Intel Boot Guard and Intel BIOS Guard, are developed in a way where the private key should be read from the file system.
The figure below shows the screenshot when one of the developers from ASUS Aaeon company used a public GitHub repository containing production firmware code used on some of the devices developed for critical infrastructure. As you can see, this repository also contains private keys that unlock debug capabilities on the Intel-based Apollo Lake devices. These debug capabilities can also be used to bypass some of the security features and allow attackers to install persistent implants.
This Github repository was deleted a few months ago and an investigation was conducted regarding MSI private keys breach. The Binarly Transparency Platform is still detecting the leaked keys on multiple devices across our customer's ecosystems.
One of the shocking discoveries during our initial analysis was that the same Intel Boot Guard keys had been reused by multiple device vendors. How is this even possible if the keys should be generated by device manufacturers or OEMs who develop and support firmware code for them?
In its paper, here’s how Intel explains the potential root cause of the Intel OEM keys reuse between multiple product lines and vendors:
“However, some production systems have been identified that were using the example keys from the reference code instead of OEM/ODM-generated keys.” – Intel Corporation.
It’s also worth mentioning that we identified the Intel Boot Guard keys misuse and shared the data and tools for reproducing detection with Intel’s PSIRT about six months ago. We believe that better transparency around these incidents will help the industry avoid future incidents and improve the overall security posture of the supply chain.
These issues are a result of layers of complexity that haunts every layer of the computing ecosystem. The silicon vendors shared original reference code with some examples or reference implementation regarding security technologies like Intel Boot Guard and many others. This reference code is shared with OEMs and ODMs that can reuse the sample pre-generated private keys between different product lines.
Which brings us to the obvious next question: Why have the same private keys been used by different device manufacturers and shared between Lenovo, Supermicro, and Intel Server product lines? If that’s just sample code, why did Intel Servers make such a mistake using it in production? Let’s keep digging into the rabbit hole to find the answers.
The Binarly team has been digging into the aftermath of the MSI data breach and concluded the Intel OEM private key was leaked, causing an impact on the entire ecosystem. The reality is that Intel Boot Guard may not be effective on certain devices based on the 11th Tiger Lake, 12th Adler Lake, and 13th Raptor Lake. It affects many different device vendors, including Intel, Lenovo, Supermicro, and many others across the entire industry.
The Key Manifest (KM) and Boot Policy Manifest (BPM) private keys were found in the leaked MSI source code. These keys are used for the Intel Boot Guard technology that provides a firmware image verification mechanism with a hardware Root of Trust. The hash of the OEM Root RSA public key from the KM is programmed into the chipset's Field Programmable Fuses (FPFs). The main purpose of the KM is to store the hash of an RSA public key from the BPM, which in turn contains the information on the Boot Policy, Initial Boot Block (IBB) description, and its hash. The leaked private key components of the mentioned keys allow a potential attacker to sign the modified firmware image for this device so it would pass Intel Boot Guard's verification, making this technology completely ineffective and potentially compromised.
The steps of malformed modification of the production device with leaked Intel Boot Guard keys is shown in the following figure:
This attack was practically confirmed by researchers (“Boot Unguarded: x86 Trust Anchor Downfalls to The Leaked OEM Internal Tools and Signing Keys”) who were able to sign the modified firmware image for MSI device with the leaked private keys for Intel Boot Guard technology and flash the modified firmware image successfully to the device.
At Black Hat USA 2022, we previously demonstrated the physical attack surface specifics that allows building an attack chain without the need to hold the RSA private key for Intel Boot Guard. An important attack surface hiding in an early-boot environment like pre-EFI (PEI) was explained in our blog “Black Hat 2022: The Intel PPAM attack story”. To perform such attacks, it requires interfering with NVRAM or other areas on SPI flash memory that architecturally could not be covered by Intel Boot Guard technology. However, the demonstrated physical attack surface opens a way to exploit these vulnerabilities more effectively.
Recently we reported a massive amount of vulnerabilities in Intel reference code related to NVRAM which was considered by Intel PSIRT to be out of scope for the current threat model.
We continue to see a lot of inconsistencies in threat modeling between different vendors. We strongly believe these attack surfaces in NVRAM opens a lot of potential for an attacker and, in combination with other vulnerabilities, will not require physical access as explained in our previous blog “A Fractured Ecosystem: Lingering Vulnerabilities in Reference Code is a Forever Problem”.
Back to the leaked keys topic, we missed that with the leaked keys, there is a way to build a pure-software attack for rewriting SPI flash memory with the modified firmware image and running it.
Another important discovery from the leaked MSI data was the signing private keys for Firmware Capsule (FwCapsule). The Firmware Capsule update package is a standard to deliver firmware updates for UEFI-based devices and is described in detail in UEFI specification. In the picture below, we demonstrated where the Firmware Capsule (FwCapsule) private keys were located in the leaked MSI source code.
After looking closely at the folders, we figured out that these leaked private keys were representing AMI OEM Firmware Keys. These keys are used for AMI firmware capsule image signature verification mechanism. The leaked private components of the mentioned keys allow an attacker to sign the modified firmware capsule image for this device and abuse the firmware update procedure with a modified firmware image. Essentially, the threat actor can bypass firmware update signature verification and deliver malicious firmware code to the affected devices!
The combination of signing AMI OEM Firmware Keys with the leaked Intel Boot Guard keys allow an attacker to create a modified AMI firmware update capsule that can be installed on the device the same way as the original firmware update delivered to the device by using AMI Flash toolchain. An attacker can use these tools to deliver these modified firmware capsule updates directly from the operating system.
No additional firmware vulnerabilities are required to be exploited for this attack, just administrator privileges!
This combination of leaked private keys Intel Boot Guard key + AMI FW key = valid AMI update capsule is very dangerous because it opens the door for the attacker to deliver any malformed code in the signed firmware update format. The figure below shows the described attack via AMI update capsule.
This attack has a significant impact on the operating system. Most traditional security solutions will not be able to spot these firmware modifications and will be completely blind to this entire attack surface. To visualize the impact, we modified our attack surface diagram to scope the specific impact that comes from modified firmware updated signed with the leaked MSI keys.
As we can see from this diagram, it shows a complete bypass of the Root of Trust for UEFI system firmware on the device and opens the doors to deliver a persistent malicious payload directly to SPI flash firmware storage. The malicious payload could survive OS reinstallation or hard-drive replacement.
The Binarly REsearch team scoped all the affected product lines impacted by both Intel Boot Guard keys (KM and BPM) and AMI OEM Firmware Key. In total, we found 57 affected products that are already available on the market.
We also noticed that different MSI products reuse AMI OEM Firmware Key. This leads to the conclusion all the cryptographic keys have been misused and stored directly in the source code. In general, such mistakes lead to a significant impact across all the devices shipped by the vendor to the market, and vulnerable devices will be available in the field for years.
Binarly provides FwHunt rules to detect vulnerable devices at scale to help the industry recover from firmware security repeatable failures.
FwHunt.RUN provides free detection: https://fwhunt.run
FwHunt detection rules: https://github.com/binarly-io/FwHunt/tree/main/rules
Binarly Transparency Platform is available to all customers with the detection of leaked MSI and Lenovo/LCFC leaked keys detection. As always, it’s augmented with the most recent threat intelligence data and helps our customers stay protected proactively in the rapidly emerging threat landscape below the OS.
The Binarly team is constantly working to protect the firmware supply chain and reduce the attack surfaces of our customers industry-wide by delivering innovative technologies to the market. Based on our experience we understand that fixing vulnerabilities for a single vendor is not enough. As a result of the complexity of the firmware supply chain, there are gaps that are difficult to close on the manufacturing end since it involves issues beyond the control of the device vendors.
Are you interested in learning more about Binarly Platform or other solutions? Don't hesitate to contact us at fwhunt@binarly.io.
.svg)
