Slashdot Mirror


Bootkit Bypasses TrueCrypt Encryption

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."

21 of 192 comments (clear)

  1. Uh, what? by Cthefuture · · Score: 4, Interesting

    So yeah, if someone is running live software on your machine then there isn't much you can do. If there is decrypted data then it's essentially available to anything on the machine.

    I mean if you're going to do this you could just modify the TrueCrypt code (bootloader in this case) itself to do what you want.

    Kind of "duh" story if you ask me.

    --
    The ratio of people to cake is too big
  2. Much as we hate TPM here on /. by Wrath0fb0b · · Score: 5, Interesting

    TFA has a very good point -- unless you (cryptographically) trust the components of your system all the way down to the hardware itself, you can get pwned by an attack like this. You can regularly do all-the-way-to-the-firmware scrubs of your machine as damage-control, but the only real prophylactic is some form of trusted computing.

    Of course, I'm not really dying to jump on the TPM bandwagon, given the sponsors, but it sure would be nice if there was an openly-audited trusted computing module.

    1. Re:Much as we hate TPM here on /. by Wrath0fb0b · · Score: 5, Informative

      http://lwn.net/Articles/144681/

      Linux has had kernel level support for TPM for a while but most F/OSS developers have an intrinsic aversion to the concept (as I said in the GP, the identity of the TPM principals doesn't exactly give me a lot of confidence) so it's not widely used as far as I can tell.

      A wonderful response from the F/OSS community would be to build a version of TrueCrypt that uses TPM to authenticate the BIOS and MBR against the known good versions.

    2. Re:Much as we hate TPM here on /. by Wrath0fb0b · · 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.

    3. Re:Much as we hate TPM here on /. by poopdeville · · 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.

      --
      After all, I am strangely colored.
    4. Re:Much as we hate TPM here on /. by mlts · · Score: 4, Interesting

      The tools are there (tboot, TrouSers). What is missing is a gestalt "stack", where an admin can configure a distro to "seal" the hash of various parts of the boot process in the TPM (MBR, boot sector, BIOS, kernel, RAMdisk image), then encrypt the rest of the machine. Then, at boot, it would boot to the ramdisk filesystem, ask the TPM for the key, and if the image has not been tampered with, the TPM will hand the key over, and the boot process continues.

      One thing that isn't discussed (which is important) is a facility for recovering the encrypted data should the TPM be off or erased. BitLocker handles this fairly gracefully by saving a keyfile to a USB flash drive, or allowing the user to print out a sequence of numbers with the recovery key. BitLocker also allows saving of the recovery key to Active Directory, ensuring that corporate IT has recovery access (which is required by law in a number of cases). Finally, for home users, BitLocker allows use of offsite storage for the recovery information.

      Another option to implement a means of recovery is to have a recovery passphrase. PGP is a product that allows this, where one can boot from a TPM, but if that is unavailable, one can type in a previously set passphrase, or a WDRT (whole disk recovery token, which is a challenge/response system).

      This functionality will have to be implemented distribution by distribution, as there isn't a standardized set of tools. Perhaps one thing that should be designed would be a standard for implementation across distros.

  3. man in the middle by MoFoQ · · Score: 4, Informative

    it's more of a "man in the middle" sort of thing and it by itself does not "break" the encryption.

    Think of it as a keylogger for your hard drive.
    No matter how complex and secure an encryption method is, if you can steal the password (or key), yea...you get the idea.

    In that sense, the title, summary, and the title of the article in question is misleading as it doesn't really bypass any encryption but rather daisy-chains itself into the process (so once you enter a password/key, it can capture it).

  4. Not a new thing or idea by pehrs · · 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.

  5. Re:Do I need to prepare? by Wrath0fb0b · · Score: 5, Informative

    If you care about the privacy of your information then your PC had better be secured at least as well as you would secure your other valuables. If someone can gain physical access to your machine then it's effectively game over.

    But that's the entire point of System Encryption right there! Someone gains physical access to your machine and they still can't do squat to read the contents (short of beating you with a hose to get the password or spending serious supercomputer time). System Encryption was designed for precisely this application.

    This nice little trick here gives them a third option -- install malware at the BIOS level while leaving TrueCrypt unchanged so as to give you the illusion of safety while they read your mail/keystrokes/whatever. If I were the Border Patrol, I would consider a tool that automates the installation of this tool to be a very worthy investment.

    In short, he's exploiting the fact that encryption and authentication are two very different things. TrueCrypt can assure you that you data are unreadable without the key but cannot authenticate the MBR as being genuine. For that, you need some form of trusted computing, the mention of which never goes well.

  6. Ok I don't get it by Sycraft-fu · · 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.

    1. Re:Ok I don't get it by Wrath0fb0b · · 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.

  7. Re:Do I need to prepare? by Anonymous Coward · · 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.

  8. Not a break of the encryption or even TC in genera by DarkOx · · Score: 4, 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.

    --
    Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
  9. Re:Just when I though I was safe.... by sumdumass · · Score: 4, Interesting

    I'm not so sure a mac is the answer. With a mac, you can just install the code in the keyboard and grab the keys directly.

  10. Re:Do I need to prepare? by khayman80 · · Score: 5, Interesting

    You're absolutely right. Strangely, none of those links led to Peter Kleissner's web page.

    Check out the comments. Some of the visitors are flaming him pretty hard, but he's just a kid with amazing skills and (understandably) very little historical knowledge. Luckily, Christian politely points out that his attack serves to "... alert many people who think they made their PC secure by installing TrueCrypt and still keep working with an admin account where they should not. You prove that a security policy is indispensable, because admin privileges will give malicious software the ability to tamper with the installed security software."

  11. Re:Do I need to prepare? by buchner.johannes · · Score: 4, Interesting

    This exploit really is more comparable to a software keylogger. It lies between OS and Truecrypt Bootloader, catching the disk access requests.
    For infection, you need admin rights on the running machine (TFA says so).

    So, with the full system encryption, you are of course safe. This is just a way of listening to Truecrypt requests.

    Kudos to Peter, hope to meet him in the Metalab sometime.

    --
    NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
  12. Re:Do I need to prepare? by timmarhy · · Score: 4, Informative
    No, hd encryption was designed to stop people stealing your hd and reading it, not to defend against hardware keylogging. for this to work you have to have booted the machine and authenticated - if the attacker has the power to force you into this then i'm guessing your going to give them what ever they want anyway.

    i'm yet to see a decent defense against keyloggers like this thats acceptable to home users.

    --
    If you mod me down, I will become more powerful than you can imagine....
  13. Re:Do I need to prepare? by ehrichweiss · · Score: 4, Interesting

    Encryption is to prevent your data from escaping if someone stole your laptop. It however will NOT prevent the thief from installing a keylogger(which is what TFA is basically describing) which can then be used to discover your passphrase and eventually gain access to the system.

    If you lose a laptop and then recover it, you can be fairly certain that your data was never leaked but you cannot be certain that someone didn't tamper with your system so they could steal the data later. At that point the best you could do would be mount the volume on a completely different system and move any data you hadn't already backed up, then wipe the drive/bios fully..though after yesterday's article about the BIOS "rootkit" that is Computrace, I'd be wary of the hardware at that point.

    --
    0x09F911029D74E35BD84156C5635688C0
  14. Re:Do I need to prepare? by BitterOak · · Score: 4, Informative

    Easy solution: Wipe the system and restore it from a backup if you suspect your machine has been physically compromised.

    Sorry. Wiping the system will do nothing if the malware is installed in the BIOS. And it will do nothing to protect you from hardware keyloggers. Also, recall the story earlier today about tampering with the flash memory in keyboards.

    --
    If I can be modded down for being a troll, can I be modded up for being an orc, or a balrog?
  15. Re:LFP is doomed by node+3 · · Score: 4, Funny

    This sure is a big hit on the Linux for Pedophiles distro.

    What part of "insert itself between the Windows calls and TrueCrypt" did you miss?

    Maybe that's what he calls Windows?