.webp)
This blog post describes my joint research with Alexandre Gazet that culminated with us presenting the “Breaking Through Another Side: Bypassing Firmware Security Boundaries from Embedded Controller” (slides) talk at BlackHat 2019 Conference in Las Vegas. Our REsearch focused on the Embedded Controller security and Intel BIOS Guard technology implementation in Lenovo Thinkpad BIOS and took around 5 month of our spare time.
In this blog post, I will focus on a common architectural problem when hardware design doesn’t connect different pieces of hardware across a x86-based device to one unified threat model; each hardware device has its own threat model and attack surface. This opens the door for an attacker to successfully attack one single microcontroller on the motherboard and escalate it to a more privileged area behind security boundaries frequently left out of consideration by security architects. Let’s take a look at some examples of those devices:
Figure 1: How many different pieces of firmware fit into one firmware update?
In my first blog post “Who Watches BIOS Watchers?” I have discussed several problems with UEFI Firmware updates and Intel Boot Guard implementation failures. It includes some thoughts about how many separate firmware updates should be delivered in a single update package from a hardware vendor. All these pieces of firmware delivered in a single package have their own update process and security features that differ from each other. There is no unified update process for all the pieces of firmware on a hardware platform.
Figure 2: A security boundary between different platform components
If security boundaries are separated between different devices an attacker can choose the weakest one to cross its boundary and step out of the threat model considered by security architects. This is actually even worse because some of the controller’s pieces of firmware such as USB-C are delivered as a signed binary blob which can only guarantee that it comes from the vendor specified in the digital signature. There is no guarantee that the update package doesn’t contains malicious implants and other supply chain security failures. The Stuxnet hangover in the Antivirus industry was pretty strong and demonstrated the fundamental problem of infinite trust into signed code. The very similar situation related to infinite trusting of signed binary blobs is experienced right now by the hardware industry (Microcode, CSME, FSP, ACM are just the tip of the iceberg). To make it worse, the hardware companies are outsourcing the system firmware development, like the BIOS, to 3rd-parties without even having access to the source code for review. In this case, all the security is mostly based on the agreed proposal of security requirements which is hard to verify in reality. This approach saves money on development and support process but it significantly decreases the level of security confidence.
Another good example of broken security boundaries from supply chain perspective is the recently discovered ShadowHammer APT where ASUS update delivery tools have been abused to deliver malicious payloads. An interesting remark is that the same ASUS Live Update software is responsible for the delivery of UEFI firmware updates. Basically, a malicious firmware update can cross all the security boundaries from OS to SPI flash storage without any indication of maliciousness. Last year, I wrote about this problem from a different perspective in “What makes OS drivers dangerous for BIOS?”. Additional concerns about signed kernel-mode drivers from BIOS update tools were raised by researchers in the presentation “Get off the Kernel if you can’t Drive” at DEF CON 27. The reason why unverified firmware updates are such a great risk is that after a firmware update was delivered and installed it has already crossed the hardware security boundaries and is considered trusted.
Let’s get back to the discussion about security boundaries created by hardware. It’s important to always keep in mind:
Hardware/Firmware Security != SUM of all Security Boundaries
In practice, it looks like all the boundaries are separated and if you crossing/bypass one you can accidentally bypass many of them at the same time. Logically, the FW/HW Security is not the SUM of the boundaries, it’s a Boolean OR (||) between them.
HW_SEC_Boundary_1 || HW_SEC_Boundary_2|| … || HW_SEC_Boundary_N
Most of the hardware vendors are considering the platform hardware, like the motherboard, as a trusted boundary and is frequently left out of the attack surface model.
Figure 3: Modifications to SPI flash storage during runtime
A very good example of this oversight was demonstrated on the HITB conference in the “Now You See It: TOCTOU Attacks Against Secure Boot and BootGuard” talk by Trammell Hudson and Peter Bosch where they demonstrated a race condition (TOCTOU) attack on the Intel Boot Guard technology based on a design vulnerability of infinite trust to the SPI flash storage. This issue is hard to patch properly and most of the vendors created additional authentication checks to reduce the time of a possible attack window. The important lesson to learn from this research:
Authenticated once != trusted forever
Another good example of security boundaries failures is the Trusted Platform Module (TPM) which is frequently present as a separate chip soldered on the motherboard (Figure 5). System firmware such as the BIOS does not expect malicious activity coming from this direction. In 2018, Jeremy Boone presented the interposer attack (Figure 4) on serial bus called TPM Genie and found multiple issues in EDKII code.
Figure 4: Interposer attack on a TPM serial bus
Trammell Hudson earlier demonstrated the possibility of an attacker to solder directly the wires on the TPM chip to implement man in the middle attack. Both attacks showed significant problems with blindly trusting the TPM and created serious security design concerns.
Figure 5: Sniffing TPM soldered on the motherboard
Last but not the least example is based on the research “Turning your BMC into a revolving door” presented by French researchers Fabien Perigaud, Alexandre Gazet and Joffrey Czarny at ZeroNights conference in 2018. Board Management Controller (BMC) is part of any server platform and provides capabilities to communicate and update UEFI firmware by directly accessing the SPI flash. This method also crosses the security boundaries because the authentication process for a BIOS update is now dependent on the strength of the BMC admin user password or the BMC firmware update verification routine.
Figure 6: HP iLO BMC chip
This point significantly changes the threat model but in reality it is not frequently considered since:
BIOS update authentication == BMC update authentication
BIOS update authentication == BMC admin password strength
As we can see, hardware security boundaries are hard and very diverse. I discussed just a few examples which have been recently covered by researchers. In reality, only one hardware company made a shift from a separate security model for each single hardware component to a unified security model. In the unified security model, the attack surface considers all hardware components all together as an atomic thing. In my opinion, this is the right direction Apple, keep going (kudos to Ivan Krstic and team) ;-)
.svg)
