How UEFI Secure Boot works-Knew everything by Blackhat Pakistan 2023

Security products nowadays tend to focus on threats that operate at the high levels of the software stack UEFI, and they achieve reasonably good results. However, this leaves them unable to see what’s going on in the dark waters of firmware. If an attacker has already gained privileged access to the system and installed a firmware implant, these products are useless.

 Very few security products examine firmware, and those that do only do so from the operating system level, detecting the presence of implants only after they’ve successfully installed and compromised the system. More complex implants can also use their privileged position in the system to avoid detection and subvert OS-level security products.

Related Article about UEFI:UEFI Firmware Vulnerabilities by Blackhat Pakistan 2023

For these reasons, firmware rootkits and implants are one of the most dangerous threats to PCs, and they pose an even bigger threat they pose to modern cloud platforms, where a single misconfigured or compromised guest operating system endangers all other guests, exposing their memory to malicious manipulation.

 Detecting firmware anomalies is a difficult technical challenge for many reasons. The UEFI firmware codebases provided by various vendors are all different, and the existing methods of detecting anomalies aren’t effective in every case. Attackers can also use both the false positives and false negatives of a detection scheme to their advantage, and they can even take over the interfaces that OS-level detection algorithms use to access and examine the firmware.

 The only viable way to protect against firmware rootkits is to prevent their installation. Detection and other mitigations don’t work; instead, we have to block the possible infection vectors. Solutions for detecting or preventing firmware threats work only when the developer has full control over both the software and hardware stacks, like Apple or Microsoft does. Thirdparty solutions will always have blind spots.

In this chapter, we’ll outline most of the known vulnerabilities and exploitation vectors used for infecting UEFI firmware. We’ll first examine the vulnerable firmware, classify types of firmware weaknesses and vulnerabilities, and analyze existing firmware security measures. We will then describe vulnerabilities in Intel Boot Guard, SMM modules, the S3 Boot Script, and the Intel Management Engine.

What Makes Firmware Vulnerable?

We’ll begin by going over the specific firmware that attackers could target with a malicious update. Updates are the most effective method of infection.

 Vendors will typically describe UEFI firmware updates broadly as BIOS updates, because the BIOS is the main firmware included, but a typical update also delivers many other kinds of embedded firmware to the various hardware units inside the motherboard, or even the CPU.

A compromised BIOS update destroys the integrity guarantees for all other firmware updates managed by the BIOS (some of these updates, like Intel microcode, have additional authentication methods and don’t rely solely on the BIOS), so any vulnerability that bypasses authentication for a BIOS update image also opens the door for the delivery of malicious rootkits or implants to any of these units.

Figure 16-1 shows the typical firmware units managed by the BIOS, all of which are susceptible to malicious BIOS updates.

Here are brief descriptions of each type of firmware:

Power Management Unit (PMU) A microcontroller that controls the power functions and transitions of a PC between different power states, such as sleep and hibernate. It contains its own firmware and a lowpower processor.

Intel Embedded Controller (EC) A microcontroller that is always on. It supports multiple features, such as turning the computer on and off, processing signals from the keyboard, calculating thermal measurements, and controlling the fan. It communicates with the main CPU over ACPI, SMBus, or shared memory. The EC, along with the Intel Management Engine described shortly, can function as a security root of trust when the System Management Mode is compromised. The Intel BIOS Guard technology (vendor-specific implementations), for example, uses the EC to control the read/write access to SPI flash.

Intel Integrated Sensor Hub (ISH) A microcontroller responsible for sensors, such as device rotation detectors and automatic backlight adjustors. It can also be responsible for some low-power sleep states for those sensors.

Also read about UEFI:UEFI Boot vs. the MBR/VBR Boot Process-byBlackhat Pakistan 2023

Classifying UEFI Firmware Vulnerabilities

 Before digging into the vulnerabilities, let’s classify the kinds of security flaws a BIOS implant installation might target. All the classes of vulnerabilities shown in Figure 16-2 can help an attacker violate security boundaries and install persistent implants.

