Hacking

NSA BIOS Backdoor a.k.a. God Mode Malware Part 1: DEITYBOUNCE

January 29, 2014 by Darmawan Salihun

This article is the first part of a series on NSA BIOS backdoor internals. Before we begin, I’d like to point out why these malwares are classified as “god mode.” First, most of the malware uses an internal (NSA) codename in the realms of “gods,” such as DEITYBOUNCE, GODSURGE, etc. Second, these malwares have capabilities similar to “god mode” cheats in video games, which make the player using it close to being invincible. This is the case with this type of malware because it is very hard to detect and remove, even with the most sophisticated anti-malware tools, during its possible deployment timeframe.

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 technical implications of the information provided by the document. The document lacks many technical specifics, but based on the BIOS technology at the day DEITYBOUNCE started to become operational, we can infer some technically sound hypotheses—or conclusions, if you prefer :-).

Introduction to DEITYBOUNCE Malware

DEITYBOUNCE operates as part of the system shown in Figure 1. Figure 1 shows several peculiar terms, such as ROC, SNEAKERNET, etc. Some of these terms are internally used by NSA. ROC is an abbreviation for remote operation center. ROC acts as NSA’s point of control of the target system; it’s located outside NSA’s headquarter. SNEAKERNET is a fabulous term for physical delivery of data, i.e., using humans to move data between computers by moving removable media such as magnetic tape, floppy disks, compact discs, USB flash drives (thumb drives, USB stick), or external hard drives from one computer to another.

Figure 1 DEITYBOUNCE Extended Concept of Operation

Figure 1 shows DEITYBOUNCE targeting the machines marked with red dot. DEITYBOUNCE itself is not installed on those machines because DEITYBOUNCE targets Dell PowerEdge 1850/2850/1950/2950 RAID server series with BIOS versions A02, A05, A06, 1.1.0, 1.2.0, or 1.3.7, not laptops or desktop/workstations. This means DEITYBOUNCE is installed in servers accessed by the laptops or desktop/workstations marked with red dots. The red dot also means that the target systems could act as “jump hosts” to implant DEITYBOUNCE in the target servers.

Figure 1 also shows the presence of ARKSTREAM. ARKSTREAM is basically a malware dropper which contains BIOS flasher and malware dropper functions. ARKSTREAM can install DEITYBOUNCE on the target server either via exploits controlled remotely (network infection) or via USB thumb drive infection. This infection method, in a way, is very similar to the STUXNET malware dropper. ARKSTREAM installs DEITYBOUNCE via BIOS flashing, i.e., replacing the PowerEdge server BIOS with the one that is “infected” by DEITYBOUNCE malware.

The NSA ANT server document doesn’t divulge minute details explaining DEITYBOUNCE’s “technical context” of operation. However, we can infer some parts of the “technical context” from the DEITYBOUNCE technical requirements mentioned in the document. These are the important technical details revealed by the NSA ANT server document:

  1. DEITYBOUNCE provides software application persistence on Dell PowerEdge servers by exploiting the motherboard BIOS and utilizing system management mode (SMM) to gain periodic executions while the operating system (OS) loads.
  2. DEITYBOUNCE supports multiprocessor systems with RAID hardware and Microsoft Windows 2000, XP, and 2003 Server.
  3. Once implanted, DEITYBOUNCE’s frequency of execution (dropping the payload) is configurable and will occur when the target machine powers on.

In later sections, we will look into DEITYBOUNCE malware architecture in more detail, based on these technical details. These details provide a lot more valuable hints than you think :-). But before that, you need to have some important background knowledge.

A Closer Look at Dell Power-Edge Hardware

Let’s start with the first item of background knowledge. In the previous section, we learned that DEITYBOUNCE targets Dell PowerEdge 1850/2850/1950/2950 RAID server series. Therefore, we need to look into the servers more closely to understand the DEITYBOUNCE execution environment. One can download the relevant server specifications from these links:

  1. Dell PowerEdge 1950 specification: http://www.dell.com/downloads/global/products/pedge/en/1950_specs.pdf
  2. Dell PowerEdge 2950 specification: http://www.dell.com/downloads/global/products/pedge/en/2950_specs.pdf

The server specifications are rather ordinary. However, if you look more closely at the storage options of both server types, you’ll notice the option to use a RAID controller in both server types. The RAID controller is of the type PERC 5/i, PERC4e/DC, or PERC 5/e. We focus on the RAID controller hardware because DEITYBOUNCE technical details mentioned the presence of RAID as one of its hardware “requirements.”

Now let’s move into more detailed analysis. You can download the user guide for the Dell PERC family of RAID controller 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:

  1. PERC stands for PowerEdge Expandable RAID Controller. This means the PERC series of RAID controller are either white-labeled by Dell or developed internally by Dell.
  2. There are several types of PERC RAID controllers. The ones with the XX/i moniker are the integrated versions, the XX/SC moniker means that the RAID controller is single channel, the XX/DC moniker means that the RAID controller is dual channel, and the XXe/XX moniker signifies that the RAID controller uses PCI Express (PCIe) instead of PCI bus. If the last moniker is missing, it implies that the RAID controller uses PCI, not PCIe.
  3. All PERC variants have 1MB of onboard flash ROM. Mind you, this is not the PowerEdge server motherboard flash ROM but the PERC RAID controller (exclusive) flash ROM. It’s used to initialize and configure the RAID controller.
  4. All PERC variants have NVRAM to store their configuration data. The NVRAM is located in the PERC adapter board, except when the PERC is integrated into the motherboard.

