There are several key details in these events that should be of interest.
As Michael Howard (of Microsoft Security Development Lifecycle fame) points out and Robert Hensing confirms, Windows Vista with Bitlocker Drive Encryption installed (most specifically the use of the Trusted Platform Modules (TPMs), as I have discussed here many times) is immune to these types of attacks. It's not because the drive is encrypted; it's because the TPM validates the chain of trust, starting with the building blocks-- including the MBR.
But that's not the only interesting thing in this story. What's interesting is best found in Symantec's coverage on the latest MBR rootkit (Trojan.Mebroot) that has been recently found in the wild:
"Analysis of Trojan.Mebroot shows that its current code is at least partially copied from the original eEye BootRoot code. The kernel loader section, however, has been modified to load a custom designed stealth back door Trojan 467 KB in size, stored in the last sectors of the disk."That's right. Our friends at eEye who have been busy hacking the products we use to run our businesses in order to show us the emperor hath no clothes created the first Proof of Concept "bootkit":
"As we have seen, malicious code that modifies a system's MBR is not a new idea – notable research in the area of MBR-based rootkits was undertaken by Derek Soeder of eEye Digital Security in 2005. Soeder created “BootRoot”, a PoC (Proof-of-Concept) rootkit that targets the MBR."
5 comments:
Vulnerability pimps ... hilarious! I don't know Derek Soeder but I respect research like BootRoot more than I do the buffer-overflow factory work most blackhats with jobs are performing. It was a very clever hack.
It appears that those of us that don't want to use Windows Vista just to have trusted boot goodness now have an alternative with TrueCrypt 5.0. The January 2008 change log lists pre-boot authentication as a feature.
Now I am wondering if it would be possible to have trusted boot in a VM.
Hi Mike,
Thanks for commenting.
"Now I am wondering if it would be possible to have trusted boot in a VM."
The answer to that is, no, for one major reason: the only real way to achieve reasonable trustworthy computing right now is to us TPMs, and unfortunately TPMs only have so many registers to hold secret information like secret keys, etc. So, if you have a virtualized environment your options are: 1) serve up a virtual (software) TPM to the VM, which completely defeats the purpose of tamper resistant secure co-processing hardware (what a TPM is), or 2) use large TPMs that have enough storage for more applications-- not just a trustworthy OS, but applications on top. That's not practical in today's commodity hardware, but perhaps one day.
There is a very simple solution to this problem but no one will like it because it is simple. In future production runs of hard drives, let people physically control write access to all the sectors on side 0 from sector 1 to the last one by setting a jumper on the drive. There would be a jumper state for OS installs, allows writes to this region. Change the jumper (on or off) and now that region is read-only so that no low-level call can have write access to where the MBR or partition tables are. This feature should be built into every drive with no back doors. For existing hard drives, there should be a board that goes between the IDE cable and drive that intercepts writes to the system sectors of track zero and admits or disallows them based on switch setting. SCSI and SATA drives should be done the same way. Root kits, MBR virus, now would have no writable sectors to corrupt. The idea could be extended (with OS developer cooperation) to protect files in /bin for UNIX and c:\windows\system32, for apps, any files you know you don't want to be overwritten. If /bin files can't be overwritten or erased, this protects against accidental novice rm -r * mistakes. Locking down sectors with a jumper? It's a good idea, but no one will like it because it is simple. And everyone wants the complex solution.
Cheers.
JBK
kirbyjason@hotmail.com
Our "friends" at eEye? If they really wanted to be malicious (and not so friendly) then they wouldn't have let everybody know about it. That's sorta the point of security research, and one of the reasons you see things like vista now having a mechanism to defeat this rootkit. If it wasn't for our "friends" at eEye presenting their work in the public, like Blackhat as they did, we would still be clueless to this attack and vista probably wouldn't defend against this kind of attack. (I'm sure MS will argue differently)
@Kirby: while your solution may be somewhat technically accurate, it's entirely too cumbersome. You're right; it won't get adopted.
@Nate: It's one thing to say that we would not know about the possibility of MBR rootkits without eEye's work (I disagree, but I digress), but it's a completely different thing to say that we wouldn't know what they are if eEye's proof of concept code wasn't exposed to the world, eventually landing us with a great specimen in the wild. They could take about these attacks theoretically, and share their proof of concept with a very small, well-respected subset of people, comprised mostly of the affected vendors, and we would generally be that much better off. But, in eEye's line of work, it's much more effective to line up future customers by creating both the problem and the solution (which is what they're doing).
Thanks to both for dropping by with your comments ...
Post a Comment