Intel researchers first attempted to classify UEFI firmware vulnerabilities according to the potential impact of an attack on that vulnerability. They presented their classifications at Black Hat USA 2017 in Las Vegas in their talk “Firmware Is the New Black—Analyzing Past Three Years of BIOS/UEFI Security Vulnerabilities” (https://www.youtube.com/watch?v=SeZO5AYsBCw), which covered different classes of security issues as well as some mitigations. One of its most important contributions is the statistics on the growth in the total number of security issues processed by Intel PSIRT.

Post-Exploitation Vulnerabilities

 Post-exploitation vulnerabilities are usually used as the second stage in delivering malicious payloads (this exploitation scheme is explained in Chapter 15). This is the main category of vulnerabilities that attackers take advantage of to install both persistent and non-persistent implants after they’ve successfully exploited previous stages of attack. The following are the classes for the main implants, exploits, and vulnerabilities in this category.

Compromised Supply Chain Vulnerabilities

 Compromised supply chain attacks take advantage of mistakes made by the BIOS development team or the OEM hardware vendor, or they involve deliberate misconfigurations of the target software that provide attackers with a deniable bypass of the platform’s security features.

In supply chain attacks, an attacker gets access to the hardware during its production and manufacturing processes and injects malicious modifications to the firmware or installs malicious peripheral devices before the hardware ever gets to the consumer. Supply chain attacks can also happen remotely, as when an attacker gains access to the firmware developer’s internal network (or sometimes a vendor website) and delivers malicious modifications directly into the source code repository or build server.

     Supply chain attacks with physical access involve covertly meddling with the target platform, and they sometimes have similarities with evil maid attacks, when attackers have physical access for a limited time during which they exploit a supply chain vulnerability. These attacks take advantage of situations in which the hardware’s owner can’t monitor physical access to the hardware—such as when the owner leaves a laptop in a checked bag, surrenders it for a foreign customs inspection, or simply forgets it in a hotel room. An attacker can use these opportunities to misconfigure hardware and firmware to deliver BIOS implants or just physically flash malicious firmware to the SPI flash chip.

Supply Chain Vulnerability Mitigation

 It’s very hard to mitigate risks related to supply chains without making radical changes to the development and production lifecycles. The typical production client or server platform includes a lot of third-party components, in both software and hardware. Most companies that don’t own their full production cycle don’t care too much about security, nor can they really afford to.

The situation is exacerbated by the general lack of information and resources related to BIOS security configuration and to chipset configuration. The NIST 800-147 (“BIOS Protection Guidelines”) and NIST 800-147B (“BIOS Protection Guidelines for Servers”) publications serve as a useful starting point but are quickly becoming outdated since their initial release in 2011 and update for servers in 2014.

A History of UEFI Firmware Protections

 In this section, we’ll go over some classes of vulnerabilities that allow an attacker to bypass Secure Boot; we’ll discuss specific Secure Boot implementation details in the next chapter.

 Previously, any security issue that allowed the attacker to execute code in the SMM environment could bypass Secure Boot. Though some modern hardware platforms, even with recent hardware updates, are still vulnerable to SMM-based Secure Boot attacks, most enterprise vendors have shifted to using the newest Intel security features, which make these attacks harder. Today’s Intel technologies, such as Intel Boot Guard and BIOS Guard (both of which will be discussed later in this chapter), move the boot process’s root of trust from SMM to a more secure environment: the Intel ME firmware/hardware.

How BIOS Protections Work

 Figure 16-3 shows a high-level view of the technologies used to protect persistent SPI flash storage. The SMM was originally allowed both read and write access to SPI flash storage as a means of implementing routine BIOS updates. This meant the integrity of the BIOS was dependent on the code quality of any code running in the SMM, as any such code would be able to modify the BIOS in the SPI storage. The security boundary was therefore as weak as the weakest code ever run in SMM that had access to the memory region outside of it. As a result, platform developers took steps to separate BIOS updates from the rest of the SMM functionality, introducing a series of additional security controls, such as Intel BIOS Guard.

AMT Vulnerabilities

Intel’s AMT platform is implemented as an ME application and so directly relates to the Intel ME execution environment. AMT leverages the ME’s ability to communicate with a platform over a network even when the main CPU is not active or is completely powered down. It also uses the ME to read and write DRAM at runtime, independently of the main CPU. AMT is an archetypical example of an ME firmware application that is intended to be updated via the BIOS update mechanism. For this purpose, Intel AMT runs its own web server, used as the main entry point for an enterprise remote management console.

 In 2017, after nearly two decades of having a clean public security record, AMT had its first vulnerability reported—but it was a shocking one, and, given its nature, hardly the last one we’ll see! Researchers from Embedi (a private security company) alerted Intel about the critical issue CVE-2017-5689 (INTEL-SA-00075), which allowed for remote access and authentication bypass. All Intel systems produced since 2008 and that support the ME are affected. (This excludes the sizable Intel Atom population, which itself did not include the ME, although all of its server and workstation products were likely vulnerable if they included vulnerable components of the ME. Officially, only Intel vPro systems have AMT.) The scope of this vulnerability is pretty interesting, as it mostly affected systems designed to be accessed via a remote AMT management console even when turned off—meaning that the system could also be attacked when turned off.

Typically, AMT was marketed as a part of the Intel vPro technology, but in the same presentation, Embedi researchers demonstrated that AMT could be enabled for non-vPro systems. They released the AMTactivator tool, which an operating system administrator could run to activate AMT even when it was not officially a part of the platform. The researchers showed that AMT was a part of all current Intel CPUs powered by the ME, no matter whether they were marketed as vPro-enabled or not; in the latter case, AMT was still present and could be activated, for good or bad.

BMC Chip Vulnerabilities

 At the same time that Intel was developing vPro offerings powered by the AMT platform’s ME execution environments, other vendors were busy developing competing centralized remote management solutions for servers:

BMC chips integrated into the servers. As products of this parallel evolution, BMC designs have a lot of the same weaknesses as AMT.

Commonly found in server hardware, BMC deployments are ubiquitous in data centers. Major hardware vendors like Intel, Dell, and HP have their own BMC implementations, based primarily on ARM microcontrollers with integrated network interfaces and flash storage. This dedicated flash storage contains a real-time OS (RTOS) that powers a number of applications, such as a web server listening on the BMC chip’s network interface (a separate network management interface).

 If you’ve been reading attentively, this should scream “attack surface!” Indeed, a BMC’s embedded web server is typically written in C (including CGI) and is thus a prime target for attackers in the market for inputhandling vulnerabilities. A good example of such a vulnerability is HP iLO BMC’s CVE-2017-12542, which allowed an authentication bypass and remote code execution in the respective BMC’s web server. This security issue was discovered by Airbus researchers Fabien Périgaud, Alexandre Gazet, and Joffrey Czarny. We highly recommend their detailed whitepaper “Subverting Your Server Through Its BMC: The HPE iLO4 Case” (https:// bit.ly/2HxeCUS).

BMC vulnerabilities underscore the fact that, no matter what hardware separation techniques you employ, the overall measure of a platform’s attack surface is its communication boundary. The more functionality you expose at this boundary, the greater the risk to the platform’s overall security. A platform may feature a separate CPU with a separate firmware running on it, but if this firmware includes a rich target, such as a web server, the attacker can leverage the platform’s weaknesses to install an implant. For example, a BMC-based firmware update process that does not authenticate over-the-network update images is just as vulnerable as any security-throughobscurity software installation scheme.

Conclusion

The trustworthiness of UEFI firmware and other system firmware for x86- based platforms is a hot topic today, worthy of an entire book of its own. In a sense, UEFI was meant to reinvent the BIOS, but it did so with all the failings of security-by-obscurity approaches of the legacy BIOS, plus a lot more.

We made some hard decisions about which vulnerabilities to include here and which to give more detailed coverage to in order to illustrate the larger architectural failings. In the end, we hope that this chapter has covered just enough background to give you a deeper understanding of the current state of UEFI firmware security through the prism of common design flaws, rather than merely regaling you with a hodgepodge of infamous vulnerabilities.

Nowadays UEFI firmware is the cornerstone of platform security, despite being universally neglected by vendors a few years ago. The collaborative effort of the security research community made this change possible—and we hope that our book gives it its due and helps further its progress.