The PERC RAID controller flash ROM size (1MB) is huge from the firmware code point of view. Therefore, anyone can insert an advanced—read: large in code size—malicious firmware-level module into it.

I can’t find information on the Dell PowerEdge 1850/2850/1950/2950 BIOS chip size. However, the size of their compressed BIOS files is larger than 570KB. Therefore, it’s safe to assume that the motherboards BIOS chip size are at least 1MB because, AFAIK, there is no flash ROM chip—used to store BIOS code—that has a size between 570KB and 1MB. The closest flash ROM size to 570KB is 1MB. This fact also present a huge opportunity to place BIOS malware into the motherboard BIOS besides the RAID controller expansion ROM.

Initial Program Loader (IPL) Device Primer

The second item of background knowledge you need to know pertains to the IPL device. A RAID controller or other storage controller is an attractive victim for firmware malware because they are IPL devices, as per BIOS boot specification. The BIOS boot specification and PCI specification dictate that IPL device firmware must be executed at boot if the IPL device is in use. IPL device firmware is mostly implemented as PCI expansion ROM. Therefore, IPL device firmware is always executed, assuming the IPL device is in use. This fact opens a path for firmware-level malware to reside in the IPL device firmware, particularly if the malware has to be executed at every boot or on certain trigger at boot.

For more details on IPL device firmware execution, see: https://sites.google.com/site/pinczakko/low-cost-embedded-x86-teaching-tool-2. You need to take a closer look at the boot connection vector (BCV) in the PCI expansion ROM in that article. The system BIOS calls/jumps-into the BCV during bootstrap to start the bootloader, which then loads and executes the OS. BCV is implemented in the PCI expansion ROM of the storage controller device. Therefore, the PERC RAID controller in Dell PowerEdge servers should implement BCV as well to conform to the BIOS boot specification.

IPL device PCI expansion ROM also has a peculiarity. In some BIOS implementations, it’s always executed, whether or not the IPL device is being used. The reason is that the BIOS code very probably only checks for the PCI device subclass code and interface code in its PCI configuration register. See the “PCI PnP Expansion ROM Peculiarity” section 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 background knowledge needed to understand DEITYBOUNCE is SMM. A 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 interrupt. The Phrack article contains knowledge required to understand how an SMM rootkit might work.

There is one thing that needs to be updated in that Phrack article, though. Recent and present-day CPUs don’t use high segment (HSEG) anymore to store SMM code. Only top-of-memory segment (TSEG) is used for that purpose. If you’re not familiar with HSEG and TSEG, you can refer to 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 location in the CPU memory space. This means, for maximum forward compatibility, DEITYBOUNCE very possibly only uses TSEG in its SMM component.

Entering SMM via software SMI in x86/x64 is quite simple. All you need to do is write a certain value to a particular I/O port address. A write transaction to this I/O port is interpreted by the chipset as a request to enter SMM, therefore the chipset sends an SMI signal to the CPU to enter SMM. There are certain x86/x64 CPUs that directly “trap” this kind of I/O write transaction and interpret it directly as a request to enter SMM without passing anything to the chipset first. The complete algorithm to enter SMM is as follows:

  1. Initialize the DX register with the SMM “activation” port. Usually, the SMM “activation” port is port number 0xB2. However, it could be a different port, depending on the specific CPU and chipset combination. You have to resort to their datasheets for the details.
  2. Initialize the AX register with the SMI command value.
  3. Enter SMM by writing the AX value to the output port contained in the DX register.

As for the methods to pass parameters to the SMI handler routine, it’s not covered extensively by the Phrack article. Therefore, we will have a look the methods here.

Some SMM code (SMI handler) needs to communicate with other BIOS modules or with software running inside the OS. The communication mechanism is carried out through parameter passing between the SMM code and code running outside SMM. Parameter(s) passing between the BIOS module and SMI handler in general are carried out using one of these mechanisms:

  1. Via the global non-volatile storage (GNVS). GNVS is part of ACPI v4.0 Specification and named ACPI non-volatile storage (NVS) in the ACPI specification. However, in some patent descriptions, NVS stands for non-volatile sleeping memory because the memory region occupied by NVS in RAM stores data that’s preserved even if the system is in sleep mode. Either term refers to the same region in RAM. Therefore, the discrepancies in naming can be ignored. GNVS or ACPI NVS is part of 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 through the ACPI source language (ASL) interface. In Windows, parts of this region are accessible through the Windows management instrumentation (WMI) interface.
  2. Via general-purpose registers (GPRs) in x86/x64 architecture, i.e., RAX/EAX, RBX/EBX, RDX/EDX, etc. In this technique, a physical address pointer is passed via GPR to the SMI handler code. Because the system state, including the register values, is saved to the “SMM save state,” the code in the SMM area (the SMI handlers) is able to read the pointer value. The catch is: both the SMI handler and the code that passes the parameter(s) must agree on the “calling convention”, i.e., which register(s) to use.

