The importance of hardening firmware security
It’s no secret that attackers traditionally go after low-hanging fruit when hacking a system. Historically, this has meant targeting user applications, and, for deeper persistence, the operating system (OS) kernel to gain control. But, as OS security has advanced, it’s become more difficult to compromise an OS with any kind of persistent kernel rootkit.
As a result, hackers (and researchers) have moved below the OS level and are now targeting firmware – most notably the Unified Extensible Firmware Interface or UEFI (often still referred to as the Basic Input Output System or “BIOS”).
You may recall the days when BIOS flashed across a laptop or desktop startup screen. Legacy BIOS was (and in some rare cases still is) one of the first firmware codes to run on a platform, enumerating all of the device’s available components, memory, etc., before passing control to the OS. Today, most standard platforms use UEFI, which was designed to overcome many of the performance shortcomings of BIOS. It was developed by Intel, AMD, Microsoft and a variety of other PC manufacturers, and is maintained today by the Unified Extended Firmware Interface Forum.
To date, firmware attacks have been few and far between. The first known BIOS attack, called the Chernobyl Virus, happened in 1998 and was used to erase flash ROM BIOS contents on chipsets. It wasn’t until Black Hat in 2006 that another BIOS vulnerability was demonstrated by researcher John Heasman (elevating privileges and reading physical memory), and then again in 2009 when Alfredo Ortega demonstrated a persistent BIOS infection (inserting malicious code into the decompression routines).
Despite this initial leisurely pace, over the last decade the number of firmware vulnerabilities has increased significantly. While still mostly academic in nature, these threats won’t stay that way forever.
Case in point, LoJax was the first in-the-wild UEFI rootkit identified in 2018 in a campaign from Russian cyber espionage group Fancy Bear. This rootkit allowed the attacker to write a malicious UEFI module into a system’s SPI flash memory that dropped and executed malware on-disk during the boot process. And, let’s not forget the leak of the NSA’s Equation Group APT by the Shadow Brokers, which showed a catalog of attack tools including a BIOS module. The race to identify new vulnerabilities, before criminals do, is vital to protecting businesses and consumers. Once security researchers begin unearthing new threat mediums, hackers quickly follow.
But where are we today when it comes to UEFI/BIOS vulnerabilities?
Over the last several years, System Management Mode (SMM) attacks have been the most common UEFI vulnerability, mainly because SMM interfaces directly with the OS. For example, a common exploit involves installing a kernel-level rootkit in SMM that can reach into the OS. Since SMM operates in a compartmentalized execution mode, the OS is not able to “see” it. This is appealing for attackers because if the OS can’t see inside SMM, then neither can functions like antivirus (AV). If an attacker has an offensive capability that keeps getting flagged by AV, moving it into the firmware’s SMM can cover their tracks. This is a core reason SMM is attractive for attacks.
Furthermore, SMM is also one of the protections used to prohibit users from rewriting some of the UEFI firmware itself. That means if an attacker wanted to write and install a persistent rootkit into the firmware that could survive OS reinstalls and configuration – or the removal and replacement of a hard drive from a computer – a SMM attack could be the first step in accomplishing that task.
Misconfigurations are another big area of concern when it comes to UEFI vulnerabilities. Traditionally, reference code is passed from a chip manufacturer to other vendors and OEMs, but it’s not intended to be final production code. OEMs then layer on additional coding. During that process it’s possible to create vulnerabilities by not following UEFI security guidelines, creating poor add-on code, or just by accidentally misconfiguring bits. In general, it’s pretty simple for a hacker to scan through system registers and find what’s been misconfigured.
There are hundreds of different bits that need to be properly configured before a system is ready for release. One example of a common misconfiguration vulnerability involves the flash protection bits, which prevent unauthorized modification of firmware. Here’s how it works.
To protect itself from malicious changes, firmware must clear the “BIOS Write Enable” bit to disable firmware modifications. Unfortunately, an attacker could simply set that bit themselves. So to protect it, firmware must set the “BIOS Lock Enable” bit. However, attackers have found ways to circumvent this bit by disabling internal processor events. To secure the system further, firmware must ensure that the necessary events are enabled by setting the “Global SMI Enable” bit, and that an attacker can’t modify this bit by setting the “SMI Lock” bit. It’s easy to see why security misconfiguration vulnerabilities are some of the most common problems encountered.
While SMM and misconfigurations are the two most common UEFI vulnerabilities, there are others including those that require exact configurations for sleep mode and secure boot.
What’s being done to harden the firmware layer?
Now more than ever, the industry is investing in offensive security research and development. By finding problems before hackers do, vendors can work to mitigate these threats before they impact businesses and users. In fact, advancements have already been made to substantially reduce some of the most common firmware attacks. For example, Intel’s Excite project combines symbolic execution, fuzzing, and concrete testing in a single tool that helps automate the excavation of UEFI security vulnerabilities in SMM. System Management Interrupt call-out vulnerabilities, which trick trusted SMM code into executing code from an attacker, were once one of the most common firmware vulnerabilities. Now they are virtually non-existent.
Intel researchers are also working in the area of firmware taint analysis, using automated tools to identify where attackers might provide malicious firmware input, and then tracing the data flow forward, to identify code that could be “tainted” by an attacker. And then there’s Host-Based Firmware Analyzer (HBFA), an open source, automated tool designed to enable developers to conduct advanced testing on UEFI drivers and UEFI Platform Initialization (PI) drivers in an OS environment.
Despite these efforts, there will always be firmware bugs. Recognizing this, researchers are developing firmware hardening technologies for UEFI that will severely restrict what an attacker can do, even if they get code execution inside firmware. For example, new technologies are mitigating the impacts of SMM attacks by preventing arbitrary code execution inside of SMM and allowing the operating system to verify the state of SMM through secure attestation techniques.
When it comes to tackling misconfigurations there are several tools, like the Intel-led open-source Chipsec project, that scan systems for misconfiguration. Chipsec allows OEMs to validate that all system bits within the firmware are configured correctly. Prior to Chipsec, Intel offered a BIOS Writers Guide (and still offers UEFI Writers Guides), that helped vendors and developers properly write, add or configure BIOS/UEFI code. Using sophisticated automated analysis tools has been a huge leap forward for firmware security.
UEFI plays a vital role in booting systems securely, but it also offers an enticing attack surface for hackers. Once believed only to be exploitable by nation states, we’ve seen new research and attacks shift perceptions around processor firmware vulnerabilities. The ultimate goal with UEFI security is to eliminate the “whack-a-mole” approach and get in front of these threats. Only by continuing to invest in offensive security practices and research, developing new automated technologies, and better communicating with partner ecosystems, will the industry ensure those barriers of entry for hackers remain strong.
Contributing author: Burzin Daruwala, Security Research Manager, Intel.