Changing The Cat and Mouse Game of Firmware Attacks

By George Wainblat

Fixing Firmware Security Flaws

One of the noiseless yet foundational transitions in computing during the last decade has occurred in the firmware used to perform functions like hardware initialization during boot and runtime services during regular OS operation. As the usability and performance of generations of firmware raced ahead, their security often lagged, leaving the firmware world too slow for the threats it faces. Hackers have taken notice and escalated their attacks in both frequency and sophistication. The National Institute of Standards and Technology’s (NIST) National Vulnerability Database (NVD) shows that attacks on firmware have risen by 500% since 2018. There is no time to waste in developing security solutions that protect at the firmware level and above. Microsoft has reported that 83% of enterprise IT decision-makers have had their systems hit with a firmware attack in the last two years but that only 29% of the average security budget is dedicated to protecting the firmware level. And as an example of how much damage this can cause, McKinsey data has shown that a single medical device recall due to an unaddressed vulnerability such as firmware threats, can cost up to $600 million USD, thus require better hardware and firmware security features. This is unsustainable. A new solution is necessary to end this cat and mouse game altogether.

Security by Obscurity Does not Work

With IT security and visibility efforts still largely focused higher in the stack at the application layer, bad actors tend to seek easier ways to exploit systems vulnerabilities, which push them further down the stack to the firmware level. Unlike the common misconception about firmware hacking complexity, today hackers are already selling tools to hide malware in firmware devices, such as GPUs.
Once inside the firmware, hackers can disable remote firmware updates, making it impossible to fix remotely and thus requiring the service of a technician with physical access to the firmware, often requiring a complete shutdown and an on-site visit that can be quite costly for large-scale deployments. This process means fixing zero-day hacks in firmware or hardware can be incredibly time-consuming, leaving the system in question vulnerable for longer than a software breach would. These factors have contributed to a rise in firmware attack frequency both from state-sponsored actors and from smaller and less well-resourced but still dangerous private groups.

Firmware threats have found success from the very start

Pioneered in 1975 by IBM, BIOS, which stands for basic input/output system, refers to the physical chip on which CPUs run their firmware. The name legacy BIOS is used to refer to the original firmware running on that physical BIOS component. This legacy firmware is used to perform hardware initialization during the booting process (power-on startup) and to provide runtime services for OS and programs. BIOS firmware was initially stored on the BIOS chip on the motherboard but was later moved to the flash memory so it could be rewritten without removing a chip from the motherboard. This allowed for easy end-user updates to BIOS for adding new features or troubleshooting. This ease of access and alterability by end-users was popular but it also made BIOS vulnerable to Bootkits. On top of that, it opened the door for attackers to issue malicious updates to the BIOS or to brick a motherboard entirely, intentionally or otherwise.

These vulnerabilities were exploited by BIOS threats like WinCIH, ACPI rootkit, Icelord rootkit, Mebromi, and Rakshasa, many of which rose to prominence in the late 90’s. Several of these attacks worked by preventing infected computers from booting, taking advantage of the fact that widespread OSs at the time allowed direct hardware access for all programs. Modern systems do not allow users direct hardware access so many of these early generation threats grew obsolete. That said, BIOS attacks are prevalent enough that a significant transitional improvement in firmware security was necessary.

Within the last decade or so, engineers began designing devices that swapped out the BIOS firmware for Unified Extensible Firmware Interface (UEFI) firmware that replaces the runtime interface of BIOS and addresses technical limitations by quickening speed of startup and shutdown, improving the interface, and supporting larger hard drives. UEFI firmware improved networking and remote troubleshooting and configuration but perhaps its most important security feature was the introduction of the Secure Boot concept to the world, a priority given one of the primary strategies that BIOS attacks utilized was to corrupt the boot process. To give a brief description of Secure Boot, when a system turns on, it locates an operating system bootloader. Without Secure Boot, it will just use whatever boot firmware is there without any sort of verification of whether that bootloader or preceding firmware should be trusted. The Secure Boot protocol of UEFI ensures that a bootloader was signed by a trusted certificate before starting it.

Though the Secure Boot enabled by UEFI firmware offered an improvement over what legacy BIOS firmware was able to deliver, weaknesses remain. Hackers have discovered that if they could gain access into the UEFI firmware, they would subsequently be able to corrupt trusted platform measurements (TPMs) used for remote attestation purposes, since these platforms relied on the UEFI firmware that enabled Secure Boot in the first place. In simpler terms, because hackers could access the location hosting the UEFI firmware, everything that relied on that UEFI firmware was subject to compromise.