Knowing parameter passing between BIOS module and SMI handler is important because DEITYBOUNCE uses this mechanism extensively when it runs. We will look into it in more detail in later sections.

Precursor to DEITYBOUNCE Malware Architecture

As with other software, we can infer DEITYBOUNCE malware architecture from its execution environment. The NSA ANT server document mentions three technical hints, as you can see in the Introduction section. We’ll delve into them one by one to uncover the possible DEITYBOUNCE architecture.

The need for RAID hardware means that DEITYBOUNCE contains a malware implanted in the RAID controller PCI expansion ROM. The RAID controller used in Dell PowerEdge 1950 server is the PERC 5/i, or PERC4e/DC, or PERC 5/e adapter card. All of these RAID controllers are either PCI or PCI Express (PCIe) RAID controllers. You have to pay attention to the fact that PCI expansion ROM also includes PCIe expansion ROM, because both are virtually the same. I have covered PCI expansion ROM malware basics in another article. See https://resources.infosecinstitute.com/pci-expansion-rom/ for the details.

The presence of a payload being dropped by DEITYBOUNCE means DEITYBOUNCE is basically a “second-stage” malware dropper—the first stage is the ARKSTREAM malware dropper. DEITYBOUNCE probably only provides these two core functions:

  1. The first is as a persistent and stealthy malware modules dropper.
  2. The second is to provide a “stealth” control function to other OS-specific malware modules. The malware modules could be running during OS initialization or from inside a running OS or the malware modules can operate in both scenarios. The OS-specific malware communicates with DEITYBOUNCE via SMM calls.

The DEITYBOUNCE core functions above imply that there are possibly three kinds of malware components required for DEITYBOUNCE to work as follows:

  1. A persistent “infected” PCI expansion ROM. This module contains a routine to configure DEITYBOUNCE’s frequency of execution. The routine possibly stores the configuration in the RAID controller NVRAM. This module also contains the tainted interrupt 13h (Int 13h) handler that can call other routines via SMI to patch the kernel of the currently loading OS.
  2. SMI handler(s) code implanted in the PowerEdge motherboard BIOS to serve the software (SW) SMI calls from the “infected” RAID controller PCI expansion ROM.
  3. An OS-specific malware payload running in Windows 2000, Windows Server 2003, or Windows XP.

At this point we already know the DEITYBOUNCE malware components. This doesn’t imply that we would be able to know the exact architecture of the malware, because there are several possible pathways through which to implement the components. However, I present the most probable architecture here. This is an educated guess. There could be inaccuracies because I don’t have a sample DEITYBOUNCE binary to back up my assertions. But I think the guesses should be close enough, given the nature of x86/x64 firmware architecture. If you could provide a binary sample with suspected DEITYBOUNCE in it, I’m open to analyze it, though :-).

DEITYBOUNCE Malware Architecture

We need to make several assumptions before proceeding to the DEITYBOUNCE architecture. This should make it easier to pinpoint the technical details of DEITYBOUNCE. These are the assumptions:

  1. The BIOS used by the Dell PowerEdge targets is a legacy BIOS, not EFI/UEFI. This assumption is strengthened by the NSA ANT server document, which mentions the target OS as Windows 2000/XP/2003. None of these operating systems provides mature EFI/UEFI support. All user manuals, including the BIOS setup user manual, don’t indicate any menu related to UEFI/EFI support, such as booting in legacy BIOS mode. Therefore, it’s safe to assume that the BIOS is a legacy BIOS implementation. Moreover, during the launch time of DEITYBOUNCE, EFI/UEFI support in the market is still immature.
  2. The custom SMI handler routines required to patch the OS kernel during bootstrap are larger than the empty space available in the motherboard BIOS. Therefore, the routines must be placed into two separate flash ROM storage, i.e., the PERC RAID controller flash ROM chip and the Dell PowerEdge motherboard flash ROM chip. This may be not the case, but let’s just make an assumption here, because even a rudimentary NTFS driver would require at least several tens of kilobytes of space when compressed, not to mention a complicated malware designed to patch kernels of three different operating systems.

The assumptions above have several consequences for our alleged DEITYBOUNCE architecture. The first one is that there are two stages in DEITYBOUNCE execution. The second one is that the malware code that patches the target OS kernel during bootstrap (interrupt 19h) is running in SMM.

