Slashdot Log In
Boot Record Rootkit Threatens Vista, XP, NT
Posted by
kdawson
on Mon Jan 07, 2008 09:41 PM
from the writing-to-zero dept.
from the writing-to-zero dept.
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."
Related Stories
Submission: Vista & XP Security Flaw - Rootkit exploit in by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Messed up (Score:5, Funny)
Re:Messed up (Score:4, Funny)
Therefore NT3.5 is W95's stepsister -- given that W95 is the legitimate heir of Win3.11. It turned out then that W95, who was a real pervert due to its dominant 16-bit gene, chkdsked his stepsister NT3.51 (they don't used words like "fscked" in that family, they have their own lingo), who begat NT4.0. Then NT4.0 and his aunt W98 both got drunk one night, and soon they gave birth to Win2K. Somehow at that point in the family tree, the 16-bit gene got culled out. But the inbreeding continues...
Parent
Re: (Score:3, Funny)
How is it different from LILIO and Grub? (Score:4, Interesting)
Re:How is it different from LILIO and Grub? (Score:5, Informative)
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 [wikipedia.org]. 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 [wikipedia.org] is simple (and kind of stupid) and fits in 512 bytes. GRUB [wikipedia.org] 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).
Parent
Re: (Score:3, Informative)
bootkey (Score:5, Informative)
Or better yet, a USB key - an key that lets you start your computer. No key, no start. Faster than a CD, no moving parts, etc. Me likes.
Parent
Re: (Score:3, Informative)
Are you root? If not then the answer is no.
The real issue here is not whether an exploit like this would work with lilo or grub, the issue, as noted by TFA, is that "Unfortunately, all the Windows NT family (including VISTA) still have the same security flaw - MBR can be modified from usermode. Nevertheless, MS blocked write-access to disk sectors from userland code on VISTA after the pagefile attack, however,
Re:Educated users on safe platforms (Score:5, Insightful)
Parent
Re: (Score:3, Insightful)
Under GNU/Linux, you typically have better educated users.
This was true back in the day, that is, when virtually all Linux users were home-brew hacking DYIers who either loved all things CSish or hated all things M$ish and knew there were alternatives.
You know, the gentoo and sid crowds.
Then RedHat happened and Ubuntu happened and hell froze over and DELL and HP started shipping systems with an OS other than Windoze and what you say is no longer true.
It's probably still true that the majority of Linux
Misleading... (Score:5, Informative)
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 [wikipedia.org]. 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...
Re:Misleading... (Score:5, Interesting)
Parent
Re:Misleading... (Score:5, Informative)
# mount -oremount
# awk '/^root/{print}'
# passwd and enter a password you can remember. Twice.
# init 6 to reboot the machine again. You can now log in as root, using the password you supplied. No need for any special weapons, boot discs &c. This is one you can carry entirely in your head.
To restore the original root password, the sequence is
# awk '!/^root/{print}'
# cp -f
# rm -f
Parent
Re: (Score:3, Interesting)
Treacherous Computing to the rescue! (Score:4, Insightful)
Re: (Score:3, Funny)
Re: (Score:3, Insightful)
I know I'll get flamed for saying it, but this is exactly the sort of problem that a TPM can solve.
And you can "solve" crime with a ubiquitous secret police, but would you want to?
You have run Vista with elevated administrative... (Score:5, Informative)
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.
A boot sector virus? In my PC? (Score:5, Funny)
What is this? 1986?
Re:A boot sector virus? In my PC? (Score:5, Funny)
Parent
Re:A boot sector virus? In my PC? (Score:5, Funny)
Parent
Re:A boot sector virus? In my PC? (Score:4, Funny)
Parent
Re:A boot sector virus? In my PC? (Score:4, Informative)
Actually, it's a bit less. The first sector of a hard disk contains the MBR code and the partition table.
The partition table takes 64 bytes (16 bytes x 4 entries), and there's a two-byte signature that the BIOS checks to ensure the MBR is valid.
That gives you roughly 446 bytes of code that you can actually run. Most MBR code basically reads the partition table, finds a partition with the "active" flag set, then loads the first sector of that partition into memory. The partition loader then copies more sectors from disk so it can load the OS.
That's why you can install GRUB and LILO into either the partition or MBR. The MBR version basically overwrites the existing MBR to always load LILO or GRUB regardless of what the partition table says. The partition version relies on the MBR code passing it control.
Of course, having the first cylinder of a disk unused makes it convenient to stash away the extra code you need.
Parent
Re:A boot sector virus? In my PC? (Score:5, Interesting)
Remember that almost all current Windows systems reserve 1-8Mb space [microsoft.com] for converting the drive to dynamic disk.
8Mb is likely enough to run almost fullblown virtual machine, atleast versatile enough to hide beneath the "primary" os and act as a spam/ddos drone/keylogging trojan unnoticed.
Sure, it'll eat some resources sitting there, but your average Joe/Jill won't really notice that. They just curse their damn slow computer.
Parent
Solution is in your BIOS settings (Score:3, Informative)
Basically, you leaves these options off when installing the OS. Once you're finished, you can safely turn them on. I'm not sure how often NTFS needs access to the MBR, but I know I've never had trouble leaving these features enabled with FAT32.
Re:Solution is in your BIOS settings (Score:4, Informative)
Ah, but these things only work in two ways:
1) The write protect only works if the OS makes a BIOS call to the MBR. The BIOS then traps this request and asks if you mean to write to the MBR. This works pretty well as most boot sector virii exist in DOS, which uses the BIOS, rather than Windows.
2) The BIOS makes a copy of the MBR and saves it in the CMOS. On boot, it loads the boot sector as normal, and does a quick comparison (it's only 512 bytes). If it differs (because someone overwrote the MBR code, or someone changed the partition table), it asks what you want to do - restore from backup, or accept the modifications.
No good filesystem should need the MBR once the system is booted. Other than reading the partition table. (The MBR, being 446 bytes in size, is also pretty standardized, which is why any utility that rewrites the MBR code can get your system booting again. Linux rewrites MBR can boot Windows, Windows fdisk can make Linux bootable again, etc. Basically, the MBR code just examines the partition table (in RAM - the BIOS doesn't care or know about the last 66 bytes being partition table. It loads the entire 512 byte sector into RAM), finds an entry marked with an "active" flag, and copies the first sector out of that partition into RAM and jumps into that code.
Extended partitions are the devil, which is why most MBRs can't boot from an extended partition.
Parent
This is a security flaw...why? (Score:4, Insightful)
It's really annoyed me that security companies continually report these things when they have no relevance to actual security. The concentration should always be on preventing malware from acquiring root access in the first place. Vista, despite its faults, actually does a much better job of this than its predecessors.
Also, this is Slashdot. Slashdot has Linux users, and wouldn't Linux users know that overwriting is even easier to do in Linux than NT? "dd if=trojan.bin of=/dev/hda", anyone?
By the way, there are many more bad things you can do as Administrator than just hack the boot sector. You can use bcdedit to create a fake Windows XP boot entry then put your Trojan kernel there.
Round and round we go... (Score:3, Funny)
Re: (Score:3, Informative)
Re:Like it matters (Score:5, Funny)
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!
Parent
Re:Like it matters (Score:4, Informative)
Gamma rays are a type of ionizing radiation.
but
The gamma-ray burst released 4.3 blargajoules of energy.
Parent
Re: (Score:3, Informative)
Two-word noun phrases are only hyphenated when used in adjective form.
I don't know about US usage, but in British usage there's no such rule, according to both Partridge's "Usage and Abusage" and Fowler's "Modern English Usage" (arguably two of the three most influential prescriptive grammars of the 20th century, the third being Fowler's "The King's English", which I don't have to hand).
As Partidge points out, "In the life of a compound word there are three stages: (1) two separate words (cat bird); (2) a hyphenated compound (cat-bird); (3) a single word (catbird)."
Apart
Re:Like it matters (Score:5, Funny)
Parent
Re:Like it matters (Score:5, Funny)
Parent
Re:Like it matters (Score:5, Insightful)
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.
Parent
Re:Like it matters (Score:4, Insightful)
Parent
Re: (Score:3, Funny)
That's not what my users have been telling me...
Those sneaky weasels !
Re:Like it matters (Score:5, Informative)
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.
Parent
Re: (Score:2, Insightful)
I can't imagine that would make any difference. The computer needs to boot somehow, there are legitimate reasons for modifying the boot code (such as installing a new OS, or fixing flaws in it) so you can't just block it wholesale, and any program that runs at the boot stage will necessarily have complete control of your comput
Re: (Score:3, Informative)
I can't imagine that would make any difference. The computer needs to boot somehow, there are legitimate reasons for modifying the boot code (such as installing a new OS, or fixing flaws in it) so you can't just block it wholesale, and any program that runs at the boot stage will necessarily have complete control of your computer. About the best you can do is require the user to confirm before overwriting the MBR - something I thought windows already did (and if it doesn't, there's really no excuse for it not to) - but that's far from foolproof.
I think most modern Bios's have MBR/boot sector virus protection options. Basically you set the option in the BIOS and it either prevents MBR access (through the on-chip IDE controller, duno about off-board cards or scsi devices) or interrupts the system and displays an alert screen (similar to an overheat warning some do). To use it, you turn it off, install your OS with boot loader of choice, then go turn it on. Anything trying to write MBR data gets rejected or notifies you in pretty ASCII colors on scr
Re: (Score:3, Informative)
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.
Whether EFI or BIOS, this is a (small) part of what TCPA is intended to defeat. The idea is that the EFI or BIOS hands a copy of the boot sector to the TPM before loading it, and the TPM hashes it into a state register. The boot sector code sends a copy of the boot loader code to the TPM for hashing before it loads, then the boot loader sends a copy of the OS kernel to the TPM before it loads, and so on.
Any piece of code along the way, or even user-level code after boot, can check the state register to
Re: (Score:2)
Re: (Score:3, Informative)
I hated it at first, Linux installs failing as LILO not getting to write to the MBR until you turned it off.
Re:Like it matters (Score:5, Funny)
http://www.nuklearpower.com/daily.php?date=080103 [nuklearpower.com]
Parent
Re:Like it matters (Score:5, Funny)
Parent
Re: (Score:3, Insightful)
Macs use EFI and PC's use BIOS. That's why.
Of course.. (Score:5, Interesting)
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.
Parent
Okay, found some documentation on this (Score:3, Interesting)
It actually looks reasonable - you can still perform raw disk writes from userland (with admin rights, of course) - you just can't write over a mounted volume. Disk imaging utilities will still work, provided they dismount any volumes before they overwrite them (which they ought to be doing anyway; I should know, I wrote a Windows disk imaging utility at my last job).
And of course, you can't dismount a disk with an active pagefile on it, so it solves that vulnerability. But it does so in a reasonable
Re: (Score:3, Funny)
-1.
Re:I Thought Vista Was a Re-Write? (Score:4, Funny)
Parent