Breaking Through Another Side: Bypassing Firmware Security Boundaries

This blog post is the first in the series about my joint Black Hat research “Breaking Through Another Side: Bypassing Firmware Security Boundaries from Embedded Controller” (slides) with Alexandre Gazet presented last week in Vegas. This REsearch took literally 5 months of our spare time to dig into Embedded Controller security and Intel BIOS Guard technology implementation in Lenovo Thinkpad BIOS.

In this blog post, I will focus on the common architectural problem when hardware design doesn’t connect different hardware across the x86-based device to the one unified threat model. Each device has its own threat model and attack surface. It’s creating interesting room for the attacker to success in attack to one single microcontroller on the motherboard and continue the attack with a more privileged place behind security boundaries frequently out of consideration of security architects. Let’s take a look at some examples of those devices:

• USB controller’s
• Network cards
• Embedded Controller (EC)
• Fingerprint reader
• Touchpad
• Graphic card (GPU)
• Trusted Platform Module (TPM)
• Board Management Controller (BMC)
• and many others

In my first blog post on Medium “Who Watch BIOS Watchers?” I have discussed particular problems with UEFI Firmware updates and Intel Boot Guard implementation failures. But it includes some thoughts about how much separate firmware updates can be delivered in a single update package from the hardware vendor. All this firmware's has delivered in a single package has their own update process and security features separated to each other. There is no unified update process for all the firmwares on the hardware platform.

If security boundaries separated between different devices an attacker can choose a weakest one to cross the boundaries and step out of the threat model considered by security architects. And it’s actually even worse because some of the controller’s firmware’s like USB-C and others come as a signed binary blob which only can guarantee it comes from a specific vendor based. But it’s no guarantee about malicious implants inside and other supply chain security failures. I think Stuxnet hangover with signed drivers in AV industry was pretty strong and demonstrate the fundamental problems of infinite trust to signed code. The pretty similar collisions with infinite trust to signed binary blobs happening right now in hardware industry (Microcode, CSME, FSP, ACM’s just the tip of the iceberg). The worst case when hardware company outsources system firmware development like BIOS to 3rd-party without even access to the source code. In this case, all the security mostly based just on the proposal of security requirements which is hard to verify in reality. This approach safe the money on development and support process but significantly decreased the level of security confidence.

One more good example of broken security boundaries from supply chain perspective it’s recently discovered ShadowHammer APT where ASUS update delivery tools been abused to deliver malicious payloads. An Interesting point the same ASUS Live Update software responsible for delivery UEFI firmware updates. Basically, malicious firmware update can cross all the security boundaries from OS to SPI flash storage without any attention about malicious activity. In the last year, I wrote a blog post about that from a different perspective “What makes OS drivers dangerous for BIOS?”. Some 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” from DEF CON 27. The reason why I mention firmware updates is that after the firmware update is delivered and installed it’s already cross the hardware boundaries and considered as trusted.

Let’s back to the discussion about security boundaries created by hardware. It’s important to always keep in mind:

Hardware/Firmware Security != Summary of all Security Boundaries

In practice, it looks like all the boundaries separated and if you crossing/bypass one you can accidentally bypass many of them in the same time. Logically it’s not SUM of the boundaries it’s Boolean OR between them.

HW_SEC_Boundary_1||HW_SEC_Boundary_2||HW_SEC_Boundary_N

The most of the hardware vendors considered platform hardware (like motherboard) as trusted boundary and frequently it’s out of scope for attack surface model. A very good example of this mistake was demonstrated recently on HITB conference in the research “Now You See It: TOCTOU Attacks Against Secure Boot and BootGuard” by Trammell Hudson and Peter Bosch.

Where researchers demonstrated race condition (TOCTOU) attack on Intel Boot Guard technology based on design vulnerability with infinite trust to SPI flash storage. This issue hard to patch properly and most of the vendors just created additional authentication checks to reduce the time of possible attack window. The important lesson to learn from this research:

Authenticated once != trusted forever

Another good example of security boundaries failures is Trusted Platform Module (TPM) where it frequently represents on the motherboard as soldered separate chip. And system firmware like BIOS does not expect malicious stuff coming from this direction. Jeremy Boone in the last year present interposer attack on serial bus called TPM Genie and found multiple issues in EDKII code.

Trammell Hudson earlier demonstrates the possibility of the attacker to solder directly the wires on TPM chip to implement man in the middle attack. Both attacks show significant problems with trust to TPM and created serious security design concerns.

And the last but not least example based on research “Turning your BMC into a revolving door” presented by French researchers Fabien Perigaud, Alexandre Gazet and Joffrey Czarny at ZeroNights conference last year. Board Management Controller (BMC) is part of any server platform where it provides capabilities to communicate and update UEFI firmware directly by access to SPI flash. It’s also cross security boundaries where authentication for BIOS update now equal to the strength of BMC admin user password or BMC firmware update verification routine. This point significantly changes the threat model but in reality not frequently considered as:

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, I can see only one hardware company created a serious shift from 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 not separate. In my opinion, it’s the right direction Apple, keep going (kudos to Ivan Krstic and team) ;-)

The second part of Breaking Through Another Side blog series will be about our research related to Embedded Controller (EC). Where Alex Gazet and myself discovered an interesting attack surface from this small microcontroller included in most of the laptops. This will be our story of bypassing security boundaries from another side of the hardware threat model.