Now let’s look into the DEITYBOUNCE execution stages. DEITYBOUNCE execution stages are as follows:

  1. Stage 1—PCI expansion ROM initialization during power-on self-test (POST). In this stage, DEITYBOUNCE installs additional malicious SMI handlers in the system management RAM (SMRAM) range in the RAM on the motherboard. The assumption here is that the SMRAM range is not yet locked by the motherboard BIOS, therefore the SMRAM range is still writeable. SMRAM is a range in system memory (RAM) that is used specifically for SMM code and data. Contents of SMRAM are only accessible through SMI after it has been locked. On most Intel Northbridge chipsets or recent CPUs, SMRAM is controlled by the register that controls the TSEG memory region. Usually, the register is called TSEG_BASE in Intel chipset documentation.
  2. Stage 2—Interrupt 13h execution during bootstrap (interrupt 19h). Interrupt 13h handler in the PERC RAID controller PCI expansion ROM is “patched” with malicious code to serve interrupt 19h invocation (bootstrap). Interrupt 19h copies the bootloader to RAM by calling interrupt 13h function 02h, read sectors from drive, and jump into it. DEITYBOUNCE doesn’t compromise the bootloader. However, DEITYBOUNCE compromises the interrupt 13h handler. The “patched” interrupt 13h handler will modify the loaded OS kernel in RAM.

Figure 2 shows stage 1 of DEITYBOUNCE execution and Figure 3 shows stage 2 of DEITYBOUNCE execution.

Figure 2 DEITYBOUNCE Execution Stage 1

