Firmware security has undergone an incredible transformation over the past several years. What was once an often forgotten and overlooked part of the technology stack has become one of the most active battlegrounds between cybersecurity attackers and defenders. And at a high level, it is easy to see why. Firmware is where the stakes are highest. It is the most fundamental and first code to run, and if compromised, can allow an attacker to subvert everything that runs in the layers above. As the industry increasingly thinks of security from “chip to cloud,” the chip (and the firmware running in that chip) is the bedrock on which everything else is built.
And as adversaries ranging from APT groups to ransomware operators have turned their attention to firmware, it has required security researchers and technology vendors to pull together to continuously improve the firmware security stack. We are very proud to have played a key role in this evolution, both as researchers dedicated to finding weaknesses and vulnerabilities before the bad actors do, and as a 3rd-party security vendor who gives organizations the tools to proactively defend their devices and secure their supply chains.
One of the most satisfying aspects has been seeing how our research and collaboration with industry-leading OS vendors, chipset manufacturers, and OEMs have helped to improve the overall state of firmware security. Naturally, as a leading OS and technology vendor, Microsoft is highly invested in ensuring the integrity of a device’s boot process, and over the years has spearheaded many initiatives including the introduction of Secure Boot in Windows 8 and the industry collaboration to deliver Secured-core PCs, Microsoft has become highly proactive about defending the integrity of firmware and the boot process. As we get ready to release our latest research at DEFCON we thought it would be a good chance to look back at how Eclypsium research has both directly and sometimes indirectly helped to drive this evolution. Let’s take a look.
UEFI Vulnerabilities and Mitigations (2011+)
For over a decade, most PCs have moved to a common firmware standard called the Unified Extensible Firmware Interface (UEFI). Tianocore/EDK2 is a common, open-source implementation of UEFI used throughout the industry. While at Intel, Eclypsium founders and researchers have pored over this code, finding a wide range of vulnerabilities that affect many of the devices which derive their firmware from this reference code. For additional reading, this presentation from the REcon conference provides a good summary on a variety of UEFI vulnerabilities. Microsoft built on EDK2 to deliver Project Mu aimed at improving the security of UEFI for Microsoft systems (e.g. Surface). The goal was to not only deliver more secure UEFI code, but also to make it easier for ecosystem partners to collaborate and to more easily service firmware across different types of products.
Secure Boot Bypass (2013)
Microsoft first introduced Secure Boot over a decade ago with the release of Windows 8 in 2012. Prior to the release of Secure Boot, devices were relatively defenseless against bootkits, which allowed attackers to insert malicious code within UEFI components in order to take control of the device’s boot process. Secure Boot was meant to prevent this by ensuring that all code related to the boot was valid, signed, and unaltered.
However, things proved to be a little trickier in the real world. Future Eclypsium founders Yuriy Bulygin and Alex Bazhaniuk showed exactly how things were going awry in the presentation at Black Hat USA 2013 (PDF of presentation). The challenge was that Secure Boot was only secure when all BIOS and platform vendors did a few very important things correctly. The presentation demonstrated a variety of ways that Secure Boot could be bypassed and underscored a variety of best practices for OEM vendors that were essential to ensure Secure Boot actually worked as designed. This research not only helped to identify issues that made Secure Boot itself stronger, it also put a spotlight on the need to foster stronger partnerships between BIOS/OS vendors and OEMs to ensure Secure Boot actually was living up to its potential.
The Drive to Secured-core PCs
Over the years, Microsoft has introduced a variety of capabilities designed to improve the security of devices at their most fundamental levels. Examples include System Management Mode (SMM) risk mitigations and Virtualization-based security (VBS).
SMM provides a firmware-driven runtime capability that runs beneath the operating system. Using interrupts (SMIs), SMM can halt the operating system and execute actions without the higher-level OS even knowing about it. Vulnerabilities in this area, as shown in the research, could give attackers incredibly powerful control over a device while remaining completely invisible to the OS. In 2015, Yuriy, Alex, and future Eclypsium researchers Mickey Shaktov and John Loucaides presented at CanSec West, disclosing a new class of vulnerabilities affecting SMM that would allow an attacker to gain control of the device.
VBS was Microsoft’s next enhancement, which used the Windows hypervisor to protect critical OS and system components. While VBS is a big topic, one of the key aspects is that it separates the OS and kernel into two virtual machines, one a normal version called VTL0 and a second more secure VM (VTL1) dedicated to protecting critical kernel resources and system secrets such as credentials. The idea is that if an attacker or malware were able to compromise the normal user side of the OS, the attacker shouldn’t be able to gain control of the secure kernel or steal secrets.
However, in 2017 Yuriy and Alex were back at it at Black Hat, showing how weaknesses in VBS could allow an attacker with a presence in the normal side of OS could gain control over the secure side by attacking firmware. At the heart of the issue, the normal VTL0 virtual machine had full access to the system’s firmware. And this meant that if the underlying firmware was vulnerable, an attacker could gain control of firmware and use it to gain control of the secure kernel and trustlets.
What does this have to do with Secured-core? Secured-core is a Microsoft initiative that brings together a combination of protections working together including Secure Boot, System Management Mode (SMM) attack mitigation mechanisms to isolate and deprivilege System Management Interrupt (SMI) handlers, Trusted Platform Module (TPM), Dynamic Root of Trust for Measurement (DRTM), Memory Access Protection, and Hypervisor Code Integrity (HVCI). If that seems like a lot, it’s because it is, and research in all of these areas has shown that while valuable, none are a silver bullet on their own. Secured-core was a suite of technologies designed to help ensure that devices were properly taking advantage of all of these available protections. Microsoft has defined what constitutes a Secured-core PC, and OEMs leverage this technology by offering their own branded Secured-core or SecureCore devices. And while Secured-core is a big step forward, it too is not a silver bullet. The complexity of all the components means there are many ways that OEMs can make mistakes or that key components can be misconfigured either in the supply chain or after delivery. Also, as subsequent Eclypsium research has shown, new vulnerabilities and flaws can allow attackers to gain control over firmware and the boot process even on the very latest Secured-core PCs.
BootHole Vulnerability Drives Changes in Bootloader Security
Almost exactly two years ago, Eclypsium researchers Mickey Shaktov and Jesse Michael published the details of the incredibly far-reaching BootHole vulnerability. The vulnerability was tied to a flaw in GRUB2 and allowed an attacker to gain code execution during the boot process even when Secure Boot was enabled. However, the problem was not limited only to devices that used GRUB2. Due to the way Secure Boot works, any device that used the standard Microsoft Third-Party UEFI Certificate Authority would also trust the vulnerable boot loader and could be compromised by an attacker.
This triggered a mass revocation event in which devices needed to receive new bootloaders and needed to update their DB and DBX databases in order to no longer trust the outdated, vulnerable bootloaders. This event highlighted the industry-wide need for a much better process for revoking UEFI shim bootloaders. As a result, Microsoft collaborated with partners to implement a variety of improvements, including UEFI Secure Boot Advanced Targeting (SBAT) to improve the efficiency of shim revocation.
Additionally, BootHole seemed to accelerate additional research into vulnerable bootloaders. And in response, some OEMs are disabling the Third-Party CA by default, which may be a new Microsoft requirement for Secured-core PCs (see Lenovo PDF). While this would provide protection against vulnerable third-party bootloaders, it would also prevent users from loading other operating systems. We will be presenting new research related to vulnerable and malicious bootloaders at DEF CON 30.
TrickBoot Research Leads OEMs to Patch Common BIOSWE Vulnerability
In late 2020, just after the TrickBot take down attempts by USCC and later by Microsoft out of fears the US Elections technology supply chain would be targeted, Eclypsium researchers analyzed a new TrickBot module (PermaDll) discovered being used ITW (In the Wild). Adv-Intel, who noticed the module was only being used against TrickBot’s HVT’s (High Value Targets), and Eclypsium, published joint research and dubbed this module “TrickBoot”. The module was used by TrickBot actors to determine whether an infected device’s UEFI was vulnerable to a relatively common vulnerability: BIOS Write Protection being disabled. Should the actors then exploit this vulnerability, they were able to embed in the UEFI (or brick it completely, rendering the device indefinitely useless regardless of backups).
This discovery gained a tremendous amount of media attention, helping raise awareness for DFIR teams to make sure they perform forensic analysis on the device firmware itself following any TrickBot infections on critical devices. As a result, certain OEMs including Pulse Secure and SuperMicro, issued out-of-cycle “TrickBoot” patches to address this same BIOS Write Protection vulnerability the actors were targeting. In turn this created even more industry awareness of these low-level vulnerabilities criminal actors have been targeting.
Fast forward to 2022, and the Eclypsium research team performed analysis of the same Conti/Trickbot group’s internal chat leaks, to discover that criminal actors are again actively developing low level attack vectors, to include targeting Intel’s ME /AMT in order to write to the SPI flash and embed there. This would allow them to disable OS level security controls and buy themselves precious time in the kill chain. It would also give them a much broader set of targets that could be attacked via this method, as Intel ME has been around for over a decade on every Intel device made since Intel ME’s introduction. The research highlighted more than 40 Intel ME flaws that have been discovered in the Intel-based IT supply chain that the attackers could leverage in their pursuit. The same developers further discussed a System Management Mode (SMM) implant option, once again echoing tactics discussed during the 2015 CanSec West talk referenced earlier: A topic that will also be discussed at BlackHat in Las Vegas in 2022 by other researchers, once again bringing heavy industry awareness to the impact and reality of these firmware attacks.
Screwed Drivers Research Forces Strong Blocklist Policies for Drivers
In 2019 Eclypsium published two key pieces of research, Screwed Drivers and the following Mother of All Drivers, which put a focus on the risks associated with flawed and vulnerable drivers. These drivers are provided as tools by technology vendors such as Intel, ASUS, Toshiba, and NVIDIA that allow users to manage their hardware and systems. The problem is that flaws in these drivers can allow unprivileged users (or malware running in user space) to modify the Windows kernel or the underlying device firmware. Abuse of such capability can enable an attacker to bypass controls such as signed driver enforcement or exploit vulnerable firmware. And since these drivers were valid tools released by vendors to help manage or update devices, they were properly signed and would be trusted on almost any machine.
At the time, there was no universal mechanism to prevent a Microsoft OS from loading one of these bad drivers. Once again, this and other industry research drove Microsoft to make changes, including the introduction of a driver blocklist capability to Windows 10 and 11.
Key Take-Aways and Looking Forward
These are just a handful of examples of how firmware and device security research have played a driving role in moving the industry forward. It goes without saying that while we have noted our own research as examples here, there is a vast amount of additional great research that has and continues to be done in these areas. And all of this great research would go for naught if there weren’t good industry leaders like Microsoft and Intel doing the critical work to appreciate the research and adapt in order to keep their users and products as safe as possible.
Ultimately, we are all very much working on the same side. Recent history has clearly shown that adversaries are increasingly targeting the most fundamental layers of devices and technology, actively exploiting flaws in our technology supply chain. As technology vendors, researchers, and security vendors, it is our collective responsibility to address this risk proactively, to find and address weaknesses before they can be exploited, and to make the adversaries’ work as difficult and costly as possible. Additionally, as cybersecurity vendors, we play another important role in making sure that defenses are working correctly, all aspects of the firmware attack surface are visible, and that security teams have the ability to proactively detect and respond to the inevitable vulnerabilities and threats. We are proud to have played a key role in this evolution and look forward to continuing to collaborate on industry challenges going forward.
