.webp)
The Binarly security research team conducts a comprehensive analysis of the recent Intel and MSI source code leaks to model the potential impact.
The nonstop wave of data breaches and ransomware infections have netted victims in hardware and device manufacturing and now the industry is facing a major reckoning. The interconnectedness of the device supply chain means that any data leak at one vendor can have cascading effects throughout computing.
In this blog, the Binarly research team will dig into the data exposed the recent MSI breach and the possible side effects on firmware updates throughout the ecosystem. We examine the entire public data corpus of MSI firmware images from their website to look for malicious alterations that significantly differ from previous releases and analyze the data distribution to identify code changes originating from either silicon or IBV vendors.
We conclude that no malicious code was implanted during the data breach of MSI but there are some shocking results worth looking at.
Repeatable supply chain failures are frequently leading to private key breaches, especially with silicon/device vendors. Last September, there was a massive Lenovo (LCFC) data breach that included the leak of Intel keys and firmware reference source code.
More details can be found in our previous blog release dedicated to this incident.
The Key Manifest (KM) and Boot Policy Manifest (BPM) private keys were found in the leaked Alder Lake platform source code. These keys are used for the Intel Boot Guard technology that provides the 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 allows 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.
Later, it was confirmed that previously leaked Intel BootGuard private keys from Lenovo/LCFC in September 2022 are still relevant for numerous devices in the field (Lenovo, Supermicro, Intel, etc.)
Recently, the Binarly team detected Intel and Supermicro devices using this leaked key. This is the first time we see two OEMs using the same key for Intel Boot Guard -- suggesting that Intel might be providing a keygen service for OEMs and not allowing them to create keys by themselves.
In addition, we discovered the private part of another key. This is a key for Intel Integrated Sensors Hub (ISH) firmware. Occasionally Intel allows OEMs to sign ISH firmware, however, it seems this key is used to sign the Intel-developed firmware for ISH.
In May this year, MSI acknowledged a significant data breach that included the public release of data that includes a vast number of private keys that could affect numerous devices.
Digging deeper into the aftermath of the MSI data breach, Binarly 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 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.
The OEM private key file bxt_dbg_priv_key.pem was found in multiple sources - MSI source code leak and ASUS source code. Diving deeper into this, we discovered that this key is associated with Intel Orange or OEM Unlocked. Based on Intel documentation, it appears to be more powerful in comparison to Boot Guard keys. The bxt_dbg_priv_key.pem, which is the Intel OEM Platform Key (Orange Unlock) obtained from an MSI leak, has been detected on devices from HP, Lenovo, AOPEN, CompuLab, and Star Labs.
The key itself is located inside the common Intel binary header:
As it turns out, this key is used in the verification scheme of 3 OEM-provided parts of IFWI (Integrated Firmware Image).
One of them is BPM (Boot Policy Manifest) that describes IBB (Initial Boot Block) of UEFI BIOS:
The second part is SMIP (Signed Master Image Profile) that usually incorporates PMC (Power Management Controller) firmware and ISH (Integrated Sensors Hub) firmware:
Obviously, the leaked private key allows a potential attacker to make and sign malicious modifications to these parts of IFWI firmware of the device. These modifications would pass Intel TXE based IFWI firmware verification mechanism making this procedure completely ineffective.
Thirdly this key is used to create OEM Unlock Tokens that provide high-privileged access to platform debugging feature (Orange Unlock) for the OEM parts of IFWI firmware.
Overall the verification scheme of IFWI components looks like this:
According to the CVE-2018-3659 and CVE-2018-3643 white paper, the Intel Converged Security Management Engine (CSME) System on a Chip (SoC) has four different DFx (Design For testability, debug, security and validation) states:1. Green (DFx locked) - normal state;2. Orange (DFx unlocked) - allows to debug OEM IPs;3. Red (DFx unlocked) - allows Intel to debug ALL IPs;4. DAM (Delayed Authentication Mode) - special state in which debug interfaces are still closed.
Hence, OEM.key contains signed debug tokens for Orange Unlock.
The following picture summarizes all impacted firmware parts showing us how the supply chain failure affects device security.
Orange Unlock provides the capability to debug (control execution flow) of OEM IPs via USB: CPU, ISH and PCM which is a huge threat to platform security.
It is worth mentioning that they use this key for the BXT platform to sign firmware for itself and the GLK platforms.
This key could be an artifact from pre-production build versions. Still, it is possible to use this key in production signing, however CI/CD systems probably block using such keys in the production lines. Also, production versions of hardware should be protected from using pre-production versions of keys in a trusted boot process.
Additional info and impacted devices: - https://github.com/binarly-io/SupplyChainAttacks- https://duo.com/decipher/intel-bootguard-firmware-signing-keys-found-in-msi-data-leak- https://www.theregister.com/2023/05/09/intel_oem_private_keys_leaked
According to Binarly telemetry data, approximately 20% of firmware updates contain at least two or three known vulnerabilities (previously disclosed), according to Binarly Platform data (based on enterprise-grade vendors study). But when we are talking about such data breaches with leaked keys they're usually impacting the ecosystem way longer compared to any other vulnerabilities. Due to the complexity of the supply chain revocation of such key can take years or impossible by design it really depends case per case. Binarly Transparency Platform can detect not only leaked key but also prevent developers from shipping firmware updates with the testing or bringing up related cryptographic keys.
Binarly provides FwHunt rules to detect vulnerable devices at scale to help the industry recover from firmware security repeatable failures.
FwHunt Community Scanner: https://github.com/binarly-io/fwhunt-scan
FwHunt detection rules: https://github.com/binarly-io/FwHunt/tree/main/rules
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)
