.webp)
The increasingly large number of firmware vulnerabilities gives attackers a lot of options for persistence and the means to bypass traditional endpoint solutions. At least two recently discovered firmware implants -- MoonBounce and CosmicStrand -- have persisted for more than seven years by using basic firmware bootkit techniques. In general, the UEFI system firmware grows in complexity every year and constantly introduces new attack surfaces.
Binarly’s research work has conclusively proved that, based on the numerous vulnerabilities we have disclosed across the entire industry, existing approaches to detecting firmware-related security problems do not work:
Silicon Vendors Reference Code: Intel, AMD
Independent BIOS Vendors (IBV) Reference Code: Insyde, AMI
Original Design Manufacturing (ODM) Firmware Code: Atos, Intel, Dell, HP, Lenovo, Fujitsu.
Over the last twelve months, Binarly's research team has publicly disclosed 60+ high-impact vulnerabilities in System Management Mode (SMM), Pre-EFI (PEI) and more general DXE applications/drivers. An attacker can trigger most of these vulnerabilities from the operating system to attack the system firmware and gain persistence on the device.
Last week, at Black Hat US 2022 conference, we disclosed twelve (12) new high-impact vulnerabilities (overall CVSS score: 7.8).
The active exploitation of all the discovered vulnerabilities can’t be detected by firmware integrity monitoring systems due to limitations of the Trusted Platform Module (TPM) measurement. The remote device health attestation solutions will not detect the affected systems due to the design limitations in visibility of the firmware runtime.
Our presentation (Breaking Firmware Trust From Pre-EFI: Exploiting Early Boot Phases) at Black Hat USA 2022 summarizes our work over the past few months to identify the weak spots found in pre-EFI (PEI) early boot drivers. Last year at Black Hat USA, we touched on the importance of the attack surface coming from a pre-EFI environment (Intel's BSSA DFT) in “Safeguarding UEFI Ecosystem: Firmware Supply Chain is Hard(coded)”.
On newer devices, vendors have increasingly turned their attention to firmware security and runtime mitigations for the system firmware execution environments like SMM. The new Intel platform firmware runtime mitigations reshaped the attack surface for SMM and DXE runtimes with new Intel Hardware Shield technologies applied below-the-OS. The complexity of the modern platform security features is growing every year. The general security premise of the platform consists of many different layers of abstraction where each of these layers define their own security boundaries. Unfortunately, in many cases, these layers may introduce inconsistencies in mitigation technologies and create room for breaking general security premises, creating new attack surfaces. One of such cases is a vulnerable Pre-EFI (PEI) environment. With no protections available at this earliest boot phase, a simple arbitrary code execution vulnerability could compromise multiple trusted boundaries and lead to the whole device compromise by disabling multiple security features.
Digging deeper into the Pre-EFI (PEI) attack surface, there are lots of data objects generated, processed and transmitted between different boot phases or even within a single phase.
Memory corruption vulnerabilities in the code handling a Platform Configuration Data (PCD) or an NVRAM storage could be a starting point in an exploitation chain. The UEFI architecture doesn’t assume that the early phase could be an attack surface. This is the reason why this threat model is often underestimated by vendors, who keep tightening the screws only for SMM code - as the most known and popular target available for runtime environments.
As an example, the NVRAM region in the figure above is not protected by Intel Boot Guard in the SPI flash and can be abused by an attacker with physical access to the device (supply chain vector). It can be exploited each time a computer is rebooted since this vulnerability can be used as a persistent vector.
New mitigation techniques are often advertised as game-changers by vendors. In fact, some of them create a significant difference by reshaping the attack surfaces and changing the threat models. Due to the increased complexity of modern firmware, it is necessary to look over the design limitations and identify the problems which have previously been overlooked. During our research we found a significant problem where most of the devices in the field don’t enable Intel PPAM attestation.
As part of this research, the Binarly team reverse engineered the PPAM manifest and PPAM headers formats and created automated parsers that will be publicly released after the vendor embargo ends.
The results of Intel PPAM 11 certificate parsing for 209 enterprise vendor firmware files from the most recent devices on the market are presented below:
Basically, all the available certificates related to the PPAM manifest have expired. We suspect that Intel PPAM reference code was shipped to the device vendors and Intel PPAM Production Signer key was never updated after being shipped with the initial PPAM manifest certificate since the attestation for the PPAM manifest has never been enabled in the field on all of these devices. As shown in the figure below, the Intel certificate expired since May 2021:
In the case of failed device attestation, we can find ways to influence the PPAM configuration data and use this as an attack vector to disable this security feature on enterprise devices. In this case we extended the attack surface to connect pre-EFI (PEI) attack vectors to the PPAM architecture figure below.
The implementation of the PpamPlatformSmm module is OEM vendor-specific and introduces an additional attack surface on these specific implementations of Intel PPAM technology. For example, one of the devices we reviewed during our research was a recent HP EliteBook laptop. On the figure below one can see the difference between the Intel reference implementation and the HP specific one.
Binarly research team demonstrated a method of disabling Intel PPAM components from the Pre-EFI (PEI) environment, proving that it could be achieved with a one-byte-write vulnerability on some HP devices. The configuration data dependencies always open interesting attack vectors as for example HOB (Hand-off Block) data is available during Pre-EFI boot phase. On the figure below if the function CheckPpamSupportHob() returns false then PPAM will not be configured and initialized.
A new attack vector was discovered that leverages this vulnerability from the Pre-EFI environment. To understand its impact the Binarly team performed multiple experiments on different platforms. In the picture below, a dump of the original HOB data from a HP device is shown.
If the HOB sanity check passes, the PpamSupport (Version) variable is initialized to 11 on the target device. As shown below, there are two ways how we can downgrade it, by modifying the CpuSmm NVRAM variable or via PcdProtocol->SetBool(0x138, 0) call which sets it to zero (figure below).
After downgrading the PpamSupport to version 10, the protocol EFI_SMM_RESOURCE_CONFIG_PROTOCOL will be useless. This protocol is used to install or configure PPAM policies for IO and MSR access.
Binarly team used the BRLY-2022-027/CVE-2022-28858 (INTEL-SA-00712) vulnerability from the twelve others disclosed to perform the previously discussed Intel PPAM attack on a specific device.
Following is an overview of some of the vulnerabilities that were revealed and disclosed during our Black Hat 2022 presentation.
The aforementioned vulnerability is a typical stack buffer overflow since it wasn’t taken into consideration that the SaSetup and CpuSetup NVRAM variables can have different sizes. This is a classical double-GetVariable problem that causes arbitrary code execution during the early PEI phase. The pseudocode for the vulnerable function is shown below:
If the size of the SaSetup NVRAM variable is larger than 0x430 bytes, then after the first call of the GetVariable() service, the DataSize stack variable will be overwritten with this size. After a second call of the GetVariable() service, a stack overflow may occur (the stack variable Data will be overflowed). An overflow of 24 bytes is enough to execute arbitrary code. One can argue this code cannot be exploitable because all Setup variables should be protected from being modified from the Runtime environment. That’s true, but not always - in our practice we encountered devices that don’t prevent Setup variables from being changed after the end of boot services. Moreover, this attack was possible on our target device (Intel NUC M15, firmware version: BC0071) due to incorrectly configured filtering in NvramSmm. During our Black Hat USA presentation we demonstrated the possibility of changing the values of the SaSetup and CpuSetup variables using a simple chipsec script.
In the case of BRLY-2022-027/CVE-2022-28858 vulnerability, we highlighted a pretty common type of misuse of GetVariable() service by using our efiXplorer tool to detect such clases of the vulnerabilities automatically:
It should be noted that even if the SaSetup or CpuSetup variables are filtered, their values can still be modified by reflashing the NVRAM or through a vulnerability in SMM.
Below is an explanation of the vulnerability in the SmmSmbiosElog module (BRLY-2022-016/CVE-2022-33209 (INTEL-SA-00712)).
In the following demo we are demonstrating the possibility of modifying the value of the Setup variable using this vulnerability.
The root cause of both vulnerabilities (BRLY-2022-016 and BRLY-2022-027) was found in the reference code associated with AMI firmware framework code. Multiple enterprise vendors were using AMI-based firmware SDK to develop their pieces of firmware.
We would like to warmly thank the Intel, AMI and HP PSIRT teams for the collaboration and assistance they have provided during the disclosure process.
“HP appreciates Binarly’s contributions to help make HP products more secure.”
“AMI is committed to working closely with Binarly to leverage its innovative vulnerability detection technologies to strengthen the security of our products and firmware supply chain. We believe this collaboration is essential to protecting our customers and improving AMI's overall security posture. AMI looks forward to partnering with Binarly in this important effort.”
“Intel appreciates recent collaboration with Binarly involving their security research and notification of affected vendors.”
The main purpose of this year Binarly’s Black Hat US talk was to raise awareness about these firmware repeatable problems by demonstrating how the pre-EFI attack vectors can be used to attack the implementation weaknesses of the new mitigations such as Intel PPAM. For all vulnerabilities mentioned in this blog, Binarly has publicly released the FwHunt detection rules.
Disclosing the vulnerabilities and informing the customers of this firmware or device is the most important part for not leaving devices unpatched for years. Understanding the impact and scope of the affected parties at scale is the most challenging part of each vulnerability disclosure.
Are you interested in learning more about Binarly FwHunt or Binarly SaaS Platform?
Don't hesitate to contact us at [email protected].
.svg)
