Staying ahead of rising firmware attacks - Embedded.com

Staying ahead of rising firmware attacks

Advertisement

With IT security and visibility efforts still largely focused on the application layer, bad actors tend to seek easier ways to exploit system vulnerabilities, moving down the stack to the firmware level.

A quiet yet foundational transition in computing has occurred over the past decade 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 ill-prepared to counter evolving threats.

Hackers have taken notice and escalated their attacks in both frequency and sophistication. The National Vulnerability Database maintained by the U.S. National Institute of Standards and Technology (NIST) shows that attacks on firmware have risen by 500% since 2018. A Microsoft-commissioned study found that 83% of enterprise IT decision-makers have had their systems hit with a firmware attack in the past 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 & Company data shows that a single medical device recall to correct an unaddressed vulnerability, such as firmware threats, can cost up to US$600 million.

This is unsustainable. A new solution is necessary to end this cat-and-mouse game altogether, and soon.

Security by obscurity does not work

With IT security and visibility efforts still largely focused on the application layer, bad actors tend to seek easier ways to exploit system vulnerabilities, moving down the stack to the firmware level. Contrary to common misconceptions about the complexities of firmware hacking, 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 the problem remotely and thus requiring the service of a technician with physical access to the firmware. That often requires a complete shutdown and an on-site service visit that can be quite costly for large-scale deployments. 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 term “legacy BIOS” refers to the original firmware running on that physical BIOS component. This legacy firmware is used to perform hardware initialization during the boot process (power-on startup) and to provide runtime services for operating systems 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 the BIOS chip from the board. This enabled easy, end-user–initiated BIOS updates for adding features or troubleshooting, but the ease of access and alterability that made it popular with end users also made BIOS vulnerable to bootkits. On top of that, it opened the door for attackers to issue malicious BIOS updates 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 1990s. Several of these attacks worked by preventing infected computers from booting, taking advantage of the fact that OSes in wide use 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, which replaces the BIOS runtime interface and addresses technical limitations by quickening the speed of startup and shutdown, improving the interface, and supporting larger hard drives. UEFI firmware improved networking and remote troubleshooting and configuration. Given that a primary BIOS attack strategy at the time was to corrupt the boot process, however, perhaps UEFI’s most important security feature was its introduction of the Secure Boot concept to the world.

In essence, when a system with Secure Boot turns on, it locates an operating system bootloader. Without Secure Boot, it will just use whatever boot firmware is present, without first verifying 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 discovered that if they could get into the UEFI firmware, they would subsequently be able to corrupt trusted platform measurements (TPMs) used for remote attestation purposes, as those 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 Lojax, which works by infiltrating the LoJack anti-theft tracking software.

Breaches into firmware like the Lojax malware are significantly 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 after they establish persistency and achieve control of every aspect of the system firmware and software levels alike. From there, they can seize data or even infect other devices operating on the same network.

For example, a very recent discovery of BIOS flaws in Intel processors is tracked as CVE-2021-0157 and CVE-2021-0158, and both have a CVSS v3 score of 8.2 (high). This allows attackers running with OS-level privileges to trigger corruption of memory and eventually install a BIOS-level implant. Again, such attacks are particularly problematic because motherboard vendors do not release BIOS updates often enough to keep up with them, and thus, there is no long-time support for these products.

Software- or firmware-only solutions aren’t an adequate fix either, as evidenced by the 2019 exploitation of Surface Pro 3 convertible laptops and the Device Health Attestation (DHA) feature that 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 Microsoft’s vulnerability report, certain devices booted with certain firmware do not provide any measurements of their PCR banks, so a crafty hacker who acquires a legitimate TCG log from a similar device can use it to enter copied measurements into the PCR bank of the target device and then 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” devices, such as ATMs, have proved vulnerable to the same problems. In a recent study, Diebold Nixdorf ATMs were found to be susceptible to firmware hacking that resulted in possible cash withdrawals. Despite deployment of firmware-encrypted updates (where the firmware code should be kept concealed from anyone but the vendor and the device CPU) and TPM countermeasures, 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 a prediction suggests that we might be returning to the surge of firmware malware seen in the late ’90s.

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 to 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 necessary, often involving storing crypto keys (tied directly to the device owner who provisioned them) in the silicon of a machine rather than in its software in an isolated implementation. Novel solutions go a step further by offloading the RoT to a separate security-processing–unit chip entirely, to enable remote attestation not only for all motherboard components but also for any peripheral device connected to the system.

The Open Compute Project advocates for the hardware RoT in the open-standard version 1.0 of its RoT specification. This formal specification is important because, in addition to protecting against firmware persistency attacks, it 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 an 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 also renders them less flexible when new vulnerabilities are found or new functions are required. This is where field-programmable gate arrays can enter the picture. Because it is configurable after manufacturing, an FPGA allows programmers to adjust how components of their larger system are structured without assuming the sizable financial or temporal burdens that would otherwise be necessary.

CIOs, CISOs, and IT decision-makers must realize that their systems are highly vulnerable, especially at the firmware level, where attacks continue to escalate. Fending off such attacks requires 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 that everyone did something about it.

>> This article was originally published on our sister site, EE Times Europe.


Aviram Shemesh is vice president for security research at Kameleon Security.

Related Contents:

For more Embedded, subscribe to Embedded’s weekly email newsletter.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.