Slashdot Mirror
Boot Record Rootkit Threatens Vista, XP, NT
Paul sends us word on a new exploit seen in the wild that attacks Windows systems completely outside of the control of the OS. "Unfortunately, all the Windows NT family (including Vista) still have the same security flaw — MBR [Master Boot Record] can be modified from usermode. Nevertheless, MS blocked write-access to disk sectors from userland code on VISTA after the pagefile attack, however, the first sectors of disk are still unprotected... At the end of 2007 stealth MBR rootkit was discovered by MR Team members (thanks to Tammy & MJ) and it looks like this way of affecting NT systems could be more common in near future if MBR stays unprotected."
1) That's "Slashdot". -1 for capitalization, -5 for spelling.
2) Nazi is capitalized.
3) Your sig is an automatic Godwin. Might want to fix that.
4) You didn't end your sentence with punctuation. This one calls for a period.
5) Arrogant? You bet!
Hail Eris, full of mischief...
E pluribus sanguinem
Hen and egg. How does the virus get there in the first place. SOMEONE must first of all get it to execution. Malware doesn't suddenly jump in and exists. It has to be brought into the machine. A virus or trojan does jack when it just sits on your machine. It is a program. It has to be executed to do its "magic".
There are exactly three ways to get this done. First, remote (RPC) exploits, which is easy to defeat with a router that does not allow any packets in to sensitive ports. Second, exploits in programs. This is harder to secure, since you can never know whether your mail client or your web browser (or one of its myriad plugins) has such a vulnerability. Your best bet is to use something that has nearly no market share (and is thus not interesting for commercial malware users).
And finally, the user himself can execute it. And, believe it or not, this is the most used and most successful way of infecting a machine. In other words, the main security problem is not in the machine. It's in front of it.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Yeah, like something that could fit in a 512 byte MBR...
Why bother?
That's what this does. It modifies the MBR to load the virus as a driver out of a pair of sectors.
This already does whatever it wants. And the "files open" comment is non-sensical, the pre-boot environment has no concept of "open files", it's just a little 512 byte loader.
There isn't much Windows (or any) OS can do when it isn't running.
If you read the article (it contains scary things like x86 assembly, I know, but you can skip that) you'd see that the describe this hooks into the load routines used by Windows. By intercepting these calls and redirecting them, it prevents you from overwriting the MBR or even detecting that it's changed (to a degree). To fix this you have to open a clean environment (like the recovery console off the Windows CD) and have it fix the MBR.
Amazing how even with all we've got, things go back to the same kind of viruses that were written back in the days of DOS 2.
I wonder if this would be so easily possible with EFI based booting. OS X uses it. Vista SP1 supports booting using EFI off disks don't partitioned with the old DOS partition format.
PS: Whoever modded the parent as informative either doesn't know what they're talking about, is drunk, or is in cahoots.
PPS: Sorry. I've been looking for an excuse to use the word "cahoots" all day.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Alright, I get the defense in depth concept, but I don't consider it to be a severe vulnerability that the MBR is writable while Windows is running. I consider that to be a feature, one I wish Microsoft did more of -- for example, I can install Linux from a Linux LiveCD, or I can install a second copy of it on another partition, etc. As far as I can tell, OS X is similarly flexible -- it forces you to type your password, but it can deliver a firmware update from within the OS -- think equivalent to a BIOS update, so even earlier than the MBR.
So, to clarify: It's writable from userland, which is not the same as being writable by any user. If they have Admin access (which means you already clicked a "This program wants to modify your Master Boot Record, are you sure?"), you're already screwed -- kind of like how, on Linux, if they have root, you're already screwed.
In other words, it's possible to modify your Master Boot Record without rebooting your computer. This is a good thing.
What's more, this is not new. All that's new is that it's both in the wild (Blue Pill does the same thing), and that it's a rootkit (MBR Viruses have been around for a very long time now). If someone was trying to apply for a patent, you'd be jumping all over them with prior art...
Don't thank God, thank a doctor!
... to write to the MBR.
For all other sectors Vista prevents writes to raw disk sectors even with admin permissions.
Users withouts admin permissions/without elevation cannot write to the MBR in Vista.
Yes. That's all LILO, GRUB, NTLDR, and such do. They call the BIOS functions to read partition tables and such, load code from a specific place, and execute it.
You could easily install LILO on the last sector of a disk (or anywhere else, just a free sector you can protect from being used). Write a little tiny program that does nothing but read that sector into memory (having known the address ahead of time, finding that code is what makes GRUB and NTLDR slightly more complex than this), and execute it. LILO would then continue having no idea what happened before it.
Amazing little things, boot loaders. Check out the Wikipedia article on Master Boot Records. They talk about NTLDR where until XP/2K (when it got support for non-english error messages), the code was just a scant 139 bytes.
Read about some of them. LILO is simple (and kind of stupid) and fits in 512 bytes. GRUB is smarter, and works by loading more code that it finds using it's first stage (which is under 512 bytes). It's a little tiny OS that only uses BIOS calls to load another OS. That's why you can edit entires, add new ones, etc. That couldn't fit in 512 bytes (and still be useful on most computers).
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Whether it's a an MBR record or an executable file stored on a filesystem the firmware may understand, the concepts are the same. Any sane operating system will allow you to modify boot files (after all, how else do you upgrade early-execution code). Whether it's an MBR or a more sophisticate piece of firmware, the principle is the same. The question is whether users have been trained to always be administrator, or if they've been trained the more disciplined way where uncommon (at least should be)/privileged operations can only be executed at significant obious pain.
Under linux even, a number of distributions have on occasion ventured down the very dangerous/wrong approach of skipping user accounts and going all root for the sake of convenience. However, the mainstream usage of linux (and OSX) is thankfully non-root users, and as such any *serious* applications accomodate that usage pattern (with the bonus of being sanely multi-user.
Meanwhile, Windows heritage has been less optimal. The consumer oriented MS platforms right up until XP didn't have a meaningful non-administrator concept, as well as much of a multi-user concept. As a consequence, many application developers did bad things that would break (i.e. using registry entries that are machine specific rather than user specific, or even writing things like saved documents/games to the application Program Files directory. Win9x even provided relevant spots that would evolve to something meaningful, but without significant meaning, many third parties ignored it, especially after Win3.x training. XP was the first definitive wake up call to a WIDE variety of developers. Even so, the majority of users ended up being administrative users to make up for the gap (as well as having no easy automatic privilege escalation). Hell, even a customized preload I saw sets up one user, renaming the administrator user (and in fact, calls an un-renamed administrator account a security risk... indeed).
OSX made a clean break with OSX (relegating "classic" applications to a relatively severe sandbox"), Linux never had such an unclean history to overcome. So while OSX implementing clean privilege escalation, and Linux has been working on facilities that lend itself well to that (i.e. DBus). Windows XP did not make a clean break, and Vista didn't etiher, but Vista's UAC is an attempt at giving users a facility to do privilege escalation. It's annoying because of bad programs and bad habits. But non-admin default usage + UAC is the only way they have of maintaining a sane featureset without being considered so vulnerable.
It also doesn't help that so many Windows users see "click here for free smilies" and think it's a good idea to do so.
XML is like violence. If it doesn't solve the problem, use more.
The latter, because "Fuck off" is an imperative verb form and has nothing to do with adjectives.
Security by arrogance. That's a new one.