[Critical Flaw] Bootkit bypasses TrueCrypt encryption

Are you thinking of the interaction between TPM and BitLocker?

 

Nope, I'm really pointing at User Account Control. Or Windows Vista/7 in general.

But I'm certainly not mentioning Bitlocker, since thats only in Ultimate en Enterprise.
And practically nobody that I know of has that.
So its a rare function in the first place.

Same goes for TPM in a sense.

 

I found this:

http://blogs.technet.com/antimalware/archive/2008/01/10/mbr-rootkit-virtool-winnt-sinowal-a-report.aspx

Although it doesnt address this problem specifically, it does address the issue of modifying the MBR.

This malware ( VirTool:WinNT/Sinowal.A is what theyre talking about, comment mine) attempts to modify the MBR so that it can control what gets read from the disk into memory and execute very early in the boot process. After the modified MBR is executed, it reads additional malicious code into memory which modifies the NT kernel to force it to load a malicious driver that has been stored at the end of the physical disk (The driver will not be visible while the infected OS is running.). Once the driver is loaded into the kernel, it behaves just like a standard kernel mode rootkit, providing covert and stealth network backdoor functionality by hooking low level APIs to attempt to avoid detection.

Here are some interesting things about this malware:

First, the installer for this rootkit needs to modify the MBR in order to ensure that the rootkit can persist across reboots. It does this by using the CreateFile API attempting to open “\Device\Harddisk0\DR0” for write access. Using the CreateFile API in this way (for direct / raw disk access) requires administrative privileges as mentioned in this KB article: http://support.microsoft.com/kb/q100027. So if you are logged into Windows as a standard user or if you are using Windows Vista with UAC enabled, even if you accidentally run the malware installer or it runs via some exploit code, it will be running with insufficient privilege to modify the hard disks MBR; thus it will not be able to persist a system restart.

 

It seems to me that there is ultimately no software defense against this kind of attack. If the MBR is modified then won't this allow any number of subsequent bits of code to be loaded before the OS? There are Bootkits out there (kon-boot for example) that could be loaded by a hacked bootloader. The Bootkit code could restore the MBR before the OS finished loading so that the MBR would check out fine. A bootkit can bypass OS security and install whatever it wants.

The simplest defense would be to use a BIOS password to block CD and USB booting. BIOS password can be bypassed by removing the hard drive and modifying on a different machine so physical security is the best defense.

 

Brian,

To summerize and complement your post:
1) physical security, dont loose it or let it get it into the hands of possible adversaries.
2) never run as an Administrator

 

Of course, the only sure means of security is to use a laptop and carry it with you everywhere. For most people, however, sleeping with your laptop under your pillow and/or chained to your arm is just not going to happen.
I have searched for off the shelf "secure PC's" but few solutions are available to the general public. I don't understand why motherboard security is not standardized and secure options available. Well, Ok, I do understand that the vast majority of people are uninterested in security so there is no demand but...
It wouldn't be hard to do. The MBR could be encrypted and the BIOS could decrypt and execute the boot loader after a password was entered.
Another solution is to use a hard disk with hardware encryption. These often come with self destruct or lockout after too many failed password attempts.

 

well ive had the chance to take a good look at stoned,, and was invited to the beta testing of it also, and I can tell you that it gets below the level of truecrypts loading ( that is when it loads itself, It doesnt always infect the machine to begin with)

 

Justin,

I'm really interested in this subject of HMAC's and CMAC's.
Do you, by any chance, know good books or websites with some good practical introducary information regarding this subject?
Would Bruce Schneier's "Applied Cryptography" be still relevant, albeit some what old?
Because I can't really tell the difference in CMAC's and HMAC's.
Only that one is cipher-based, and the other hash-based. But that difference doesn't really tell me anything tangible.

 

I think there is a simple defense. Know your MBR, or, even better, know your first track. Run an MD5 of the first track (i.e. first 63 sectors) and save it somewhere on your hard drive. Do this as soon as you've finished installing all programs that will write to this area (i.e. TrueCrypt).

