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."
They can fix the hell out of it and it would still be vulnerable. What if someone wrote a super small bootable virus, then the virus' initial form used Partition Magic-like functionality to write its own partition and stick the virus on it then tell the computer before restarting to boot from that one. Then the virus can do whatever it wants to the MBR or basically anything else on the drive cuz no files or anything would be open. I'm pretty sure Windows can't protect the MBR if it isn't running.
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
I have a hard time taking seriously someone who can't bother with proper capitalization.
Are you trolling?
Macs use EFI and PC's use BIOS. That's why.
It's not a troll. I just want to know. If I put my code to MBR and LILO loader somewhere else and then start it, will it work? I guess so.
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!
All ACs are trolls.
We're also all inveterate liars.
I know I'll get flamed for saying it, but this is exactly the sort of problem that a TPM can solve.
... 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.
"Security flaw"? Heck, I'm almost finished with the virus that overwrites the MBR with GRUB stage 1!
Alright, I guess I'm forced to admit I'm just kidding.
Tomato wedge sperm darts that are Republican.
It's more likely than you think.
What is this? 1986?
+0 Meh
boot /dev/null
So I guess he'll ignore you too. :-P
"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."
... and grandmas ... and CEOs. Besides, If you make something foolproof (VISTA) only fools will use it.
Windows is made for fools
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
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.
As I know, most 3rd party motherboards offer "anti-virus" or the "write protect MBR" options. Even if available I doubt they will work when using onboard RAID features.
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.
Life is not for the lazy.
So how hard is it to exploit a flaw that gives a program elevated admin permissions?
Understanding the scope of the problem is the first step on the path to true panic.
some words come to mind, in particular:
"I came for a colossal doughnut, and I'm gonna get a colossal doughnut"
A program running as root takes over a machine. News at 11!
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.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
It ocurred to me that these last sectors are also (sometimes) use to store mirror info in gmirror, a GEOM "layer" I use to mirror my FreeBSD system. Just where the info is stored depends on the logical layout of your mirror devices, and are you really dual booting between Windows and a gmirrored BSD system? And blah, blah, blah.
But I'm going to look into it.
Not as hard as finding such a flaw in the first place. Why, have you found one?
Visual IRC: Fast. Powerful. Free.
The newest victim of DRM: disk imaging utilities.
IIRC, that's what the "pagefile attack" was all about - getting the kernel to run unsigned code. To close that loophole, MS prevents you from performing raw writes.
Oh well, dd on a Knoppix CD still works.
Actually, come to think of it, if this raw-write-disallowing only applies to disks that have pagefiles on them, then this wouldn't be a real loss, because you'd be unable to lock the volume anyway--and restoring over the existing pagefile would be a Bad Thing in terms of system reliability and such.
If a person wanted to be sure, couldn't you burn a boot loader onto a CD, have the CD boot first, and have that direct the loading? IANLWK (I am no Linux Whiz Kid), but in my imperfect knowledge of the world, that seems like it would completely defend against this type of attack. I yearn for correction of my ways if this wouldn't work.
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.
Here.
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 way--I can't really imagine why a well-behaved program would want to scribble over a mounted volume; you don't know whether the cache is just going to clobber what you wrote in a second anyway. So I apologize for my FUD in the parent message; this security feature actually seems to strike a good balance.
Now the FUD in TFA is another story...
(which was only a few years ago 1999ish :)) we used to refer to it as PEBCAC errors. Problem Exists Between Keyboard And Chair.
Also of course was the prevalent ID10T virus. I swear, we once actually told a guy that after he wiped his pc for the n'th time, and he ate it all up...
Seven Days with Ubuntu Unity
Once again, I thought Vista was supposed to be a complete re-write of Windows code. How do they manage to keep the same old buggy code from NT 4.0?
Let me get this straight... Windows is so insecure a team of Mental Retards can hack it?
MBR was THE attack vector for viruses back in the good old times of MS-DOS and floppies. Now it's new again?
Bot Assisted Blogging
... it is a clear sign of Oedipus Complex in that family.
Now I understand, why every Windows is always afraid giving away any USB Stick.
Something wonderful has happened, your Windows is alive!
He Who Controls the Bootloader
You are being MICROattacked, from various angles, in a SOFT manner.
It appears you're running out of new racial slurs to use. I mean seriously, wopcock?
I had a recurring rootkit virus on XP for 5 years before someone created the definitons to fix it. The only thing I could do was format the drive completely and restore from disk to remove it. I could remove it then every 3-6 months I would get it again probably from a old floppy or cd. (?) I was able to remove it finally with AVG or Karpinski I forget.
With administrative privileges, if overwriting the MBR from userland is blocked, aren't malicious codes could always install device drivers that does that job?
... it wants its viruses back!
If you read the OP this is pretty much what DOS viruses were doing 20 years ago. Wow.
Most motherboards from the last part of previous century on had boot virus protection in some form, usually a write block on the first sectors of the first harddisk. This was enabled/disabled in the BIOS setup and effectively stopped any attempt to modify these sectors. Had to be turned off for OS installation, lilo modification etc, but I found it well worth the hassle. Has this disappeared? (Found on a P4B close by - so Asus had it recently)
accept no limits but time
The MBR is a vulnerability by definition. Almost the only way to protect it is by having a jumper on the HDD itself, which must be fitted to enable writing to the MBR and must be removed to enable booting. That means that everytime you want to install a bootstrap loader, you will have to open up the machine and muck about inside it.
Question is, is the threat from the MBR vulnerability significant enough to warrant such a drastic solution?
Je fume. Tu fumes. Nous fûmes!
Under linux, that's dictated by /etc/localtime. So, Linux isn't different from Windows in that respect.
There are applications which independently track the time zone, but they piss me off because they don't concur and I don't feel like selecting my time zone per application.
XML is like violence. If it doesn't solve the problem, use more.
I'm not sure if you can blame MS in this case though. If your machine is interfacing with the device through a plextor driver, which similarly allows the firmware update (as a non-privileged user), I'd say the weakness is Plextor's. Drivers need to be able to do their thing, and I'm not really sure that the OS could easily differentiate between a driver reading/writing a DVD or writing firmware. So if this were the case, MS wouldn't really be to blame unless it was actually their driver, or perhaps if the Plextor driver passed MS Certification.
There is a simple solution: Boot from the Ultimate Boot CD for Windows (UBCD4Win), and run a scan on all the boot sectors of all hard drives. Since the original, possibly infected, operating system and hard drives are not in control, the rootkit has no effect.
Being appalled is the natural state of existence for a windows sysadmin.
Why do death penalty advocates mostly oppose abortion while vegans mostly support it?
Because it is easier to justify executing someone for murder or other horrible crime, than for simply being inconvenient.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
Disabling the root account is simply done by having no entry, or an invalid entry (i.e. containing a character in the "scrambled password" field which cannot be generated by the scrambling algorithm, i.e. matching [^A-Za-z0-9./] and thus preventing any rescrambled password from ever matching it), for "root" in the file /etc/shadow.
/etc/passwd, a password which when scrambled matches the corresponding one in /etc/shadow and, if so, launches a program specified in /etc/passwd -- usually a shell -- in the name of the user whose login you typed), you start the shell directly, without having your login checked. You can only have one process going on at once, but that's still enough to have some phun with. And the shell just conveniently assumes your userid number is 0, which is root, so you get all the powers and none of the responsibilities.
/etc/shadow entry for root; and thus even if the root account was disabled before, you've enabled it. Later, you will restore the old (possibly bogus or non-existent) entry to the /etc/shadow file. You really should fix the timestamp on this; but you already left a big enough clue that you'd been mucking around when you rebooted the box. If the sysadmin doesn't notice that, hell, you might as well just pick the machine up and wander out the front door with it. (Probably doesn't even look suspicious if you have a pair of coveralls and an ID badge.)
Booting with "init=/bin/sh" means that instead of starting the process scheduler init (which would then run several instances of getty; each of which runs login, which checks that you entered a valid login that appears in
Once you've done the passwd step, you have now created a valid
Je fume. Tu fumes. Nous fûmes!
Actually, it seems most modern BIOSes do NOT have this option. I have not tested it, but I assume that even if the option is set, it can only trap calls made through the BIOS int13h. (DOS, Windows 3.1, Windows 9x/Me in legacy disk access mode only) Once you transition to protected mode and the 32bit realm, the BIOS is out of the loop for disk access. It is possible that somehow the Southbridge, or disk controller can get programmed to look for LBA 0x00000000 or CHS 0,0,1 accesses and block them, but I do not believe this is the case.
Say what you want about Windows 98SE, but it still runs quite a number of games and is immune to Windows 2000/XP/Vista crapware.
Uh, any AntiVIrus program worth its salt nowadays, checks the bootrecord.
/cmdcons & have it as an easy to use boot option, no F8 bootup OR even OS installation disk required then)
Now, SINCE this is a rootkit, or even a device driver driven trojan, out of Ring 0/kernelmode/RPL 0 etc. et al, & one that MIGHT disable antivirus tools, OR, misreport info. to they? Ok... then, admittedly, I might be wondering myself, was my machine acting up in any way... & you're also probably "not sure if you have this bug or not" due to its mechanics (noted above (if things on your rig are acting stupidly))??
Repair it!
Recovery Console has an EASY fix as well, called the fixmbr command, to do so.
(& you can install it into Windows 2000 upwards, using (insert cd/dvd letter here)::\i386\winnt32.exe
You can use parameters "password" and "restricted" in lilo.conf
By the way, this technique does NOT work on all systems. I'm not entirely sure about the last time I tried it on Ubuntu, but on at least some systems, the initrd will also respond to init=foo, thus you'll get the initrd environment. That's not to say that you couldn't do similar damage from there (including running a root shell on the "real" system), I'm just stressing that there is no one way to attack all Linux systems.
/sbin/poweroff and such.
/sbin/init", and the system will have absolutely no clue that you changed anything.
Also, some of your stuff here is sloppy, on the systems for which it will work. "init 6" is not what you want -- you don't have init running at all at this point. What you want is to manually unmount, or "mount -o remount,ro", every filesystem, then sync, then either physically reboot or mess with
Or you can simply set everything back to the way you found it (mounted readonly and such), then "exec
Regardless, on anything, you just need physical access to the machine and sufficient time.
Don't thank God, thank a doctor!