SpiderLabs Blog

Detecting A Surveillance State - Part 3 Infected Firmware

Written by | Apr 9, 2014 12:16:00 PM

In this third installment of Detecting A Surveillance State blog series I will move away from hardware devices as discussed in parts one and two and talk instead about something harder to detect--persistent compromises made possible by BIOS or firmware modifications.

Again, the source used on how these devices worked was restricted to the public knowledge about them found on Wikipedia, and what was publically disclosed at 30c3.

In the leaks links above, they describe utilities used by some state actor spy agencies that would allow for persistent compromises on devices utilizing their own firmware or BIOS to prevent removal during an OS reinstall or similar. These attacks can affect computers, network routers and even some hard drives.

The documents describing the programs I'm covering today do not explain how the infections would take place. The most common methods to infect a firmware or BIOS would be to access an already exploited system or intercept the device before the owners of the devices receive them (e.g.. supply chain attack) and install the infected BIOS or firmware. Since this portion of the attack is not known at this time, I will not cover specifics about how to prevent supply chain attacks or on the fly firmware/BIOS modifications.

The names of some of these programs are:

DIETYBOUNCE: Motherboard BIOS Infector
SWAP: Hard Drive Firmware Infector
HEADWATER, SIERRAMONTANA, and JETPLOW: Each of these are firmware backdoors that target popular networking hardware.

I've grouped these cross-platform infections together because they each typically infect a device or computer in a manner that is traditionally trusted and inspected for compromise. Keep in mind, they're just not normally inspected. This doesn't mean it's difficult or impossible to access them.

For each of these infections, where applicable, pulling the chip and replacing it with a new freshly burned BIOS chip or compact flash card would be sufficient. If you're curious, compare the data on the untrusted chip with the image available from the manufacturer. We can assume that a spy would not have a secret implant that has infected every available image for a device. That would be both too costly and easily detected by employees at the manufacturer who work on the project.

When dealing with built-in firmware it's a bit more difficult than pulling and replacing. You will need to re-flash the device using an operating system that is not at risk of being attacked by the infected firmware. Due to the lack of hard evidence here, it's hard to recommend an approach. You could use a more obscure OS that the firmware wouldn't know how to attack. You could boot the device into a low level OS in hopes that the firmware infection isn't able to protect itself. Or, you could wire in a debugging header to the device (such as JTAG, if available) to read or write the firmware on the device to clear things up for good.

These methods are pretty complicated even for experienced computer users. The time required to read, compare and/or write the data to the chips make it an improbable step to take unless you absolutely knew it was a necessity anyway.

Wow, three down already. Handling infected firmware wasn't too hard. Next time we will get in to something entirely different; Cellular network attacks. See you then!

  • Read part one of this series here
  • Read part two of this series here