DEITYBOUNCE stage 1 execution, shown in Figure 2, happens during the PCI expansion ROM initialization stage at POST. If you’re not familiar with the detailed steps carried out by the BIOS to initialize an x86/x64 system, a.k.a. power-on self-test, please read my system address map initialization on x86/x64 Part 1 article 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 Malicious Code Execution in PCI Expansion ROM article (https://resources.infosecinstitute.com/pci-expansion-rom/). The motherboard BIOS calls the INIT function (offset 03h from start of the PCI expansion ROM) with a far call to start add-on board initialization by the PCI expansion ROM. This event is the stage 1 of DEITYBOUNCE execution. In the DEITYBOUNCE case, the add-on board is the PERC PCI/PCIe board or the PERC chip integrated with the PowerEdge motherboard.

Figure 2 illustrates the following execution steps:

  1. PERC RAID PCI expansion ROM executes from its INIT entry point.
  2. The infected ROM code reads DEITYBOUNCE configuration data from the RAID controller NVRAM.
  3. The infected ROM code copies DEITYBOUNCE’s additional SMI handlers to the SMRAM range in the motherboard main memory (system RAM).
  4. The infected ROM code fixes checksums of the contents of SMRAM as needed.

Once the steps above are finished, the SMRAM contains all of DEITYBOUNCE’s SMI handlers. Figure 2 shows that the SMRAM contains “embedded” DEITYBOUNCE SMI handlers that are already present in SMRAM before the DEITYBOUNCE component in the RAID controller PCI expansion ROM is copied into SMRAM. The embedded DEITYBOUNCE component is injected into the motherboard BIOS. That’s why it’s already present in SMRAM early on.

Figure 2 shows DEITYBOUNCE configuration data stored in the PERC add-on board NVRAM. This is an elegant and stealthy way of storing configuration data. How many anti-malware tools scan add-on board NVRAM? I’ve never heard of any.

Figure 3 DEITYBOUNCE Execution Stage 2

Now, let’s move to stage 2 of DEITYBOUNCE execution. There are several steps in this execution stage, as follows:

  1. The mainboard BIOS executes the PERC RAID controller PCI expansion ROM routine at bootstrap via interrupt 19h (bootstrap). This time the entry point of the PCI expansion ROM is its BCV, not the INIT function. Interrupt 19h invokes interrupt 13h function 02h to read the first sector of the boot device—in this case the HDD controlled by the RAID controller—to RAM and then jump into it to start the bootloader.
  2. The infected PCI expansion ROM routine contains a custom interrupt 13h handler. This custom interrupt handler executes when interrupt 13h is called by the bootloader and part of the OS initialization code. The custom routines contain the original interrupt 13h handler logic. But the custom one adds routines to infect the kernel of the OS being loaded. Interrupt 13h provides services to read/write/query the storage device. Therefore, a malicious coder can modify the contents of interrupt 13h handler routine to tamper with the content being loaded to RAM. Figure 3 shows that the custom interrupt 13h handler contains a routine to call the DEITYBOUNCE SMI handler via software SMI. The DEITYBOUNCE SMI handler contains a routine to install malware or to activate certain vulnerabilities in the target OS kernel while the OS is still in the initialization phase. Execution of the custom interrupt 13h handler depends on DEITYBOUNCE configuration data. Figure 3 DEITYBOUNCE configuration data related to the custom interrupt 13h handler is stored in the PERC RAID controller NVRAM.

The target OS contains a vulnerability or malware after steps 1 and 2 in DEITYBOUNCE second stage execution. Keep in mind that the vulnerability or malware only exists in RAM because the instance of the OS that’s modified by DEITYBOUNCE exists in RAM, not in a permanent storage device (HDD or SSD).

At this point we know how DEITYBOUNCE might work in sufficient detail. However, you should be aware that this is only the result of my preliminary assessment on DEITYBOUNCE. Therefore, it’s bound to have inaccuracies.

Closing Thoughts: Hypotheses on DEITYBOUNCE Technical Purpose

There are two undeniable strategic values possessed by DEITYBOUNCE compared to “ordinary” malware:

  1. DEITYBOUNCE provides a stealthy way to alter the loaded OS without leaving a trace on the storage device, i.e., HDD or SSD, in order to avoid being detected via “ordinary” computer forensic procedures. Why? Because the OS is manipulated when it’s loaded to RAM, the OS installation on the storage device itself is left untouched (genuine). SMM code execution provides a way to conceal the code execution from possible OS integrity checks by other-party scanners. In this respect, we can view DEITYBOUNCE as a very sophisticated malware dropper.
  2. DEITYBOUNCE provides a way to preserve the presence of the malware in the target system because it is persistent against OS reinstallation.

Given the capabilities provided by DEITYBOUNCE, there could possibly be a stealthy Windows rootkit that communicates with DEITYBOUNCE via software SMI to call the DEITYBOUNCE SMI handler routine at runtime from within Windows. The purpose of such a rootkit is unclear at this point. Whether the required SMI handler is implemented by DEITYBOUNCE is unknown at the moment.

Posted: January 29, 2014
Articles Author
Darmawan Salihun
View Profile

Darmawan Salihun has been focusing on BIOS-related security research since 2002. He has published papers on BIOS reverse engineering, BIOS code injection techniques, BIOS hacking, Plug and Play BIOS, and PCI protocol exploitation in the CodeBreakers Journal. In 2006, he wrote the BIOS Disassembly Ninjutsu book which covers the result of his research on BIOS security. His research on BIOS and UEFI security continues to this day. He is also a researcher with InfoSec Institute.

30 responses to “NSA BIOS Backdoor a.k.a. God Mode Malware Part 1: DEITYBOUNCE”

  1. rommelfs says:

    Hash or it hasn’t happened.

    • anon says:

      Rootkits hide themselves – you cannot “hash” without physically extracting the firmware using an attached chip reader (assuming they’ve not defended against that approach too – which they may well have done).

      • Menachem wuz hear says:

        BIOS? Unsolder the IC (a serial flash likely), connect it to a reader or an Arduino, and pull out the code. Publish the code, and highlight where it varies from OEM.

        Or it’s all just science fiction.

        • x says:

          “hash or didn’t happen” is ridiculous.

          sure, actual code would be nice…lack of it does not prove anything.

          are you saying the method is not sound?
          are you saying the hardware is not capable?
          are you saying windows would prevent such an attack?
          are you saying antivirus of the era would detect such things?

          there is more proof such things exist than not. prove it is not true, prove how such a thing could not be, if you disbelieve.

          “hash or i dont believe” is just blind faith.

          might as well say “the flying spaghetti monster disagrees.”

          “anyone have actual code?” is helpful. “how much of this is conjecture and how much is based on actual code?” is helpful.

          baseless accusations, without pointing out specific flaws, is just whining.

  2. tom says:

    Thank you for this — an absolutely fantastic article that is very clearly written, well-documented and broadly accessible. I posted the link over at Bruce Schneier’s site (he provides a forum for folks going through the ANT catalogue one-by-one). https://www.schneier.com/blog/archives/2014/01/ for DeityBounce.

    I wonder though if GodSurge is that similar to DeityBounce, as you suggest in the first paragraph. It again is restricted to Dell PowerEdge servers but requires a large FluxBabbitt hardware implant and exploits the JTAG debugging interface. The best on JTAG seems to be at http://www.alexforencich.com/wiki/en/reverse-engineering/jtag/start

    The other items in the ANT catalog mentioning BIOS are IRONCHEF, SWAP, STUCCOMONTANA, SCHOOLMONTANA, SIERRAMONTANA, SOUFFLETROUGH and possibly GOURMETTROUGH and FEEDTROUGH

    I hope you are able to take a look at some of these and write additional articles at this depth.

  3. Darmawan Salihun says:

    Hi Tom. This article is just the first part. I’ll try to cover as much and as fast as I can. AFAIK, GodSurge is an entirely different kind of attack. There is at least one that is quite similar to this. But, I won’t spoil the article, because it’s the next one in the pipeline :-).

  4. tom says:

    I’ll be checking in for next article … the pace of exposition and background you provide make it possible for a motivated but initially ignorant person to get up to speed in an area that is rarely explained well. So thanks again for generous sharing of your knowledge — the internet at its best.

    You are definitely the ‘go-to’ guy for analysis if this stuff is ever located on an actual target computer. With the TCP port 32764 affair, online tools quickly showed up that allowed people to see if theirs was open. Now we have open source tools like ZMap that can scan the entire internet for certain attributes in an hour. Just thinking out loud, can we find ways to globally rid the world of these implants?

    Here is that amazing tutorial on using JTAG to install malicious persistent code on hard drives that I had intended to link to above.

    http://spritesmods.com/?art=hddhack&page=3

  5. Matthew Beddoes says:

    Thank you for this, i now understand how it works and can attempt to work out how to fix it.

  6. Darmawan Salihun says:

    Thanks for the link Tom. I actually prepared the research on the HDD firmware circa mid-2013 but stopped short due to other urgent work. There is other way to get to the HDD firmware but it must not be corrupted in the first place. Anyway, this BIOS stuff is a weekend kind of research since in the college.

  7. Darmawan Salihun says:

    There is one topic missing from the analysis above, i.e. the “kill switch”/”self-remote-wipe” to remove the malware just in case the operation got botched. I’m going to cover this topic in the next installment.

  8. Darmawan Salihun says:

    “kill-switch” is a standard mechanism in military electronics to prevent adversaries from knowing your technique.

  9. anon says:

    All HP products also have an extremely easily exploitable backdoor – their iLo firmware leaks the iLo administrator credentials over the IPMI port, giving anyone an over-the-net method for remote-modifying server firmware.

  10. Vitor says:

    Hi Darmawan Salihun,

    I work developing a package for Linux that queries the state of a device with SMI. The main function of the kernel module is below. I’d like to ask for your help to understand what exactly the code does.

    In short, the line “out %%al,$0xb2nt” is to invoke SMI, but the line after that is not clear: “out %%al,$0x84nt”. Could you provide anything in the direction to understand that? The site of development is “https://launchpad.net/i8kutils”.

    static int i8k_smm(struct smm_regs *regs)
    {
    ktime_t calltime, delta, rettime;
    unsigned long long duration;
    int ret;

    calltime = ktime_get();

    int rc;
    int eax = regs->eax;

    #if defined(CONFIG_X86_64)
    asm volatile(“pushq %%raxnt”
    “movl 0(%%rax),%%edxnt”
    “pushq %%rdxnt”
    “movl 4(%%rax),%%ebxnt”
    “movl 8(%%rax),%%ecxnt”
    “movl 12(%%rax),%%edxnt”
    “movl 16(%%rax),%%esint”
    “movl 20(%%rax),%%edint”
    “popq %%raxnt”
    “out %%al,$0xb2nt”
    “out %%al,$0x84nt”
    “xchgq %%rax,(%%rsp)nt”
    “movl %%ebx,4(%%rax)nt”
    “movl %%ecx,8(%%rax)nt”
    “movl %%edx,12(%%rax)nt”
    “movl %%esi,16(%%rax)nt”
    “movl %%edi,20(%%rax)nt”
    “popq %%rdxnt”
    “movl %%edx,0(%%rax)nt”
    “pushfqnt”
    “popq %%raxnt”
    “andl $1,%%eaxn”
    :”=a”(rc)
    : “a”(regs)
    : “%ebx”, “%ecx”, “%edx”, “%esi”, “%edi”, “memory”);
    #else
    asm volatile(“pushl %%eaxnt”
    “movl 0(%%eax),%%edxnt”
    “push %%edxnt”
    “movl 4(%%eax),%%ebxnt”
    “movl 8(%%eax),%%ecxnt”
    “movl 12(%%eax),%%edxnt”
    “movl 16(%%eax),%%esint”
    “movl 20(%%eax),%%edint”
    “popl %%eaxnt”
    “out %%al,$0xb2nt”
    “out %%al,$0x84nt”
    “xchgl %%eax,(%%esp)nt”
    “movl %%ebx,4(%%eax)nt”
    “movl %%ecx,8(%%eax)nt”
    “movl %%edx,12(%%eax)nt”
    “movl %%esi,16(%%eax)nt”
    “movl %%edi,20(%%eax)nt”
    “popl %%edxnt”
    “movl %%edx,0(%%eax)nt”
    “lahfnt”
    “shrl $8,%%eaxnt”
    “andl $1,%%eaxn”
    :”=a”(rc)
    : “a”(regs)
    : “%ebx”, “%ecx”, “%edx”, “%esi”, “%edi”, “memory”);
    #endif

    rettime = ktime_get();
    delta = ktime_sub(rettime, calltime);
    duration = (unsigned long long) ktime_to_ns(delta) >> 10;
    printk(KERN_DEBUG “i8k_smm function took %lld usecsn”, duration);

    dump_stack();

    if (rc != 0 || (regs->eax & 0xffff) == 0xffff || regs->eax == eax)
    return -EINVAL;

    return 0;
    }

  11. Darmawan Salihun says:

    ‘@anon: IPMI has been in the radar of BIOS/UEFI security researchers for some time :-).

    @vitor: I’m not quite sure whatport 0x84 is used for. It’s probably system specific. Haven’t looked into AMD BKDG as well. Probably, it’s in there somewhere.

  12. Peter says:

    Will this malware be able to infect an OS that is initialized using SINIT/SENTER?

  13. Darmawan Salihun says:

    ‘@peter: I’m not sure if the exploit payload is capable to infect such OS. However, if by chance NSA breaks the hash protection via some sort of “backdoor” in the SHA-1 checksum. Then we’re out of luck.

  14. jason says:

    Have been suffering from persistent attacks for 15 months and your article was very very helpful. If you still want samples from BIOS (and PCIe expansin ROM also??) – then do advise.

    1. If you can tell me how to read the firmware from harddiscs then that would be very helpful.
    2. How is best protection against IPMI achieved? Deleteing it from Windows entirely and remove CMD file – or?

    Kind regards

  15. BadBIOSvictim says:

    Jason, offered to give BIOS and PCIe expansion ROM samples. I would like to offer them too if there is an easy how to guide. Otherwise, I am offering my Toshiba laptops that were interdicted to anyone interested in conducting forensics and identifying the implant. IThe implant may be similar to BULLDOZER. My email address is bluelotus@openmailbox.org. Thanks.

  16. No says:

    the ANT catalog was not a snowden leak, probably the product of another leaker.

  17. Dave Gilbert says:

    This article seems to assume that all the code being injected runs on the x86 side of things, either via Int 13 or SMI, but since the PERCs have a programmable RAID controller (that I think was an ARM or something non-trivial) is it possible it’s actuallly running the code on there? Then it could inject blocks into the hosts memory via boot without ever showing any change to the discs, and indeed it might only return ‘special’ versions of the blocks in well defined boot sequences and not during a disc examination.
    Especially on older PCI systems, I assume the RAID controller can DMA interesting bits of RAM without the x86 getting involved.

  18. buckwii says:

    I am quite sure at least one of my machines is infected. It has the DELL A02 bios. Could you let me know what kind of log I can produce so you can give me your opinion? I am only running Linux distros at the moment. Mint 15 is installed and i also use a Live Debian disk and a Parted Magic disk. Thanks

    email ham.hamlin@aol.com

  19. Paolo says:

    A PCI option ROM shouldn’t be allowed to write arbitrary stuff to SMRAM (in fact I think this is forbidden in the super-complicated UEFI SMM architecture). So is DEITYOUNCE, at least to some extent, exploiting a vulnerability of the Dell SMM code?

    • Matt says:

      ‘@Paolo, Dell didn’t make the switch to UEFI until a little bit after that Intel product generation. For a legacy system, there is no spec on getting stuff into SMRAM. BIOS could have a single image that gets created at built time that it loads then locks the door behind it. Others could have modules that add handlers to SMRAM sort of like is covered in one of the UEFI PI specs IIRC. Dell likely had a modular approach in their BIOS that allowed it to bet exploited like this. The exploit code would need to know the ‘calling convention’ used by the functions that load handlers as well as being able to load them. Remember that this is all in x86 16 bit assembly so there really aren’t any standards. The NSA would have had to put in a LOT of hours reverse engineering the BIOS and the RAID controller firmware. That’s why the hardware is so specific fort this malware. But a data center with lots of identical servers that carry a lot of traffic would make it a worth while effort.

  20. Smiley says:

    Thanks for this article. Our model Dell’s are in there. This is the whole reason why we are no longer buying anything Dell for our business or employees, forever.

    • bug menot says:

      Too bad this is valid for almost any system design ‘out there’. If Dell was more honest, they’d offer some kind of advice on detecting the exploits out of the systems (say, EPROM reader with clip-on [solderless]) adapter. Wrong checksum = possibly infected.

  21. SneakerNet is not a program term (thus no capitals) but a slang term of the movement of data by physical means, as you mention. More interestingly, the term is typically used when referring to moving data between networks of different classifications.

    For example, “this document was done on SIPR but there’s nothing classified as SECRET and I need to email it. I ought to SneakerNet it down to NIPR.”

  22. Matt says:

    The BIOS on those Dell servers is almost certainly legacy. It took them a little while to switch to UEFI.
    The assumption of a 1MB flash part might be right. Larger parts are routinely in use for BIOS today, but they use a chipset feature called descriptor mode on Intel platforms to share the part for multiple components on the system (such as the LAN controller).
    UEFI secure boot would likely have stopped this dead in its tracks. PCI device still have option ROMs, but they are executable images that follow the UEFI driver model. And with secure boot enabled, they must be signed. It would be interesting to learn of any weaknesses in the signing process though.
    The same goes for the boot loader used by the OS for IPL. It’s not in wide use yet and the public has been mistrusting of it (the argument is that the system could theoretically be used to lock out certain OSes by an OEM being payed by a competing vendor, but that’s an issue that should have been addressed by now).
    The switch to UEFI, at least for Intel based systems should be pretty much complete at this point. I’m not sure about AMD platforms. Has anything that targets UEFI specifically come to light?

  23. IRATEMONKEY says:

    I have a desktop computer, call it PC-A that in the past I have on at least three separate different occasions reformatted from scratch (with at least a one pass zero using killdisk) the HDD each time before installing Windows 7 64-bit onto the PC-A.

    The very first thing I would do after reformatting the PC and reinstalling Windows would be to install TrueCrypt 7.1a and then do a full disk encryption on it before doing anything else. (including before installing any device drivers or connecting it to the network, etc)

    Those who have used TrueCrypt full disk encryption knows that it forces you to burn a rescue disk before using FDE. Since I don’t want to waste a disc each time, I’ve always downloaded and used WinCDEmu to bypass that TC requirement.

    However, recently, (and I tried this on three separate occasions, each time totally starting from scratch) when I reformat,wipe and after reinstalling Windows on PC-A, I notice that when attempting to install WinCDEmu that right after I click install, I get a weird error stating that “Microsoft Register Server has Stopped Working” and details show a “BEX” error related to DEP, referencing WinCDEmuContextMenu.dll_unloaded

    I have made absolutely ZERO hardware changes, no BIOS or firmware upgrades. Every time I have used the exact same Windows 7 DVD-ROM to install the OS via the bootable disc, the disc itself is fine with no scratches. I have also consistently used the exact same version of WinCDEmu and checksum it each time to make sure there is no bit-rot or file integrity issues. I do the same for TrueCrypt and use the exact same version of TrueCrypt. As a matter of fact, since I’ve done the exact same procedure so many times and I know TrueCrypt will ask for to burn a rescue disk, the very very FIRST thing I do after a fresh install of Windows 7 is to install WinCDEmu 3.6 even prior to installing TrueCrypt itself.

    I even tried the SAME Windows 7 64bit DVD bootable disc on another computer (call it PC-B) that I have that is airgapped and never connected to the network at all, and used the EXACT same version of WinCDEmu resting on the exact same external usb storage medium with no problems and don’t get the error messages.

    So, my procedure is EXACTLY the same, nothing has changed. Prior to the suspected infection, I had at least THREE different times used the same procedure with the exact same software and on the exact same hardware configuration (PC-A) and never had any issues or errors.

    Now, after the interdiction, I still use the exact same procedure, exact same hardware, exact same software and yet I get the persistent error messages. As a means of test/control, I even tried the exact Windows DVD install disc and the exact version (checksum) of WinCDEmu 3.6 on TWO seperate computers, one that is airgapped and another one that is not airgapped and neither of them have any issues nor give the error messages.

    And on the infected machine, when I try to proceed with the FDE and encrypt the host protected area, it will not work. It seems to work but the next time I reboot the computer to do the “test”, it does not recognize my password even though I am 100% sure the password is correct. In addition, the harddrive is a standard Seagate HDD, and this is all commodity hardware, but when I moutned the harddrive to a different machine, it would not correctly recognize it and I would have not been able to have access to it to clone the drive or extract any data. It seems to only work when mounted on the original device.

    This is something I’ve never encountered before. Since I do at least a “one pass zero” to wipe the entire harddrive each time prior to reinstalling Windows, since there has been no hardware changes, and since I always install WinCDEmu prior to making any changes to the newly installed computer OS (prior to connecting to the Internet, or updating drivers, or installing any other application, etc) the only thing that can possibly explain this bizarro behavior is that I’ve been interdicted and attacked by an advanced persistent threat such as the NSA.

    Screenshots:

    image.bayimg.com/0a91bdcdb399dbf4322f89582af86f3cf70998db.jpg

    image.bayimg.com/b42874a45ecde2e24940d33511c7ba81a560e407.jpg

    I would not have caught this had circumstances not converged:

    1) I am a bit OCD when it comes to reformatting computers. I tend to do it way more often than necessary. However, repetitive motion develops muscle memory. When you’ve been doing something Nth times, and on the Nth+1 and subsequently every time after that something has changed, you easily take note.

    2) After installing Windows 7 from the same DVD each time (for consistency sake) the first order of business is always to install WinCDEmu and then TrueCrypt 7.1a. Of course doing install I don’t have any other usb or connections, the PC doesn’t have even have wifi functionality, and no Ethernet cables are plugged in. I could see how I might have gotten an error message if I had messed around in msconfig/services.msc/gpedit.msc or had installed other software or had updated or installed firmware, BIOS, and operating system and software drivers, but none of these are the case.

    3) The really odd thing is this, seeing how I was unable to make a clone of the drive (even using hardware methods), as a test I mounted it to a different computer to see if it would let me install Windows 7 onto that harddrive. Using the boot-able Windows 7 disc, it would boot to the first initial Windows ‘energy logo’ screen (right before the screen where you choose to install or upgrade Windows, etc) and it would merely stay there for 60 seconds or more… just hang there and do nothing at all. Then when it finally got past that part, after at least about 60 seconds, it would get to the install/upgrade screen, I choose to do a fresh install, and it reports back to the disk is not bootable and that Windows can’t be installed on this disc (even though it is recognized by Windows and in the BIOS).

    4) So on one of the tests, I got impatient and abruptly cut power to the computer while it was stuck at the Windows bootup screen (prior to the install/upgrade options screen) on that test computer, then the next time I power cycled it and tried to restart/ turn it on, it would not do anything at all, as if the BIOS was damaged or acting like had the power been cutoff during the flashing of a BIOS.

    How is this possible? Can the DVD-ROM drive’s firmware itself be infected? If there is a firmware malware on the infected HDD, and I mount it to another clean machine, and try to install Windows 7 from DVD (the DVD obviously can’t be contaminated) how could it possible get the chance to jump from the harddrive or the harddrive’s firmware onto the BIOS or other components of the other computer?

    • bug menot says:

      “seeing how I was unable to make a clone of the drive ” I’m highly suspecting some ATA password glitchiness, at this point. Some computers set this to ‘help you’. :/ It hasn’t set it randomly (where drive becomes useless) in this case, but some bugs in firmware or hardware will do that, too.

  24. IRATEMONKEY says:

    Screenshots:

    image.bayimg.com/0a91bdcdb399dbf4322f89582af86f3cf70998db.jpg

    image.bayimg.com/b42874a45ecde2e24940d33511c7ba81a560e407.jpg

Leave a Reply

Your email address will not be published. Required fields are marked *