36

The well-respected security consultant Dragos Ruiu is reporting that he has been infected with mysterious malware that can survive re-installation of the OS and re-flashing of the OS. In other words, he has taken an infected machine, wiped it, airgapped it, reflashed its BIOS, replaced its disk drive, installed a fresh OS -- and after booting the new OS, it was still infected.

How might such an infection remain? What mechanisms could malware use, to keep its hooks in a machine and survive both re-flashing of the BIOS and re-installation of OS?

I'm of course interested in possibilities for what mechanism Dragos' mysterious malware might be using, but let's not stop there. More broadly, I'm also interested in what mechanisms malware could use to survive wiping of the disk and flashing of the BIOS. What schemes could malware use for this purpose?

This question has implications for how we recover from infection. A standard saying is that, once you've been hacked, "The only way to be sure is to nuke it from orbit" -- in other words, you gotta wipe the hard drive and re-install everything from scratch. Maybe the lesson from this mysterious malware is that even "nuking it from orbit" isn't enough. So, to understand what we need to do to restore an infected machine to a known-good state, it'd help to understand all of the ways that malware could stay resident even after you replace the hard disk and re-flash the BIOS.

More background: this page summarizes what Dragos has reported about the mysterious malware he was infected with. See also this outstanding answer from Gilles.

Community
  • 1
D.W.
  • 98,860
  • 33
  • 271
  • 588
  • 2
    Perhaps there are hooks in PCI devices (array controllers) that are read/write or even printers that expose hacks in the drivers that interact with it. – makerofthings7 Oct 31 '13 at 21:23
  • @ThoriumBR, thanks for your comment, but that's not relevant here. My question is about whether it is possible for malware to persist across re-flash of the BIOS and re-install of the OS. Communication is a separate issue, and this comment thread is not the place to get into a general discussion about BadBios in general or the credibility of the incident. (That said, it's certainly not impossible; if you read the links, you'll find a quote from Graham explaining one way it could be done. But please don't discuss this here; it doesn't belong in this comment thread.) – D.W. Apr 30 '19 at 22:15

4 Answers4

43

