[BreachExchange] The importance of hardening firmware security

[Destry Winant]

https://www.helpnetsecurity.com/2019/07/17/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.