So last night I had to go do an emergency cleanup on a friend's computer. It seems that Firefox 7 had some kind of vulnerability that allowed a variant of <a href="Remove Data Restore (Uninstall Guide).mht">this thing</a> to jump aboard.

Normally I wouldn't bother trying to remove something like this, as the safest course after a compromise is to do a clean reinstall of the OS and all programs. However, I and my friend are both really busy lately, and a cleanup was somewhat faster than reinstalling Windows. She knows not to type any important passwords or credit card numbers into that computer in the mean time.

This variant was mostly similar to the one described, except that it called itself "System Restore" instead of "Data Restore", and (this is the interesting bit) it was sophisticated enough to use the extra 2 or 3MB of space that's always left over on Windows machines (the Windows installer does this because if you convert a disk to Microsoft's "Dynamic Disk" format, it needs a little room at the end of the disk for metadata). It created a second partition for itself there, installed an obfuscated or encrypted boot loader/wrapper there (link -- here's the binary dump of that image. it has an NTFS header and sets its partition type to XX Hidden NTFS/HPFS to avoid showing up in Windows). It then marks this partition bootable and removes the boot flag from the main partition. It also modifies the Windows bootloader code in the master boot record in some way -- I unfortunately didn't get a dump of that.

To fix the extra boot partition, I did the following:

- zeroed it out with dd if=/dev/zero of=/dev/sda2
- deleted the partition and restored the 'bootable' flag to the main one
- booted to the windows install cd, into the recovery console, and ran fixboot and fixmbr

Given the level of sophistication, I was surprised that it didn't do more trickery in the realm of Windows -- its only autorun triggers were a hidden batch file called "santa.bat" in the start menu Startup folder (for the current user only), and an autorun entry in HKLM\Software\Microsft\Windows\CurrentVersion\Run. The santa.bat script contained two instructions: it renamed a .txt file in system32 to .exe, then added the autorun entry to the registry. I'm guessing that the boot-time code was responsible for injecting this "text" file into the filesystem once per boot, so that it would always come back.

This beasty did not, however, do any of the really tricky .exe file handling hijacks (in HKCR\exefile\shell, for instance). That was surprising, because the ones that do that are a bit harder to clean. I guess the author had faith in their boot-time solution, as none of the removal instructions even note the existence of the extra partition, or the modified MBR code.

Oh, this thing is also smart enough to touch the file modification dates on its components, so you will not be able to find all of its related pieces by just searching for files created in the last day or so.

There is one other bit to watch out for with this thing: it turns on form completion history in Internet Explorer. This means that it quite possibly contains credit card number–scraping code, that might send interesting parts of the form history to some command & control server somewhere.

As I said at the beginning, removing an infection like this generally isn't the best idea -- you never know if there's a secondary payload that uses entirely different means of hiding and provides no outward symptoms. Once a computer has been infected, it should be blanked and rebuilt, and have its user data very carefully restored. No executable content should be imported from the compromised computer after the OS has been reinstalled.

Finally, I want to add that given how smart malware writers have finally gotten, we really need a foolproof way to ensure that BIOSes are not writeable by default. I would advocate a hardware switch for this purpose. Failing that, there should be BIOS gatekeeper logic that will only allow a flash update if no drives that were connected to the computer at last boot, are connected during the update attempt. That is, if you have hard drives A, and B, and DVD drive C connected to your computer normally, attempting to update the BIOS with *any* of those still connected should fail. This would prevent anything from OS-land from embedding itself in the BIOS, updates of which should almost never need to be done anyway. Emphasis on "should" -- our industry as a whole needs to slow down (a lot) and start doing some real quality control for a change. Something like a BIOS should be as simple as possible, and should be *extremely* rigorously tested before it ships.