New "Mebroot" MBR-Modifying Rootkit Analyzed

I Don't Believe in Imaginary Property writes "F-Secure has a writeup on a highly obfuscated, advanced new rootkit they recently discovered which uses a number of old techniques like MBR modification in new ways. It modifies the MBR, starts up its downloader with an ntoskrnl.exe hook set to nt!Phase1Initialization (which conveniently removes it from memory afterwards), and hooks IRP_MJ_READ and IRP_MJ_WRITE in disk.sys to hide itself in empty sectors. It also bypasses software firewalls by calling the NDIS API directly, using a 'code pullout' technique to load just the parts of ndis.sys that it needs. F-Secure believes it was written by professionals who are after financial information."

Comments

Re:Would these issues affect EFI to the same degre

[jmorris42]

> ...would the introduction of EFI bring greater barriers to this sort of exploit...

EFI is more complex than the simple boot block / partition table that fits in a single disk sector. More complex means fewer people who will fully understand it, more bad implementations in firmware with potential security problems, etc.

Of course there are good reasons for it to replace the MBR/partion table, like running into a brick wall on the max drive size.

Re:Would these issues affect EFI to the same degre

[sigxcpu]

there are proof of concept EFI rootkits out there
http://it.slashdot.org/article.pl?sid=06/01/27/1327228

From the article

[Corporate Troll]

From the article:

In fact, it is quite surprising that it's possible to write to the MBR from within Windows to begin with.

I'm pretty sure you can only do that when you're Admin.... Use "Limited User" for crying out loud!

Re:DOS Viruses

[jfim]

And then you have the obvious - why is the OS allowing you to modify the MBR without appropriate rights and/or why are users running as users with the rights necessary to do this? This is STILL a problem harking back to the DOS days - everyone as administrator. With a new twist - the average user hasn't needed to BE administrator for quite a long time now.

Except in Vista, this isn't true. You need to either have elevated privileges(or have disabled UAC so that everything runs as administrator) to be able to write to the MBR, at least according to this website. Of course, UAC does not mitigate the issue if they attach to a publically available installer(say kazaa-super-deluxe-installer.exe), since you'll need elevated privileges to run the installer and thus will click "Accept". However, since writing to the MBR is a highly unusual operation, they could bring another box that clearly marks the operation as unusual before allowing the write to the MBR.

Also, since the article mentions that the rootkit does not modify the registry, it would appear that all that is required to remove it is to do a "fixmbr" from the installation CD to overwrite the MBR with a clean copy(which is corroborated by Symantec).

Re:Would these issues affect EFI to the same degre

[Hal_Porter]

Of course there are good reasons for it to replace the MBR/partion table, like running into a brick wall on the max drive size. Actually you don't need to change the Bios to get that. Currently the Bios loads sector 0 into memory and jumps into it. There's no reason why sector 0 couldn't be a GPT MBR. Pre GPT people worked out ways to allow for 64 bit LBA addresses in the partition table

http://home.no.net/tkos/info/embr.html

And the Bios has supported 64 bit LBA addresses in int 13 for ages, so there is no disk size problem for a very long time - probably many decades. Seriously, you don't need EFI to get 64 bit LBA support.

The fix is free:

[Futurepower(R)]

At the bottom of the linked article, there is another link: Gmer -- MBR. At the end of that long technical article it says: "Rootkit removal: To remove rootkit from infected machine you can simply use "Recovery Console" command: fixmbr."

To use it, you first go into the Windows XP Recovery Console. Then run FixMBR /? for parameters. Save the MBR (Master Boot Record) first.

Here is a discussion on the Microsoft web site about tools for fixing the MBR without the Recovery Console. I've never tried them; I've always used the FixMBR utility that comes with the Recovery Console.

FIXMBR -- trust chain

[sconeu]

Yeah, but you've got to boot off of CD to use it, otherwise you're suspect, since you've booted off the bogus MBR to get to the recovery console.