8

If a system becomes infected and does not have any other storage units besides the one hard drive.

Is it there any other way for a rootkit to stay on the system besides infecting the BIOS OR the MBR of said drive after a 'nuke from high orbit'?

8

Normally, no. Not in a self-bootable area. You might have data not overwritten by the disk wipe, in "out-of-band" areas, but those areas aren't normally accessible, and if made so, they also become accessible to the wipe.

Theoretically, for very large values of theoretically, yes. In some hard drives, there may be a third memory area that is accessible, self-booting and capable of hosting a complex malware (as complex as, say, a minimal Linux kernel).

(Update: the above trick has been reported in the wild by Kaspersky)

This area is normally not accessed (for programming) through the data cable by which the hard drive is connected to the host computer, but through a specialized JTAG connector which is only used during the manufacturing process.

Also, the programming instructions must be specifically adapted for the hard drive controller CPU chip; just as the same HTTP protocol may be "spoken" by a Motorola-powered old Mac or an Intel 80386, but the two CPUs won't ever "speak" the same language, so two disks from the same manufacturer may have an Avago chip, or a Marvell one - and they will require different and totally incompatible instructions.

The problem then is that the malware would have to be specifically targeted, and in most if not all cases, hardware physical access to the JTAG connector through a custom cable will be required. So a purely software malware would have no chances. Unless some programming backdoor had been burned in the firmware by the manufacturer, in order to save some bucks and do without the whole JTAG stuff. Which, predictably, it seems to have been the case.

A disk thus hacked is completely untrustworthy. Whatever you do to a hard disk from the SATA cable is actually no more than a polite request to the disk SoC to perform some action on your behalf. Untampered SoCs will obey (or lie to you to your advantage: for example reporting that a sector has been written instantly, while in reality it is being held in a write-back cache to increase performances). A tampered SoC might disobey and lie about it (and will do so, or there would no point in tampering).

You could (ask it to) overwrite the boot loader, read it back and receive an enthusiastic confirmation that it has been zeroed; (ask to) write a clean boot loader in its place, re-read it and receive a haughty confirmation that it has been written and committed. Then power cycle... and still have a malicious boot loader come out of the disk instead of the one you believed should have been there, thus bluepilling the system.

Of course, the malware should be aware of the operating system in use in order to infect it, and gain, through it, a more sophisticated access to files, network, keyboard and so on. It would do so by intercepting the operating system attempts to load its own code from disk, supplying instead modified code containing the infection routines. The modified code would need to be compatible with the operating system, and it would be powerless should the operating system self-check its own code, unless even more advanced techniques were used.

Actual probability is in the low noughts for any reasonably common scenario.

On the other hand... if you just received a brand new desktop as a token of NSA's appreciation for your work, then no - wiping the disk, zeroing its HPA and DCO and Gutmann-blasting every single sector it has, will not be enough.

2

If it replaced the BIOS, it could, through the Windows Platform Binary Table (WPBT), provide a malware stored there, reinfecting a Windows machine even after replacing the hard disk with a new one.

This is what was used by the lenovo rootkit from August 2015 to persist itself even after a clean reinstall.

1

Here's a discussion on Super User about host protected areas and Drive configuration overlays.

  • Host Protected Areas are typically not available to an operating system. Typically, manufacturers use them to hide recovery media and other utilities.
  • Drive Configuration Overlays are kind of the same deal, but this is used to configure the drive, ie. report on number of cylinders and features available on the drive.

Theoretically it is possible to store data on these sections, and it is not touched by a standard drive wipe. The Super User discussion touches on hdparm for this purpose. I do not know of any existing rootkits that use this technique.

  • 3
    BadUSB also deserves a mention here. A lot of laptop computers and motherboards have built-in USB "peripherals" (Bluetooth radios, webcams) which have the potential to do anything to your system while it's booting. Theoretically. For very large amounts of theoretically. (I really like this phrase, Iserni). Also, if you want to be paranoid, you have no idea what those chips on your motherboard actually do. Or that BIOS you just reflashed and you trust so much. – matega Jan 22 '15 at 1:19
1

Yes, at least a bootkit can do this, and now it transpires that it's easy;

John Loucaides and Andrew Furtaki have showed it with their Lighteater bootkit. They gave a speech ot CanSecWest titled 'How many million BIOSes would you like to infect?' The only way to get rid of it is to flash your motherboard.

Even changing the disk wouldn't do any good, as Lighteater exploits the BIOS flash protection, and is then able to reprogram it on its own, taking over your computer.

Currently, the only protection against this is to flash your BIOS/UEFI and update as often as you can.

Also see:

0

Yes if it is resident in your GPU Ram it can survive reboots & re-formats.

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.

Assuming the GPU malware is only memory resident and exists nowhere else, shut the system down (full power off) and that will cut power to the GPU.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.