Bootkit Bypasses TrueCrypt Encryption 192
mattOzan writes with this excerpt from H-online: "At Black Hat USA 2009, Austrian IT security specialist Peter Kleissner presented a bootkit called Stoned which is capable of bypassing the TrueCrypt partition and system encryption. The bootkit uses a 'double forward' to redirect I/O interrupt 13h, which allows it to insert itself between the Windows calls and TrueCrypt."
Not a new thing or idea (Score:5, Insightful)
I can't tell what's supposed to be interesting or spectacular about this. It's a standard rootkit with MBR support along with some special hooks for truecrypt. It won't let anybody read an encrypted truecrypt volume unless you enter the password... And if you do enter the password on an owned computer it's not like trucrypt is going to help you anywhere. If you unlock the volume any malware can grab all the data it wants through the usual calls and hooks. It doesn't seem especially advanced compared to many of the rootkits out there.
Re:Much as we hate TPM here on /. (Score:3, Insightful)
Ok I don't get it (Score:5, Insightful)
How does this, in any way shape or form, "break" Truecrypt? Now maybe I misunderstand how it works, since the information is not presented in a clear manner and the author is letting ego get in the way of good writing, but more or less it looks like he has a way to get in to the system at a low level. Ok, great, that does NOTHING to break the encryption. I see nothing in here about managing to get data out of a Truecrypt drive/volume without knowing the key. So what's the big deal?
I mean yes, you could use said malware to log the password. Well guess what? If you've physical access to the system, you don't need software for that. A hardware keylogger would achieve the same thing, or maybe a camera over the shoulder or maybe a tempest attack. The point is if you have physical access to the system, there is little someone can do to keep you from bugging said system.
What Truecrypt is intended to deal with is someone nabbing your system and getting data, and I see no break in that regard. If you encrypt your laptop's harddrive to ensure that nobody gets your data, and somebody steals you laptop, this doesn't help them. For it to help them they'd have to get your laptop, bug it, get it back to you such that you didn't notice, wait for you to use it, then steal it again so they could get the password.
I just fail to see how this is news here. If there is something I'm missing, by all means I'd be interested in knowing.
Re:Much as we hate TPM here on /. (Score:5, Insightful)
Unless the bios writes a kernel module that hooks into reads from /dev/sda and gives out false information for the first 512 (or whatever) bytes.
You cannot possibly defeat malware that is running on the same level of privilege as your detection code.
Re:As usual secrets are best kept in brain case (Score:3, Insightful)
Tell that to the doctor in the emergency room when he needs to look up your patient records to decide if it's safe to administer a drug to you.
Re:Do I need to prepare? (Score:5, Insightful)
Giving someone physical access to your machine is the equivalent of losing it and recovering it later, and encryption was never about this case!
Encryption is meant to prevent data release with such a loss, but does nothing much to guarantee integrity of the system after recovery. It does not provide a tamper-evident nor tamper-proof system, since tampering can occur outside the encrypted content. Also, encryption itself does not even provide tamper-proofing for the encrypted volume! It just makes it infeasible to inject known plaintext into the real filesystem, but someone can simply corrupt the ciphertext image and therefore corrupt the real filesystem. You would need additional checksums or other integrity-checks to actually detect such damage.
Re:Ok I don't get it (Score:5, Insightful)
How does this, in any way shape or form, "break" Truecrypt?
It breaks the unspoken (and totally unwarranted & incorrect) assumption that TrueCrypt not only encrypts but also authenticates.
This is not "breaking" TrueCrypt since they never claimed to authenticate the MBR/BIOS against this sort of attack. That's what's somewhat clever about it -- it doesn't attempt to smash the door open but rather attacks in a fashion that this particular security software was not designed to handle.
Re:Much as we hate TPM here on /. (Score:5, Insightful)
Because if you have a compromised BIOS, it could "read back" whatever you wanted to hear. Asking a hacked BIOS to read itself back to you is like asking a liar whether he is a liar -- it gets you no reliable information.
Surely you jest.
As to updating the BIOS in a TPM system, I imagine that the procedure would be like this: ...
(3) On next boos, TPM raises an alert saying "BIOS has been replaced -- new bios hash XXXXXXX"
If you think this scheme works, but the one above doesn't, I have a bridge to sell you. Where do you think this data to hash is going to come from? From the BIOS, which you claim is an unreliable source. Indeed, if you rig up a BIOS to return the same signature as your current one, and you can run step 2 with no step 3 or 4.
Not a break of the encryption or even TC in genera (Score:5, Insightful)
This really does not defeat TrueCrypt. All it does is read the date after its decrypted and before it gets to the OS. It also can only read the data after the real key has been presented. I think the take away here is disk encryption is not a silver bullet. You can't sit there and say "My disk is encrypted my data is safe." Its not safe while the machine is on an in the unlocked state. Any other malware running on the system can send or leak data all over the place. You have to trust the entire stack or have defenses in place at every layer.
All disk encryption can accomplish is:
1. If someone steals the system while off or locked and does not already have the key they can't get the data
2. The system cannon be modified offline with out the key
It can't really do anything more than that. TC is not broken its just not a defense against other software that can get ahold of the disk layer.
Suppose I walk into a bank during hours after the manager has opened the vault. I point a gun at him, hand him a bag and tell him to start loading it up. I then leave with the money. The vault is not broken. Its just that it only protects the money while its closed. If I showed up in the middle of the night broken and got the goods then the vault would be broken; but a day light robbery is just exploiting another weakness in the system.
Re:Do I need to prepare? (Score:3, Insightful)
It just makes it infeasible to inject known plaintext into the real filesystem, but someone can simply corrupt the ciphertext image and therefore corrupt the real filesystem.
If you were able to do several lunch-time attacks over time, you might also be able to do 'traffic analysis' to figure out which files were system files, correlate that with a security update, then replace the updated software with an older, vulnerable version by re-writing old ciphertext. This would be particularly easy if, for example, /home is mounted on a different encrypted volume than /usr.
Re:Not a new thing or idea (Score:3, Insightful)
Agreed; I'm more worried about tiny pinhole cameras watching my keystrokes, that RF keylogging, or a rubber hose. My crypto has always been to deter the average thief who boots once to look for personal info before selling it online and to prevent other students from pranking me. Against a resourceful attacker you're pretty much screwed anyway.
My best defense is that the kind of people who /could/ break into my computer have better things to do.
Re:Do I need to prepare? (Score:3, Insightful)
The perp won't be able to read the data, unless he installs this rootkit, returns your PC and then steals it again to read the keylogger info.
Easy solution: Wipe the system and restore it from a backup if you suspect your machine has been physically compromised.
Boot from CD with a "secure" BIOS (Score:3, Insightful)
Password protect the BIOS, disable post-boot BIOS flashing, and only boot from a CD that you carry with you at all times. That's a pretty effective way to get rid of software only attacks. Once the hardware is involved (which includes vulnerabilities that allow flashing the BIOS after it's booted or without a password), you're screwed.
Confirm this for me... (Score:2, Insightful)
So let me get this straight...if a program lodges itself into the bios and intercepts disk calls above an encryption layer and can intercept the data, that is in and of itself newsworthy?
Ok, I though it was like "The government can wiretap your phone by standing in your kitchen while you're talking."
Please....this is unworthy of any attention. Everyone knows that a compromised system is not secure. Was this ever in question? Take your 15 minutes of fame, and go....
Re:The point of full system encryption... (Score:1, Insightful)
Re:Do I need to prepare? (Score:3, Insightful)
Yes, it's a typical MITM attack [wikipedia.org].
As Trucrypt presents it's drives as block devices to the OS, this BIOS-level Trojan is equivalent to a typical OS-level Trojan.