Then create a batch file that will automatically copy the first track to the hard drive and run an MD5 hash on it (command line program). Then you can compare the original MD5 to this new one. This batch file can be set to run every time the computer starts. You can use dd (or dd for Windows) to do the copying.

The reason you want to run a hash on just the first track and nothing else is that when you encrypt your system, this is the only unencrypted area of the drive.

Alternatively, you can keep a copy of your first track on your hard drive and have it automatically written back every time you boot up (presuming nothing is blocking you from write access to this area and presuming that you never install any further legitimate software that writes to this area).

I've been doing something similar for 4 years, and no problem yet. I know for a fact that this area of my drive cannot be modified. The only real effort was when I first set this up. Now it runs automatically, and it takes no effort.

Disclaimer: I will not take responsibility for someone destroying their MBR.

 

One of the first things that a computer does at boot time is to load the first sector of the HDD and run it. So it is a bit hard to run code before a presumable MBR virus/trojan/rootkit runs. The only way would be to boot from a read only medium (like a CD/DVD) and check the validity of the first track, and then give control to HDD. Otherwise your program will run after the malware was executed, so you have no guarantee that your checking tool will give accurate results.

 

How did I know someone would say that?

Of course you have a guarantee. The guarantee is that in order for some code in the MBR to modify the functioning of some random command-line hashing program or "dd", the changes to the system would have to be quite noticeable (i.e. you would know something is up). I'm talking about 2 tiny programs that have little to no reliance on system resources to function. "dd" simply does a sector by sector copy and the hashing program simply does some math on that copy. Under most circumstances, I would say you were right, but not in this case.

So, I do believe you have a guarantee that it will work.

Edit: While I do believe the above technique is valid, I also do use some other techniques involving booting from read-only media prior to booting from my hard drive. While I don't do this primarily for the purpose of verifying my first track (I do some other things that are off-topic for this thread), I actually do verify the first track (incidentally) during the process.

 

No, I don't. And this is because rootkits won't modify a specific tool so that you can't use it properly, but the way first track is accessed (for instance, when somebody tries to read from track zero, a clean copy or MBR prior to infection is given). I'm not saying that it will happen all the time, I'm just pointing out that relying on any information AFTER a system compromise is not good security.

This is the proper way, that can give you a guarantee

 

I agree it's not as good to check after your computer is booted, but I was giving the simplest possible solution that anyone can do. Most people won't do what I do.

That being said, I'm not just talking about the MBR, I'm talking about the whole first track, which is 32,256 bytes typically. Also, when you encrypt an entire drive with TrueCrypt, those are actually the only unencrypted sectors on the drive. If you have a system partition + other encrypted partitions, then there is probably some space at the end of the drive to hide things.

If the drive was modified due to someone having physical access to the drive, it will almost certainly be caught by this method. The reason is that, for all intents and purposes, they really have nowhere to hide that much data. If they replace your first track with something, they won't have much (if any) space to work with to store your original first track. Yeah, there's all sorts of complex games that an attacker can try to play, but they'll almost certainly get caught by this simple trick. Encryption really limits the real estate they have to work with, not only in terms of places to hide the original first track but in the amount of space they have to place their code. It's actually quite tiny.

If the MBR was modified due to some online attack (why didn't you have something in place to prevent modification of the MBR?), then the attacker could have made any of a number of modifications to your system, so this method will be less likely to work. But, I would guess you could catch 90+% (possibly even 100%) of MBR modifications with this. It would be inordinately complicated for the bootkit creator to try to prevent a simple hash of the first track for the less than 1% of people who would even attempt it.

It just wouldn't be worth their time to try to anticipate every possible way someone could examine the first track. There is only one thing that concerns me with an online attack. Would it be possible for the original first track to be written back after a boot then the infected first track written in during shut down? I personally think that would be too much trouble and not worth it for a bootkit creator. And it shouldn't be possible at all if you have some protection of the MBR in place.

In summary, in my opinion, a bootkit attack due to physical access (the only type of attack anyone should really be susceptible to) of an encrypted drive should be caught by this method. If you want to be 100% sure, then boot with read-only media.