BIOS/UEFI Forensics:Firmware Acquisition and Analysis Appr0aches

Recent rootkits targeting UEFI firmware have renewed interest in UEFI firmware forensics. Leaks of classified information on state-sponsored BIOS implants, as well as the security breach at Hacking Team mentioned in Chapter 15, have demonstrated the increasingly stealthy and powerful capabilities of malware that targets the BIOS and prompted the research community to dig deeper into firmware. We’ve already discussed some technical details of these BIOS threats in previous chapters. If you haven’t read Chapters 15 and 16, we highly recommend doing so before continuing; those chapters cover important firmware security concepts that we assume you understand for this discussion.

UEFI firmware forensics is currently an emerging area of research, so security researchers working in this field lack conventional tools and approaches. In this chapter, we’ll cover some firmware analysis techniques, including various approaches to firmware acquisition and methods of parsing and extracting useful information.

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

We first focus on acquiring firmware, which is usually the first step of a forensic analysis. We cover both a software and a hardware approach to obtaining a UEFI firmware image. Next, we compare these approaches and discuss the advantages and disadvantages of each. We then discuss the internal structure of the UEFI firmware image and how to parse it in order to extract forensic artifacts. In the context of this discussion, we show you how to use UEFITool, an indispensable open source firmware analysis tool for browsing and modifying UEFI firmware images. Finally, we discuss Chipsec, a tool with very extensive and powerful functionality, and consider its applications for forensics analysis. Both tools were introduced in Chapter 15.

Limitations of Our Forensic Techniques

The material we present here does have some limitations. In modern platforms, there are many types of firmware: UEFI firmware, Intel ME firmware, hard drive controller firmware, and so on. This chapter is dedicated specifically to the analysis of UEFI firmware, which constitutes one of the largest parts of platform firmware.

Note also that firmware is very platform specific; that is, each platform has its own peculiarities. In this chapter, we’ll focus on UEFI firmware for Intel x86 systems, which constitute the majority of desktop, laptop, and server market segments.

Why Firmware Forensics Matter

In Chapter 15, we saw that modern firmware is a convenient place for embedding very powerful backdoors or rootkits, specifically in the BIOS. This type of malware is capable of surviving OS reinstallation or hard drive replacement, and it gives an attacker control over an entire platform. At the time of this writing, most state-of-the-art security software doesn’t take into account UEFI firmware threats at all, making them even more dangerous. This gives an attacker a big opportunity to implant malware that persists undetected on the target system.

 Next, we outline a couple of specific ways attackers might use firmware rootkits.

Related Article:Contemporary UEFI Bootkits by Blackhat Pakistan 2023

 Attacking the Supply Chain

 Threats targeting UEFI firmware increase the risk of supply chain attacks, because attackers can install a malicious implant on a server before it is delivered to the data center or to a laptop before it gets to the IT department. And because these threats can impact a large number of a service provider’s clients by exposing all their secrets, big cloud-computing players like Google have recently started to use firmware forensic analysis techniques to ensure that their firmware isn’t compromised.

Compromising BIOS Through Firmware Vulnerability

Attackers can compromise the platform firmware by exploiting a vulnerability in it to bypass BIOS write protection or authentication. For a refresher on this attack, return to Chapter 16, where we discuss different classes of vulnerabilities used to attack the BIOS. To detect these attacks, you could use the firmware forensic approaches discussed in this chapter to verify the integrity of a platform’s firmware or to help detect malicious firmware modules.

Understanding Firmware Acquisition

 The very first step in BIOS forensic analysis is the process of obtaining an image of the BIOS firmware to analyze. To better understand the location of BIOS firmware on modern platforms, refer to Figure 19-1, which demonstrates the architecture of a typical PC system’s chipset.

 There are two main components in the chipset: a CPU and a Platform Controller Hub (PCH) or South Bridge. The PCH provides a connection between the controllers of peripheral devices available on the platform and the CPU. In most modern systems based on Intel x86 architecture (including 64-bit platforms), the system firmware is located on a flash memory in the Serial Peripheral Interface (SPI) bus u, which is physically connected to the PCH. The SPI flash constitutes the main target for forensic analysis because it stores the firmware we want to analyze.

The motherboard of a PC typically has one discrete physical SPI flash chip soldered onto it, but you might occasionally encounter systems with multiple SPI flash chips. This happens when a single chip doesn’t have enough capacity to store all the system firmware; in that case, the platform vendor uses two chips. We discuss this situation later in this chapter, in “Locating the SPI Flash Memory Chip” on page 376.

To acquire the firmware image stored on the SPI flash, you need to be able to read the contents of the flash. Generally speaking, you can read the firmware using either a software or a hardware approach. In the software approach, you attempt to read the firmware image by communicating with the SPI controller using software running on the host CPU. In the hardware approach, you physically attach a special device called an SPI programmer to the SPI flash, then read the firmware image directly from the SPI flash. We’ll cover both approaches, starting with the software method.