As for how it may happen that reflashing the BIOS does not eradicate the malware, we can hazard a few guesses:

  • The reflash operation is under control of... the BIOS, so the infected BIOS only pretends to do the reflash (or reinfects the new BIOS immediately afterwards).

  • Another flashable firmware in the machine is also infected, and when either it or the BIOS is reflashed, the still infected firmware reinfects the other one. Any device with DMA can hijack the live machine at any point, and most devices with a firmware have an onboard CPU which would be up to the task (GPU, hard disks...).

  • The disk firmware is infected, and inserts malicious code in the boot code which reinfects the BIOS. (Not sure it matches the symptoms, but that's a possibility.)

The common theme here is that all the reflashing is done while part of the machine is live, so there is a chicken-and-egg: you cannot securely reflash from a machine which runs infected code (even indirectly, in the case of a DMA-able device with its own CPU), but if the machine is off you cannot reflash either. Ideally, the BIOS chip would be removed from the machine, reflashed from another device (without booting it, of course), and then plugged back. But these chips are usually soldered... We know how to make pluggable chips -- e.g. none other than the CPU, so it is doable without killing I/O performance. But I imagine that soldering is cheaper for the manufacturer.

Maybe manufacturers could add some JTAG-like ports which would allow reflashing a chip soldered in a powered-off board (really powered off, with the power cord physically removed).

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • Can JTAG even operate for a powered off system? I know that at least Intel's motherboard JTAG requires the system remaining on. You can use an SPI programmer to flash a powered-off BIOS chip, though, but that's not a debugging port like JTAG. – forest Dec 13 '17 at 06:12
2

Seems completely implausible!

If we assume that the reports are accurate (and I'm uncertain if us observers are qualified to make the assumption that Dragos is being truthful, not mistaken, and not coerced?), then it only leads to three options:

  1. The storage media (HDD, SSD, USB drive) are not being completely wiped
  2. The BIOS is not being properly flashed
  3. Other computer components are being used as a reservoir where the virus lies dormant

I'm happy to accept that #1 is unlikely, at least for magnetic media.

Option #2 may be possible if the flash is being done on the infected system (which may(?) be able to reject the flash and give the illusion of success). Proof of concept has been demonstrated at Black Hat 2013 by Butterworth, Kallenberg, and Kovah [PDF].

Proof of concept of #3 has been demonstrated by Brossard at Black Hat 2012, and is perhaps the most plausible of the already quite rare scenarios above. A quick read of the links provided doesn't appear to show that this angle was considered by Dragos.

Security researcher Jonathan Brossard created a proof-of-concept hardware backdoor called Rakshasa that replaces a computer's BIOS (Basic Input Output System) and can compromise the operating system at boot time without leaving traces on the hard drive.

Brossard, who is CEO and security research engineer at French security company Toucan System, demonstrated how the malware works at the Defcon hacker conference on Saturday, after also presenting it at the Black Hat security conference on Thursday. ... Rakshasa replaces the motherboard BIOS, but can also infect the PCI firmware of other peripheral devices like network cards or CD-ROMs, in order to achieve a high degree of redundancy.

So I suppose the best thing to do for high value targets is to rebuild from known good media onto known good hardware! Not as bad as it sounds, because these days hardware is cheap, especially for said high value targets.

scuzzy-delta
  • 9,303
  • 3
  • 33
  • 54
0

It's unclear from your question if the hard drive content was properly deleted. Re-installing the OS certainly doesn't guarantee that the drive has been wiped out. If the drive was pulled out of the infected computer and replaced or properly wiped out on another machine then it would be plausible to ignore the possibility that malware is still present on it. Firmware and BIOS malware have little use outside of a narrow targetted attack or proof of concepts.

user94592
  • 67
  • 3
-1

The rookit may reside in ring -2, or the SMM, these infections have been around since at least 2008. This is true despite the downvotes, as is the rest of what is in here. I am told, people here don't like security through obscurity (in reference to the memtest on boot, as seen below)

[update after the dislike] If it is SMM malware, and it survives OS/reinstall, it could be an infected bios or firmware, which you may fix with either a normal flash, or SPI flasher, the former if the virus isn't capable of preventing an update; You should be able to determine if this is the case if your update fails or you see no change in the bios version after the fact. If it is GPU malware, make sure you power down your PC, and maybe even unplug it from the wall, this will clear GPU ram and any GPU resident malware, if it is not embedded in your video cards firmware. Otherwise re-flashing your GPU and or SPI flashing it may be necessary. The same goes for hard drive firmware as well. If the harddrive's chipset was infected, likely via jtag, you will likely need to replace the drive itself, research into this is ongoing. If it is NIC card malware embedded in the firmware, you may have to re-flash that as well, or disable your onboard NIC in the BIOS and buy a OTP flashed NIC (One time flash), which is flashed once on the assembly line and does not allow for future re-flashing. Just to save you the headache, The RTL8111G/RTL8111GS features embedded One-Time-Programmable (OTP) memory. Like the UGreen Gigabit Ethernet PCI Express PCI-E Network Controller RJ45 Adapter link

If your motherboard itself or any of its components have malware embedded directly on the chips from some point between the manufacturing process and landing in your residence, you may have to remove each piece of hardware one at a time and test until you determine which component is causing the problem... if it is on your motherboard itself, you may have to buy a new motherboard.

One thing I would suggest is you wipe your ram on boot through bios with the extended memory test, memtest or "slow boot" option, this zeros the ram by writing to every sector, similar to memtest86x, but it happens right on post and with typically only one sweep. It may also clear data malware has injected into ram during the post, from an infected firmware module or chipset, however unlikely this scenario may be, and may allow you to complete functions if they were are blocked by malware.

Tyler
  • 417
  • 5
  • 13
  • Malware that _literally_ persists in RAM after reboot is rendered immediately unreadable for multiple reasons. First, the unallocated memory is never read, and second, LFSR-based memory scrambling destroys the malware. It's impossible for malware to use RAM alone for persistence across reboot. So this answer is wrong. – forest Mar 22 '19 at 23:55
  • Can you point to some sources please? Thank you! Also, do all motherboards perform LFSR-based memory scrambling, even systems that date back to 2008, or say 2002? Also take note of the updates to my answer. Some portions of my answer may be, however it may have been SMM malware that had infected his device. I will update it accordingly as I learn more. – Tyler Mar 22 '19 at 23:57
  • 2
    There are no sources for that in the same way there are no sources that prove that malware cannot hide in the screws holding the chassis together. However, you can read about memory scrambling [here](https://www.researchgate.net/publication/3943089_Address_and_data_scrambling_causes_and_impact_on_memory_tests). Even if memory scrambling is not used though, unallocated memory (at boot) is simply ignored. It's not read and executed which would be necessary for malware to persist. A booting system doesn't just say "hey, let me try executing everything at every possible offset and any possible"... – forest Mar 22 '19 at 23:59
  • 2
    "fragmentation just in case valid code exists here!" The same is true with hard disks. If you format a disk, even without securely overwriting it, any malware on the disks will be rendered harmless. As for SMM malware, that does not persist across reboot either _unless_ the BIOS is modified to execute malicious SMM at each boot, in which case it's not exclusively memory-resident. – forest Mar 23 '19 at 00:01
  • It may not grab onto the memory during post, malware might access that memory section by other means, perhaps an infected firmware or SMM. Also malware may write to empty/raw disk space, and be accessed that at a later time, this is why wiping the free space or running Trim on a harddrive/SSD can also effectively nullify any malware hiding in raw disk space. – Tyler Mar 23 '19 at 00:03
  • 2
    That would still require malware be stored somewhere outside of RAM. If it only existed in RAM, then a reboot completely destroys it. If the malware existed in the BIOS and simply stored some extra data too big for the BIOS in RAM (which I guess would be possible, though I've never seen it and doubt it exists), then enabling POST memory wiping would still be useless, since a compromised BIOS means a compromised POST process. Unless you have something like SRTM using a TPM to measure the BIOS, there's no way to keep yourself safe by using BIOS functionality (RAM tests, ECC initialization, etc). – forest Mar 23 '19 at 00:03
  • I hope you are right :) In the world of electronics however, and constantly evolving threats, I try my best to keep an open mind. I would not be surprised if firmware or chip-set based malware has been used to utilize the ram of a pc. – Tyler Mar 23 '19 at 00:07
  • 2
    You might want to read up on GPU-based malware persistence, which _can_ survive a reboot (well, a so-called warm reboot where power is not cut to PCIe devices and they do not enter D3 cold), since the GPU is not necessarily powered down and can perform DMA attacks against system memory once the system is back. – forest Mar 23 '19 at 00:09
  • How would you flush out this from GPU-memory? Do you expect a complete power down to be effective in this circumstance? This is one question I have been eager to find an answer to recently. – Tyler Mar 23 '19 at 00:10
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/91435/discussion-between-forest-and-tyler). – forest Mar 23 '19 at 00:11
  • Forest Said "GPU-based malware persistence can survive a reboot (well, a so-called warm reboot where power is not cut to PCIe devices and they do not enter D3 cold), since the GPU is not necessarily powered down and can perform DMA attacks against system memory once the system is back. – Tyler Mar 23 '19 at 04:39
  • Forest Said: My overall point is just that your advice to use POST memory tests is useless, since the malware in the BIOS can override that to protect whatever data it wants to keep in RAM." – Tyler Mar 23 '19 at 04:39
  • If the virus only was designed to write to memory during the initial post process, wiping whatever is in there could make the virus useless until you fail to run the memory wipe on boot, unless the programmers already thought of that and created such mitigation's mitigations; its still one of the few options people have – Tyler Mar 23 '19 at 05:21
  • 1
    Any malware advanced enough to persist in that manner would also be advanced enough that you could not rely on that kind of security through obscurity to protect from them. – forest Mar 23 '19 at 05:26