NSA BIOS Backdoor a.k.a. God Mode Malware Part 1: DEITYBOUNCE
In this part we will learn about NSA BIOS Backdoor.
What is NSA BIOS Backdoor?
This article is the first part of a series on internal NSA BIOS backdoors. Before we begin, I would like to point out why these malware are classified as “god mode”. First, most of the malware use Internal Codenames (NSAs) in the realms of “gods” such as DEITYBOUNCE, GODSURGE, etc. Second, these malware have abilities similar to “god mode” cheats in video games, which make the player close to invincibility. This is the case with this type of malware as it is very difficult to detect and remove, even with the most sophisticated anti-malware tools, during its possible deployment time frame.
This part of the series focuses on the DEITYBOUNCE malware described in the NSA ANT Server document leaked by Edward Snowden. The analysis presented in this article is based on the technical implications of the information presented in the document. The document lacks many technical specifics, but based on the BIOS technology of the day DEITYBOUNCE started working, we can derive some technically sound hypotheses — or conclusions, if you will :-).
Introduction to DEITYBOUNCE Malware
DEITYBOUNCE works as part of the system shown in Figure 1. Figure 1 shows several special terms such as ROC, SNEAKERNET, etc. Some of these terms are used internally by the NSA. ROC stands for Remote Operations Center. The ROC acts as an NSA control point over the target system; located outside NSA headquarters. SNEAKERNET is a fancy term for physical data delivery, i.e. using people to move data between computers by moving removable media such as magnetic tapes, floppy disks, compact discs, USB flash drives (thumb drives, USB sticks) or external hard drives. from one computer to another.
Figure 1 DEITYBOUNCE Extended Concept of Operation
Figure 1 shows DEITYBOUNCE targeting machines marked with a red dot. DEITYBOUNCE itself is not installed on these computers because DEITYBOUNCE targets the Dell PowerEdge 1850/2850/1950/2950 RAID series servers with BIOS versions A02, A05, A06, 1.1.0, 1.2.0 or 1.3.7, not laptops or desktops computers/ workstations. This means DEITYBOUNCE is installed on servers accessed by laptops or desktops/workstations marked with red dots. The red dot also means that the target systems could act as a “jump host” to implant DEITYBOUNCE into the target servers.
Figure 1 also shows the presence of ARKSTREAM. ARKSTREAM is basically a malware dropper that includes BIOS flasher and malware dropper functions. ARKSTREAM can install DEITYBOUNCE on a target server either through remote exploits (network infection) or USB flash drive infection. In a way, this infection method is very similar to the STUXNET malware dropper. ARKSTREAM installs DEITYBOUNCE via BIOS flashing, i.e. replacing the BIOS of the PowerEdge server with one that is “infected” with the DEITYBOUNCE malware.
The NSA ANT server document does not reveal the fine details explaining the “technical context” of DEITYBOUNCE’s operation. However, we can derive some parts of the “technical context” from the DEITYBOUNCE technical requirements listed in the document. These are the important technical details revealed in the NSA ANT server document:
DEITYBOUNCE provides persistence of software applications on Dell PowerEdge servers by exploiting the motherboard BIOS and using System Management Mode (SMM) to obtain regular startups when the operating system (OS) loads.
DEITYBOUNCE supports multi-processor systems with hardware RAID and Microsoft Windows 2000, XP and 2003 Server.
Once implanted, the DEITYBOUNCE execution frequency (payload launch) is configurable and occurs when the target machine is powered up.
In later sections, based on these technical details, we will look at the DEITYBOUNCE malware architecture in more detail. These details provide much more valuable advice than you think :-). But before that, you need to have some important basic knowledge.
A closer look at Dell Power-Edge hardware
Let’s start with the first item of basic knowledge. In the previous section, we learned that DEITYBOUNCE targets the Dell PowerEdge 1850/2850/1950/2950 RAID series. Therefore, we need to take a closer look at the servers to understand the DEITYBOUNCE execution environment. You can download the relevant server specifications from the following links:
- Dell PowerEdge 1950 specification: http://www.dell.com/downloads/global/products/pedge/en/1950_specs.pdf
- Dell PowerEdge 2950 specification: http://www.dell.com/downloads/global/products/pedge/en/2950_specs.pdf
Server specifications are fairly common. However, if you take a closer look at the storage options of both types of servers, you will notice the option to use a RAID controller in both types of servers. The RAID controller is a PERC 5/i, PERC4e/DC or PERC 5/e type. We’re focusing on the RAID controller hardware because the DEITYBOUNCE specs mentioned the presence of RAID as one of their hardware “requirements”.
Now let’s move on to a more detailed analysis. Dell PERC Series RAID Controller User Guide can be downloaded from: ftp://ftp.dell.com/Manuals/Common/dell-perc-4-dc_User’s%20Guide_en-us.pdf. Despite the fact that the document is only a user guide, it provides important information as follows:
PERC stands for PowerEdge Expandable RAID Controller. This means that PERC series RAID controllers are either white-labeled by Dell or developed in-house by Dell.
There are several types of PERC RAID controllers. Labels labeled XX/i are integrated versions, label XX/SC means that the RAID controller is single-channel, label XX/DC means that the RAID controller is dual-channel, and label XXe/XX means that the RAID controller uses a PCI Express bus instead of PCI (PCIe). If the last nickname is missing, it means that the RAID controller uses PCI, not PCIe.
All PERC variants have 1 MB of integrated flash ROM. Note that this is not a PowerEdge server motherboard flash ROM, but a PERC RAID controller flash ROM (exclusive). Used to initialize and configure the RAID controller.
All PERC variants have NVRAM to store configuration data. The NVRAM is located on the PERC adapter board, except when the PERC is integrated into the motherboard.
The PERC RAID controller flash ROM size (1 MB) is huge in terms of firmware code. Therefore, anyone can insert an advanced – read: large in code size – malicious module into it at the firmware level.
I can’t find the Dell PowerEdge 1850/2850/1950/2950 BIOS chip size information. However, the size of their compressed BIOS files is larger than 570 KB. So it’s safe to assume that motherboards BIOS chip size is at least 1MB, because AFAIK there is no flash ROM chip – used to store BIOS code – between 570KB and 1MB in size. The closest flash ROM size to 570KB is 1MB. This fact also presents a huge opportunity to place BIOS malware in the motherboard BIOS in addition to the RAID controller expansion ROM.
Initial Program Loader (IPL) Device Primer
The second item of knowledge you need to know is about the IPL device. A RAID controller or other storage controller is an attractive victim of firmware malware because it is an IPL device according to the BIOS boot specification. The BIOS boot specification and the PCI specification mandate that the IPL device firmware must be executed at boot time if an IPL device is used. IPL device firmware is mostly implemented as a PCI expansion ROM. So the firmware of the IPL device will always boot, provided that the IPL device is in use. This fact paves the way for firmware-level malware to reside in the firmware of the IPL device, especially if the malware needs to be executed at every boot or at a specific bootloader.
For more details on booting the IPL firmware, see: https://sites.google.com/site/pinczakko/low-cost-embedded-x86-teaching-tool-2. In this article, you need to take a closer look at the Boot Connection Vector (BCV) in a PCI expansion ROM. The BIOS calls/jumps into BCV during bootstrap to start the bootloader, which then loads and boots the OS. BCV is implemented in the PCI expansion ROM of the storage controller device. Therefore, the PERC RAID controller on Dell PowerEdge servers should also implement BCV to match the BIOS boot specification.
The IPL PCI device expanding the ROM also has a peculiarity. In some BIOS implementations, it is always performed whether the IPL device is in use or not. This is because the BIOS code is very likely only checking the PCI device subclass code and the interface code in its PCI configuration register. See “Peculiarity of PCI PnP Expansion ROM” at https://sites.google.com/site/pinczakko/low-cost-embedded-x86-teaching-tool-2#pci_pnp_rom_peculiarity.
System Management Mode (SMM) Primer.
The third item of knowledge needed to understand DEITYBOUNCE is SMM. The seminal work on SMM malware can be found in the Phrack ezine article, A Real SMM Rootkit: Reversing and Hooking BIOS SMI Handlers at http://www.phrack.com/issues.html?issue=66&id=11#article. SMI in this context means System Management Interruption. The Phrack article contains the knowledge needed to understand how an SMM rootkit can work.
However, there is one thing to update in this Phrack article. Recent and current CPUs no longer use the high segment (HSEG) to store SMM code. Only the top-of-memory segment (TSEG) is used for this purpose. If you are not familiar with HSEG and TSEG, you can check https://resources.infosecinstitute.com/system-address-map-initialization-in-x86x64-architecture-part-1-pci-based-systems/ and https:/ /resources.infosecinstitute.com/system-address-map-initialization-x86x64-architecture-part-2-pci-express-based-systems/ for details on HSEG and TSEG placement in CPU memory space. This means that for maximum forward compatibility, DEITYBOUNCE is very likely only using TSEG in its SMM component.
Entering SMM via software SMI in x86/x64 is quite simple. All you have to do is write a specific value to a specific I/O port address. A write transaction to this I/O port is interpreted by the chipset as a request to enter the SMM, therefore the chipset sends an SMI signal to the CPU to enter the SMM. There are certain x86/x64 processors that directly “catch” this kind of write I/O transaction and interpret it directly as an SMM input request without passing anything to the chipset first. The complete algorithm for entering SMM is as follows:
Initialize the DX register using the SMM “activate” port. Typically, the SMM “activation” port is port number 0xB2. However, it may be a different port depending on the particular CPU and chipset combination. You have to refer to their datasheets for details.
Initialize the AX register with the value of the SMI command.
Enter SMM by writing the value of AX to the output port contained in the DX register.
As for the methods of passing parameters to the SMI handler routine, the Phrack article does not cover them very much. Therefore, we will look at the methods here.
Some SMM (SMI utility) code needs to communicate with other BIOS modules or software running inside the operating system. The communication mechanism is done by passing parameters between SMM code and code running outside of SMM. Parameters passed between the BIOS and the SMI handler are generally done using one of the following mechanisms:
Through Global Nonvolatile Storage (GNVS). GNVS is part of the ACPI v4.0 specification and is named ACPI non-volatile storage (NVS) in the ACPI specification.
. However, in some patent descriptions, NVS stands for non-volatile memory because the memory area occupied by NVS in RAM stores data that is retained even when the system is in sleep mode. Both terms refer to the same area in RAM. Therefore, naming inconsistencies can be ignored. GNVS or ACPI NVS is part of the RAM managed by the ACPI subsystem in the BIOS. It stores various data. GNVS is not managed by the OS, but is reachable by the OS via the ACPI source language (ASL) interface. On Windows, parts of this area are accessible through Windows Management Instrumentation (WMI).
Through General Purpose Registers (GPR) in x86/x64 architecture i.e. RAX/EAX, RBX/EBX, RDX/EDX etc. In this technique physical address pointer is passed through GPR to SMI handler code. Because the system state, including register values, is stored in the “SMM save state”, code in the SMM (SMI handler) area is able to read the value of the pointer. The catch is that both the SMI handler and the code that passes the parameter(s) must agree on a “calling convention”, i.e. which registers to use.
Knowing how to pass parameters between the BIOS and the SMI handler is important because DEITYBOUNCE makes extensive use of this mechanism in its runtime. We will cover this in more detail in the next sections.
The predecessor of the DEITYBOUNCE malware architecture
As with other software, we can infer the architecture of the DEITYBOUNCE malware from its execution environment. The NSA ANT server document mentions three technical advisories, as you can see in the Introduction section. We will dive into them one by one to reveal the possible architecture of DEITYBOUNCE.
The need for RAID hardware means that DEITYBOUNCE contains malware implanted in the PCI expansion ROM of the RAID controller. The RAID controller used in the Dell PowerEdge 1950 is a PERC 5/i or PERC4e/DC or PERC 5/e adapter card. All of these RAID controllers are PCI or PCI Express (PCIe) RAID controllers. You have to be careful that the PCI expansion ROM also contains the PCIe expansion ROM as both are practically the same. I covered the basics of PCI ROM expanding malware in another article. See https://resources.infosecinstitute.com/pci-expansion-rom/ for details.
The presence of a DEITYBOUNCE launched payload means that DEITYBOUNCE is essentially a “second stage” malware dropper – the first stage being the ARKSTREAM malware dropper. DEITYBOUNCE probably only provides these two basic functions:
The first is as a persistent and stealthy dropper of malware modules.
The second is to provide a “hidden” inspection function for other OS-specific malware modules. Malware modules can be executed during operating system initialization or from within a running operating system, or malware modules can operate in both scenarios. OS-specific malware communicates with DEITYBOUNCE via SMM calls.
The basic functions of DEITYBOUNCE above indicate that there are possibly three kinds of malware components that are required for DEITYBOUNCE to work as follows:
Permanently “infected” PCI expansion ROM. This module contains a routine to configure the execution frequency of DEITYBOUNCE. The routine may save the configuration to the NVRAM of the RAID controller. This module also contains an infected interrupt 13h (Int 13h) handler that can call other routines via SMI and repair the kernel of the currently loaded OS.
SMI handler code implanted in the BIOS of a PowerEdge motherboard to handle SMI software (SW) calls from an “infected” ROM expansion RAID controller.
Operating system-specific malware running on Windows 2000, Windows Server 2003, or Windows XP.
At this point, we already know the components of the DEITYBOUNCE malware. This does not mean that we would be able to know the exact architecture of the malware, as there are several possible ways to implement the components. However, I present here the most likely architecture. That’s an educated guess. There may be inaccuracies as I do not have a sample DEITYBOUNCE binary to support my claims. But I think the estimates should be close enough, given the nature of the x86/x64 firmware architecture. If you could provide a sample binary with the suspected DEITYBOUNCE in it, I’m open to analyzing it :-).
Architecture of DEITYBOUNCE Malware
Before we approach the architecture of DEITYBOUNCE, we need to make a few assumptions. This should make it easier to determine the technical details of DEITYBOUNCE. These are the prerequisites:
The BIOS used by the Dell PowerEdge targets is an older BIOS, not EFI/UEFI. This assumption is reinforced by the NSA ANT server document, which lists Windows 2000/XP/2003 as the target OS. None of these operating systems provide advanced EFI/UEFI support. All user manuals, including the BIOS setup user manual, do not list any menus related to UEFI/EFI support, such as booting into legacy BIOS mode. So it’s safe to assume that BIOS is an older implementation of BIOS. Additionally, during DEITYBOUNCE launch time, EFI/UEFI support is still immature in the market.
The custom SMI handlers required to repair the operating system kernel during bootstrap are larger than the free space available in the motherboard BIOS. Therefore, the routines must be placed in two separate flash ROMs, i.e. the PERC RAID controller flash ROM chip and the Dell PowerEdge motherboard flash ROM chip. Maybe not, but let’s just make an assumption here, because even a basic NTFS driver would require at least several tens of kilobytes of space when compressed, not to mention complicated malware designed to patch the kernels of three different operating systems.
The above assumptions have several implications for our purported DEITYBOUNCE architecture. The first is that there are two phases when performing DEITYBOUNCE. The second is that the malware code that fixes the kernel of the target operating system during bootstrap (interrupt 19h) runs in SMM.
Now let’s look into the stages of executing DEITYBOUNCE. The stages of performing DEITYBOUNCE are as follows:
Phase 1 – Initialization of the PCI ROM expansion memory during the power-on self-test (POST). At this stage, DEITYBOUNCE installs additional malicious SMI handlers in the System Management RAM (SMRAM) extent of the motherboard’s RAM. Here it is assumed that the SMRAM range is not yet locked by the motherboard BIOS, so the SMRAM range is still writable. SMRAM is an area of system memory (RAM) used specifically for SMM code and data. SMRAM content is only accessible via SMI after it has been locked. On most Intel Northbridge chipsets or newer CPUs, SMRAM is controlled by a register that controls the TSEG memory area. Usually, the register in the Intel chipset documentation is called TSEG_BASE.
Phase 2 – Interrupt 13h execution during bootstrap (interrupt 19h). The 13h interrupt handler in the PERC RAID PCI Expansion ROM is “patched” with malicious code to handle the 19h (bootstrap) interrupt. Interrupt 19h copies the bootloader into RAM by calling the interrupt 13h 02h function, reads the sectors from the drive, and jumps to it. DEITYBOUNCE does not compromise the bootloader. However, DEITYBOUNCE compromises the 13h interrupt handler. Handling the “fixed” interrupt 13h modifies the loaded operating system kernel in RAM.
Figure 2 shows phase 1 of DEITYBOUNCE execution and Figure 3 shows phase 2 of DEITYBOUNCE execution.
Figure 2 DEITYBOUNCE Execution Stage 1
DEITYBOUNCE Phase 1 execution, shown in Figure 2, occurs during the initialization phase extending the PCI ROM to POST. If you are not familiar with the detailed steps the BIOS takes during x86/x64 system initialization, or the power-on self-test, please read my article on x86/x64 system address map initialization, part 1 at https:// resources.infosecinstitute.com /system-address-map-initialization-in-x86x64-architecture-part-1-pci-based-systems/.
We know that PCI expansion ROM initialization is initiated by the motherboard BIOS from the article Malicious Code Execution in PCI Expansion ROM (https://resources.infosecinstitute.com/pci-expansion-rom/). The motherboard BIOS calls the INIT function (offset 03h from the start of the PCI expansion ROM) with a remote call to initiate the initialization of the add-in board using the PCI expansion ROM. This event is phase 1 of the DEITYBOUNCE implementation. In the case of DEITYBOUNCE, the add-on board is a PERC PCI/PCIe board or a PERC chip integrated with the PowerEdge motherboard.
Figure 2 illustrates the following implementation steps:
The PERC RAID PCI expansion ROM is booted from the INIT entry point.
The infected ROM code reads the DEITYBOUNCE configuration data from the NVRAM of the RAID controller.
The infected ROM code copies additional SMI DEITYBOUNCE drivers into the SMRAM array in the motherboard’s main memory (system RAM).
The infected ROM code corrects the checksums of the SMRAM contents as needed.
Once the above steps are completed, the SMRAM contains all the SMI DEITYBOUNCE drivers. Figure 2 shows that SMRAM contains “embedded” SMI DEITYBOUNCE drivers that are already present in SMRAM before the DEITYBOUNCE component in the RAID controller’s PCI expansion ROM is copied to SMRAM. The built-in DEITYBOUNCE is embedded in the motherboard’s BIOS. That’s why it’s coming soon to SMRAM.
Figure 2 shows the DEITYBOUNCE configuration data stored in the NVRAM of the PERC add-on board. This is an elegant and unobtrusive way of storing configuration data. How many anti-malware tools scan an NVRAM add-on board? I’ve never heard of one.
Figure 3 DEITYBOUNCE Execution Stage 2
Now let’s move on to phase 2 of the DEITYBOUNCE execution. There are several steps in this execution phase:
The motherboard BIOS runs the PERC RAID controller PCI ROM extension routine at bootstrap via interrupt 19h (bootstrap). This time, the entry point of a PCI expansion ROM is its BCV, not the INIT function. Interrupt 19h calls interrupt 13h 02h to load the first sector of the boot device—in this case the HDD controlled by the RAID controller—into RAM and then jumps to it to start the bootloader.
The infected PCI ROM extension routine contains its own 13h interrupt handler. This user interrupt handler is triggered when the bootloader calls interrupt 13h and part of the OS initialization code. Custom routines contain the original logic of the 13h interrupt handler. But custom adds routines to infect the OS loaded kernel. Interrupt 13h provides read/write/query services to the storage device. Therefore, a malicious coder can modify the contents of the 13h interrupt handler to manipulate the contents loaded into RAM. Figure 3 shows that the custom interrupt handler 13h contains a routine to call the DEITYBOUNCE SMI handler through the software SMI. The DEITYBOUNCE SMI handler contains a routine to install malware or to activate certain vulnerabilities in the target operating system’s kernel while the operating system is still in the initialization phase. Execution of the 13h custom interrupt handler depends on the DEITYBOUNCE configuration data. Figure 3 DEITYBOUNCE configuration data related to the 13h custom interrupt handler is stored in the NVRAM of the PERC RAID controller.
The target operating system contains a vulnerability or malware after steps 1 and 2 when performing the second phase of DEITYBOUNCE. Note that the vulnerability or malware only exists in RAM because the instance of the operating system that is modified with DEITYBOUNCE exists in RAM, not on a persistent storage device (HDD or SSD).
At this point, we know how DEITYBOUNCE can work in enough detail. However, you should note that this is only the result of my preliminary evaluation on DEITYBOUNCE. Therefore, they must have inaccuracies.
Final Thoughts: Hypotheses about the technical purpose of DEITYBOUNCE
Compared to “ordinary” malware, DEITYBOUNCE has two undeniable strategic values:
DEITYBOUNCE provides a stealthy way to change the loaded OS without leaving a trace on the storage device, i.e. HDD or SSD, to avoid detection by “normal” computer forensics. Why? Since the OS is manipulated when it is loaded into RAM, the OS installation on the storage device itself remains intact (original). SMM code execution provides a way to hide code execution from possible operating system integrity checks by third-party scanners. In this respect, we can view DEITYBOUNCE as a very sophisticated malware dropper.
DEITYBOUNCE provides a way to keep the malware present on the target system as it is resistant to OS reinstallation.
Given the capabilities provided by DEITYBOUNCE, there could be a stealthy Windows rootkit that communicates with DEITYBOUNCE via the software SMI to call the DEITYBOUNCE SMI handler at runtime from within Windows. The purpose of such a rootkit is unclear at this time. Whether the required SMI handler implements DEITYBOUNCE is unknown at this time.
Also Read:Theoretical Methodology for Detecting ICMP Reflected Attacks: SMURF Attacks 2023