Before we go into the description of the software approach, however, you should understand that each approach has its advantages and limitations. One of the benefits of dumping UEFI firmware using the software method is that you can do it remotely. A user of the target system can run an application to dump the contents of the SPI flash and send it to a forensic analyst. But this approach also has a major drawback: if an attacker has already compromised the system firmware, he or she could interfere with the process of firmware acquisition by forging the data read from the SPI flash. This makes the software approach somewhat unreliable.

The hardware approach doesn’t have the same drawback. Even though you must be physically present and it requires you to open the target system’s chassis, this method directly reads the contents of the powered-off system’s SPI flash without giving the attacker any opportunity to counterfeit the data (unless you’re dealing with a hardware implant, which we don’t cover in this book).

The Software Approach to Firmware Acquisition

In the software approach to dumping UEFI firmware from the target system, you read the contents of the SPI flash from the operating system. You can access modern systems’ SPI controllers through registers in the PCI configuration space (a block of registers that specify device configuration on the PCI bus). These registers are memory mapped, and you can read and write to them using regular memory read and write operations. In this section, we’ll demonstrate how to locate these registers and communicate with the SPI controller.

Before we proceed, you should know that the location of an SPI register is chipset specific, so in order to communicate with an SPI controller, we need to refer to the chipset dedicated to the platform we’re targeting. In this chapter, we’ll demonstrate how to read the SPI flash on chipsets in Intel’s 200 Series (the location of SPI registers can be found at https://www intel.com/content/www/us/en/chipsets/200-series-chipset-pch-datasheet-vol-2.html), which are the latest chipsets for desktop systems at the time of this writing.

It’s also worth mentioning that the memory locations that correspond to the registers exposed via the PCI configuration space are mapped in the kernel-mode address space and, as a result, aren’t accessible to code running in the user-mode address space. You would need to develop a kernelmode driver to access the address range. The Chipsec tool discussed later in this chapter provides its own kernel-mode driver for accessing the PCI configuration space.

Locating PCI Configuration Space Registers

 First we need to locate the memory range where the SPI controller’s registers are mapped. This memory range is called the Root Complex Register Block (RCRB). At offset 3800h in the RCRB, you’ll find the SPI Base Address Register (SPIBAR), which holds the base address of memory-mapped SPI registers (see Figure 19-2).

The Hardware Approach to Firmware Acquisition

To guarantee we have acquired the actual BIOS image stored on the SPI flash and not one already compromised by an attacker, we can use the hardware approach. With this approach, we physically attach a device to the SPI flash memory and read its contents directly. This is the best solution because it’s more trustworthy than the software approach. As an extra benefit, this approach allows us to obtain other firmware stored on the SPI flash, like ME and GBE firmware, which might not be accessible with the software approach due to restrictions enforced by the SPI controller.

 The SPI bus on modern systems allows multiple masters to communicate with the SPI flash. For instance, on systems based on the Intel chipset, there are generally three masters: the host CPU, the Intel ME, and GBE. These three masters have different access rights to different regions of the SPI flash. On most modern platforms, the host CPU can’t read and write to the SPI flash region containing the Intel ME and GBE firmware. Figure 19-7 demonstrates a typical setup for obtaining the BIOS firmware image by reading the SPI flash.

In order to read data from the flash memory, we need an additional device, called an SPI programmer, which we physically attach to the SPI flash memory chip on the target system. We also connect the SPI programmer via a USB or UART interface to a host that we use to obtain the BIOS firmware image. We would then run some particular software on the programmer to make it read data from the flash memory chip and transfer the data to the analyst’s computer. This might be proprietary software provided with a particular SPI programmer, or it could be an open source solution such as the Flashrom tool, which is discussed later in “Reading the SPI Flash with the FT2232 Mini Module” on page 377

Reviewing a Lenovo ThinkPad T540p Case Study

 The hardware approach is even more specific than the software approach. It requires you to consult platform documentation in order to learn what kind of flash memory the platform uses to store the firmware and where the firmware is physically located in the system. In addition, there are numerous flash programming devices for specific hardware we could use to read the contents of the flash memory. We won’t discuss the various hardware and software options available for system firmware acquisition, because there are simply too many. Instead, we’ll go over one of the possible ways to dump firmware from the Lenovo ThinkPad T540p using the FT2232 SPI programmer.

We chose this SPI programmer because of its relatively low price (about $30) and flexibility, as well as our prior experience of working with it. As we’ve mentioned, there are many solutions, and each has its unique features, advantages, and drawbacks.

Locating the SPI Flash Memory Chip

Let’s start by physically reading the firmware image from the Lenovo ThinkPad T540p platform. First, to dump the system firmware from the target system, we need to find where, on the main board, the SPI flash memory chips are located. To do this, we consulted the Hardware Maintenance Manual (https://thinkpads.com/support/hmm/hmm_pdf/t540p _w540_hmm_en_sp40a26003_01.pdf ) for this laptop model and took apart the target system’s hardware. In Figures 19-9 and 19-10, you can see the locations of the two flash memory chips. Figure 19-9 shows a complete image of the system board. The SPI flash chips are located in the highlighted area.

Figure 19-10 zooms in on the region highlighted in Figure 19-9 so you can see the SPI flash chips more clearly. This laptop model uses two SOIC-8 flash memory modules to store the firmware—a 64Mb (8MB) one and a 32Mb (4MB) one. This is a very popular solution on many modern desktops and laptops.

Since two separate chips are used to store the system firmware, we’ll need to dump the contents of both. We’ll obtain the final firmware image by concatenating the images from the two flash memory chips into a single file.

Reading the SPI Flash with the FT2232 Mini Module

Once we’ve identified the physical location of the chips, we can connect the SPI programmer’s pins to the flash module on the system board. The datasheet (http://www.ftdichip.com/Support/Documents/DataSheets/Modules/DS _FT2232H_Mini_Module.pdf) for the FT2232H Mini Module shows us which pins we should use to attach the device to the memory chip.

Figure 19-11 demonstrates the layout of the pins for both the FT2232H Mini Module and the SPI flash chip. The FT2232H has two sets of pins, corresponding to two channels: Channel 2 and Channel 3. You may use either channel to read the contents of the SPI flash memory. In our experiment, we use Channel 3 to attach the FT2232H to the SPI memory chip.

 Figure 19-11 shows which of the FT2232H pins we connected to the corresponding pins of the SPI flash memory chip. In addition to connecting the FT2232H to the memory chip, we need to configure it to operate in USB bus-powered mode. The FT2232H Mini Module supports two modes of operating: USB bus-powered and self-powered. In the bus-powered mode, the mini module takes power from the USB bus it is attached to, and in self-powered mode, the power is provided independently of the USB bus connection.

To help us attach our SPI programmer to the SPI chip module, we use a SOIC-8 clip, as shown in Figure 19-12. This clip allows us to easily connect the mini module’s pins to the corresponding pins of the flash memory chip.

Analyzing the Firmware Image with UEFITool

 Once we obtain a firmware image from the target system’s SPI flash, we can analyze it. In this section, we’ll cover the basic components of platform firmware, such as firmware volumes, volume files, and the sections necessary for understanding the layout of the UEFI firmware in the flash image. Then we’ll focus on the most important steps in the forensic analysis of firmware.

We’re going to revisit UEFITool (https://github.com/LongSoft/UEFITool/), the open source tool for parsing, extracting, and modifying UEFI firmware images that was introduced in Chapter 15, to demonstrate theoretical concepts with the real firmware image we acquired in the previous section. The ability to look inside the firmware image to browse and extract various components is incredibly useful for forensic analysis. This tool doesn’t require installation; once downloaded, the application is ready to be executed.

Getting to Know the SPI Flash Regions

Before we look at the firmware image, we need to go over how the information stored on the SPI flash is organized. Generally, modern platforms based on the Intel chipset SPI flash consist of several regions. Each region is dedicated to storing firmware for a specific device available in the platform; for instance, UEFI BIOS firmware, Intel ME firmware, and Intel GBE (integrated LAN device) firmware are each stored in their own region. Figure 19-13 demonstrates the layout of several regions of the SPI flash.

Dumping UEFI NVRAM Variables

Now we’ll use Chipsec to enumerate and extract UEFI variables from the SPI flash image. In Chapter 17, we briefly covered how to use chipsec uefi var-list to extract NVRAM variables. UEFI Secure Boot relies on NVRAM variables to store configuration data like its Secure Boot policy value, platform key, key exchange keys, and db and dbx data. Running this command will produce a list of all the UEFI NVRAM variables stored in the firmware image, along with their content and attributes.

These are just a few commands out of the Chipsec tool’s rich arsenal. A comprehensive list of all Chipsec use cases would require a book of its own, but if you’re interested in the tool, we suggest checking out its documentation.

This concludes our analysis of a firmware image with Chipsec. After executing these commands, we get the extracted contents of the firmware image. The next step in forensic analysis would be to analyze the extracted components individually, using tools specific to the type of extracted object. For instance, you can analyze PEI and DXE modules using IDA Pro disassembler, while you can browse UEFI NVRAM variables in a hex editor.

 This list of Chipsec commands serves as a good starting point for further exploration of UEFI firmware. We encourage you to play with this tool and refer to the manual to learn its other capabilities and features in order to deepen your knowledge of firmware forensic analysis.

Conclusion

 In this chapter, we discussed important approaches to UEFI firmware forensic analysis: acquiring firmware, and parsing and extracting information from a UEFI firmware image.

We discussed two different ways to acquire firmware—the software approach and the hardware approach. The software approach is convenient, but it doesn’t provide a completely trustworthy way of obtaining a firmware image from the target system. For this reason, we recommend the hardware approach, despite its higher difficulty.

 We also demonstrated how to use two open source tools indispensable to analyzing and reverse engineering SPI flash images: UEFITool and Chipsec. UEFITool provides functionality for browsing, modifying, and extracting forensic data from an SPI flash image, and Chipsec is useful for performing many operations required in forensic analysis. The use of Chipsec also reveals how easily an attacker can modify the firmware image with a malicious payload, and so we expect interest in firmware forensics to significantly increase in the security industry.