A recent example of a piece of “in-the-wild” malware that specifically targets the UEFI firmware in this way is called “Lojax,” which works by infiltrating the LoJack anti-theft tracking software.

Breaches into firmware like the Lojax malware are significant more difficult to detect and resolve from higher layers in the stack. Not only do application-layer tools provide inadequate visibility and response tools for acting against firmware attacks to begin with, but once inside the firmware, attackers can disable these tools once they establish persistency and achieve control of every aspect of the system firmware and software levels alike. From there, they can then seize data or even infect other devices operating on the same network. For example, a very recent discovery of BIOS flaws in Intel Processors, are tracked as CVE-2021-0157 and CVE-2021-0158, and both have a CVSS v3 score of 8.2 (high). Allows attackers running with OS-level privileges, to trigger corruption of memory and eventually install a BIOS-level implant. Again, such things are particularly problematic because motherboard vendors do not release BIOS updates so often and do not offer long time support for their products.

Software or firmware only solutions aren’t an adequate fix either by the way, as evidenced by the 2019 exploitation of Surface Pro 3 convertible laptops and the Device Health Attestation (DHA) feature Microsoft introduced to validate BIOS, TPM, and Secure Boot. Devices like the Surface store measurements from Platform Configuration Registers (PCRs) in a bank for health and attestation checks by the DHA. However, according to in Microsoft’s vulnerability report, certain devices booted with certain firmware do not feature any measurements  of their PCR banks, which means if crafty hackers can acquire a legitimate TCG log from a similar device, they can use it to enter copied measurements into the PCR bank of their target device and use those measurements to fetch legitimate DHA certificates. This vulnerability exists because it checks against a software source for authorization, but software is accessible and therefore alterable. Even more “physical” non-traditional compute devices such as ATMs have been suffering from the same problems. In a recent study, Diebold Nixdorf ATMs were found to be susceptible to firmware hacking that resulted in possible cash withdrawals. Although deploying firmware encrypted updates (where the firmware code should be kept concealed from anyone but the vendor and the device CPU) and TPM counter measures, the attackers were able to alter the device firmware.

These sorts of firmware and software attacks are on the rise. Petya, NotPetya and other variations of destructive ransomware attacks are nothing new. According to Kaspersky Advanced Threat Predictions for 2022, there will be an explosion of low-level attacks and attackers will return to using Bootkit implants. Such prediction suggests we might be returning to the surge of firmware malware as seen in the late 90’s. IT decision-makers must address this glaring vulnerability by moving the crown jewels off the firmware to somewhere attackers cannot reach – or even see.

Transitioning to an Isolated Security Processor

To secure firmware against ever more ambitious and creative attackers, a Root of Trust (RoT) is necessary as an entity against which to check every layer of the stack from hardware boot to firmware load, OS runtime up until the running applications. The only way for a computing component to be trustworthy in this way is for it to be immutable, a condition that eliminates any sort of software solution as an option. A hardware solution is therefore necessitated, often involving storing crypto keys that tie directly to the device owner who provisioned the keys in the silicon of a machine rather than in its software in an isolated implementation. Novel solutions take things a step further by offloading the RoT to a separate security processing unit (SPU) chip entirely to enable remote attestation for all motherboard components but also any peripheral device connected to the system.

The Open Compute Project advocates for the hardware RoT in the open standard version 1.0 of their RoT specification. This formal specification is important because in addition to protecting against firmware persistency attacks, it also helps firmware developers understand how to develop more secure firmware with fewer vulnerabilities, though these learnings can be difficult to implement. Standardization helps vendors create interoperable solutions as well.

The issue with establishing a RoT on a system’s hardware, or on an isolated security processor, is that by design they are very difficult to access or affect. This makes them more secure against bad actors but leaves them less flexible when new vulnerabilities are found, or new functions are required. This is where field-programmable gate arrays (FPGAs) can enter the picture. An FPGA is a semiconductor device separate from the processor that is configurable after manufacturing, which this allows programmers to adjust how components of their larger system are structured without sizable financial or temporal burdens that would otherwise be necessary.

All told, what CIOs, CISOs, and IT decision-makers need to realize is that their systems are very much vulnerable – especially at the firmware level. Attacks targeting this level are escalating in severity and sophistication so what is needed is a hardware root of trust which can be used to authenticate and authorize any alteration of any stack level while remaining flexible enough to adapt to new vulnerabilities and enable security applications. Firmware attacks will only increase as hackers grow more ambitious – it’s long past time everyone did something about it.

Tags in this post