TrueCrypt vs Peter Kleissner, Or Stoned BootKit Revisited..
Peter Kieissner
This weeks flame war between TrueCrypt and Peter Kleissner had me both upset and laughing at the same time.
For a start, hats off to young Peter (18 years old according to his site), who recently presented at Black Hat his concept for a “universal rootkit” exploit, which, using that older-than-he-is technology of MBR replacement, manages to subvert Windows in such a way as to be able to drop a payload into memory as the computer boots.
I’m not sure, but isn’t that what MBR viruses have done since day one? I guess Peter agrees because his new “Stoned Bootkit” rootkit is named “Stoned” in homage to one of the original MBR Viruses of 1987
Replacing the MBR to get the machine to do something before booting the operating system is pretty well know – every full disk encryption software product uses that trick, as does every boot loader, boot manager, or partition manager I can think of. I think even some disk imaging software uses code run via MBR changes. But still, using that mechanism to then run something which subverts the disk interrupt driver (aka again every full disk encryption product), to load his own payload as Windows boots is clever.
Unfortunately though, Peter seems to have taken offence to a perceived snub by the authors of Truecrypt (an open source full-disk-encryption software), who in short told him that he’d discovered nothing new, and that any prevention methods put in place by software to detect his rootkit could of course, be detected and circumvented by said rootkit, so were thus pointless.
Yes, it’s a sad truth that Trojans and rootkits are nasty little things which, because they tend to run first, also have the ability if they are clever to subvert anything which goes looking for them (to hide themselves). The only way to reliably detect them is to compare an “in band” and “out of band” analysis of the system – the two should of course agree, but if something is hiding itself “in band”, the out of band scan will show it up.
Both McAfee (RootKit Detective) and SysInternals (RootKitRevealer), as well as others provide tools to do exactly this kind of detection, and of course, with a reputable AV/Malware product on your machine in the first place, the only way Stoned Bootkit is going to get a hold on your machine is if someone physically puts it there – Writing to the MBR from within Windows is an incredibly privileged operation, and easy to block (that’s why there are hardly any MBR viruses any more).
Peters’ frustration of TrueCrypts apathy to his discovery went so far as to entice him to perhaps unwisely blog about their ambivalence – his entry “TrueCrypt Foundation is a joke to the security industry, pro Microsoft” is a work of art in itself, but more worthy perhaps are the viewers comments, most incredibly constructive and encouraging – very unlike the usual flame wars which follow unpopular cryptographic discussion. Two gems from commentators called Thomas and Christian respectively come to mind:
What the TrueCrypt Foundation wanted to tell you is, that your attack is actually nothing special. Its a root kit, which in fact just doesn’t start with windows but at the first point when its possible, the MBR. Well, “root”-kit is the correct word, because “root” means it runs under administrator privileges. A basic rule in computer security (yes, TrueCrypt tried to explain that) are that someone who already _has_ administrator privileges on your computer (and so is able to install your/any rootkit) has _full_ access to it. That is a fact which was known way before your bootkit. In fact, its known since computers exists.
Still you have made a great job! Your program will 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.
Yes, it’s a sad fact that, as the old adage goes “If you let your machine out of your sight, it’s no longer your machine”.
NOTE: Some people have already asked me if McAfee Endpoint Encryption for PC’s or SafeBoot Device Encryption for PC’s is vulnerable to this kind of attack. As I say above, this is not really an attack – Stoned Bootkit can’t suck the data off your machine unless you allow it to be installed, then you yourself login. But, of course IF you allowed such to happen, then yes, Stoned Bootkit could put some malware on your machine. The mitigation of course is to use a good AV/Malware solution and to not leave your machine in such a place where Stoned Bootkit could be introduced.
Although Peter has not written a specific exploit for the McAfee/SafeBoot drivers (and it would be significantly harder to do than TrueCrypt due to the fact we are closed source and that we have MBR rootkit detection built in, which Peter would also have to bypass), it’s not beyond the possibility (in theory) that he could, or that someone has already done so. I’d like to think that your AV/Malware detection product would pick this up though very quickly. Rootkits are not too hard to find once you know what you are looking for.
Leave a comment
Who?
 | EVP Cyber Product Innovation for Mastercard. Formally the Chief Technology Officer for Intel Secure Home Gateways, CTO for McAfee Enterprise Endpoint, CTO McAfee Innovation team, and Founder/CTO SafeBoot Corp. |
Comments
 | Christopher Burgess on How not to implement smarthome… |
 | Mike on Is Encryption enough? Why just… |
 | Simon Hunt on Is Encryption enough? Why just… |
| Mike on Is Encryption enough? Why just… |
 | Stéphane Pautrel on New S.M.A.R.T Monitor Tool for… |
Simon Says - Musings of a Technology CTO 
which proves Truecrypts point of “once someone has physical access to your OS, they can own your data”
Peter bit off way more than he can chew and doesnt have the gaul to admit he was wrong.
Yeah, he has started censoring comments on his blog. I challenged him to prove he could “bypass” system encryption. I offered him $5000 if he could bypass the encryption of a my system drive. He deleted this comment.
If you read some of the comments, it’s clear he’s misrepresented exactly what his exploit can do. Lot’s of people see the headline and assume TC is broken.
Victim: “Oh no, I gave malware root access to my system, now my data is compromised!”
TC Dev: “You hear that?”
***Rubbing fingers together***
TC Dev: “That’s the sound of the worlds smallest violin playing just for you.”
Hopefully this will at least get more people looking at MBR code and bootloader. What you really need to do is boot from ROM like a CD-ROM that checks your MBR/Bootloader and restores it everytime you boot your PC, and the same program should scan windows – and anything else that could possible have execution passed to it. That way you would be 100% secure.
I don’t think being open or closed source makes things harder or easier these days. Truecrypt signs its binary releases with certificates built into them, you can never compile exact matching binaries from the source. You have to treat it as closed source because you cannot match the binaries and therefore cannot prove the source code given is for the program at all.
MBR rootkit detection pretty much is pointless, its obfunsication at best, not security. If someone has MBR code that can do whatever they want, including making your rootkit detection give the OK to it’s self.
..BR rootkit detection pretty much is pointless, its obfunsication at best, not security..
Trucrypt said that already, and I reported it above. But let’s say it again – anything which owns your system (ie ROOT) can lie to anything that comes later which is modifiable. That includes anything software. The only defense is tamper proof hardware which contributes entropy based on measurement or input.
..it’s clear he’s misrepresented exactly what his exploit can do..
I'm not convinced that was deliberate – I'm prepared to give Peter the benefit of the doubt. Perhaps he's just really enthusiastic. When I was his age I said a lot of things that I'd not really thought through as well, and also thought people knew what I meant which was often different from what I said.
.. Perhaps he’s just really enthusiastic. When I was his age I said a lot of things that I’d not really thought through as well
It’s quite probable that is how it started. English is not even his native language after all.
Saying things like you can install any software on an encrypted system with stoned is ambiguous and has mislead a lot of people, (Probably unintentionally).
However people have asked him point blank – to publicly state exactly what – and more importantly what not his boot kit can do.
His silence on the matter speaks volumes.
Since this attack scenario is dedicated to disk encryption, can this also bypass folder/data that is encrypted with TC (note: machine is already infected, but the user did not mount the encrypted folder).- What would be the effect if user has admin rights to an infected machine.
Can Stoned forcely open this encrypted Folder or Data? how?
This attack can’t actually bypass ANY crypto product. It still requires the user to authenticate. All Peter has done, is proven that he can >introduce< A Trojan. It can’t access any data until the user unlocks the folder.
It’s interesting b/c his own demo video even SHOWS this. He types in the password for the TC volume before he boots up, AFTER the “rootkit” is installed. Not sure what is so revolutionary about this. I am surprised that this was even presented at Blackhat.
Thank you Simon. at least this closes the issue. Also, I would like to express that Truecrupt doesn’t intruduce a backdoor to its product.
I dont believe in the statement of Peter with Microsoft’s bitlocker compared to Truecrupt. I would personally give Truecrypt our Enterprise support.
Are the reports true that Encryption in Vista (Bitlocker) is broken by COFEE?
If Yes, it simply suggest that their OS has many holes and thier encryption(bitlocker) can somehow be bypassed or has a backdoor. Can anybody confirm?
You would use a free product without central management or auditing, and without certifications or a professional support organization in your enterprise? I accept it’s a great product for individuals but for corporate use? What will you do when it crashes your CEO’s machine?
Hi Simon,
We have audited and Truecrypt meets our requirements. Im not sure though if we purchased a support incase a machine has crash and what can Truecrypt do about it.
Im not sure what you are suggesting, I feel you wanted us to get something like a bitlocker because of its backdoor for emergency cases? Im not sure what you are trying to mean, forgive me in advance.
How can you help us evaluate if we go for free encryption for enterprise executives or even for regular users, what are considerations when taking a professional support?
I would obviously prefer you bought McAfee Endpoint Encryption for PC’s, but then again, I’m completely biased.
http://www.mcafee.com/us/enterprise/products/data_protection/data_encryption/index.html
How can I help you? I’m not sure – are you asking me if I’m open to taking a private consulting engagement? 🙂
As the ex-CTO of a data encryption company, and the current CTO of the data protection division of McAfee, I’m not really an impartial observer.
I guess the first thing I would encourage you to think about is whether you are trying to secure data, or trying not to fall under any data privacy or compliance laws – the two requirements are often very different. You can be compliant, but not secure, and vice-versa. Once you have your “reasons” worked out, you’ll know how much forensic capability, auditing, proof of security, certification etc you need in a product. Often securing data is easier than being legally protected (as long as your users are trustworthy and dedicated).
Hi everyone
I just visited the stoned vienna website and found that there was a possibility to install Stoned via some Windows PE boot CD. So the question is, can you still protect your HD with WDE (be it TC or whatever… PGP say stoned would not work on their WDE, because they protected the MBR or something…) when someone has physical access? For example someone steals your laptop, your laptop gets confiscated at the airport, your home gets policeraided or whatever reason there may be?
Any thoughts?
Sure, it can be installed on a stolen laptop if Stoned can safely write its code to somewhere that is not being used on the (fully encrypted disk), but as you say unless stoned also bypasses the MBR check functions of FDE products, then it will be detected when the machine is booted up. In EVERY case though, remember installing stoned on an encrypted machine is pointless unless you then give the machine back to the legitimate user and they boot it up after logging in. Just having a FDE encrypted machine and stoned does not get you the data (without the users credentials).
Stoned cannot recover data from a FDE protected machine without the credentials in any situation.
If the rootkit just tracks your keyboard while entering your pre-boot password and saving this in some place in memory/disk, then it becomes trivial for a thief to get all your data from your encrypted hard drive. So, yes, such a rootkit can do lots of damage. (or, it can even send your password to some random web-site). Even if you use two factor authentication or whatever, a rootkit can find out the encryption key and store it in clear text for a thief-to-be to find an use. So, this is a two-step attack: 1. Use one of thousands social engineering methods to get user to run rootkit installer (such as a free movie or free porn or whatever). 2. Get laptop and enjoy free access to data.
That would only be true a) if the rootkit could install without the encryption product detecting it (unlikely with the current batch of commercial products which are FIPS/CC certified), and b) if the product used the BIOS keyboard routines (again, unlikely with modern commercial products – certainly the McAfee product is immune from such malarkey).
I think if you were using a reputable commercial FDE product and a good AV/Malware product, it would be pretty hard to catch Stoned. Tinkering with the MBR is certainly not something most MBR products will permit, and again, most FDE products can detect unusual MBR relocations.
Actually, this is very easy by social engineering as explained in the earlier comment: Give a CD with a “free game”. Free game “reboots” the machine, and since CD is there, it boots from CD. Installs grub and chainloads the Mcaffee bootloader. Damage done (as long as the bootloader allows multi-partition boots). Never underestimate the power of the side channels. Of course, the above would be stopped with a TPM-based chain loading/verification, and I believe that this is the only real robust solution to the problem.
Again, it only works if Stoned is clever enough to defeat the FDE MBR protection methods, as anyone who’s tried to use something like Grub with FDE has found, it’s not as simple as you suggest. We pay a lot of attention to our MBR because it’s critical it stays where it is, so anything like stoned which tries to subvert that better do perfect reflection, otherwise it’s going to get found out very early on.
You are right though about TPM, a properly initialized and “owned” TPM, with an OS which supports TPM vector checks is much more likely to defeat Stoned and its derivatives. Unfortunately, the vast majority of TPM chips are neither activated, initialized or owned…
I don’t understand all the posts about “use a commercial product so MBR changes get detected!!”.
The whole premise of this kind of attack is that it replaces the first code to be executed with its own, meaning whatever product you have, it won’t even be ran! You boot up the computer, the bootkit immediately takes over, displays a fake login screen, you enter your password, it sends it to the attacker, uninstalls itself and reboots, leaving the MBR exactly how it was before. How exactly is some software, that never even gets ran while the attack is taking place, supposed to protect you from this? Somebody please explain..
Stoned does not have the capacity to “send” anything from its pre-boot loader, yes, it could store something, but now you’re confusing stoned (which exists) and “Evil Maid” which is a class of attack. Stoned relies on storing something hidden on the machine which the hacker can retrieve later, so if it stores something, this can be detected by something running in the usual windows context. With Evil Maid where you are using a repeat-visit scenario, that’s trickier to protect against as you indicate, though of course something like hard-disk based hardware FDE, where the disk is unwritable prior to authentication totally eliminates both Stoned and Evil-Maid class attacks, simply by virtue of the fact that you can’t install them to start with.
Not Stoned in particular, but that was only meant as a POC anyways, wasn’t it? Wouldn’t any serious attacker send the data rather then store it, and restore the MBR afterwards? It just seems to me like the obvious thing to do with this kind of attack.
Yes, they should, but sending data off a machine when you don’t have any OS to help you is formidably difficult – getting network cards working without drivers, wireless networks etc, all very challenging. It becomes a very targeted attack indeed.
If the space in the MBR is too small to include drivers for all the different network cards, wouldn’t the attacker simply generate (automatically) one version of the keylogger for each, and install the one that matches? I mean if it’s a laptop shouldn’t it be easy to identify what model it is (and thus what network card it has in it), and if it’s a desktop shouldn’t it be easy to just open it up and look? I don’t understand what the difficulty is. I think the only way to stop pre-OS keyloggers is with a WORM MBR. And even then the attacker could simply replace the hard drive itself.. in which case it could just boot into a normal OS like a lightwheight Linux distro, and use the drivers that it has already implemented, to send your password to him. This way only one access to your computer is needed. Will McAffee’s FDE prevent either of these? I don’t see how it could.
the mbr is 512 bytes 😉
sure, in theory you could write your own OS to support all the needed drivers etc, of course that assumes the notebook is hard-wired, what about if it’s on wireless? And yes, they could switch the drive entirely for their own one, but your attack is getting more and more niche. Why not replace your computer entirely with one which looks the same?
Of course no product is going top stop the user giving their password up to some other system – you can’t fix stupid after all.
You have to consider who is after your data – if it’s the CIA/MI5, then you’re sunk – they could do all this stuff, but if you’re trying to protect yourself from data disclosure laws and accidental loss, pretty much our who conversation is overkill.
Because only a few megabytes of space would be needed for a full lightweight OS, so such a hard drive would cost like $20 tops? Easily absorbed in the money they’d make selling the laptop or whatever else they stole, and the information they get could be worth an insanely large amount? I think many people outside of the CIA/NSA/MI5 would find this a worthy trade-off. And of course requires virtually no technical expertise since you wouldn’t need to make your own driver. What is so niche about it?
I think the solution is obvious, just noone has implemented it; three-way handshake. You put in one password, the computer uses this to decrypt its own which it promptly displays, and if it’s the right one you enter the second password which is the one used to decrypt the disc. I think the MBR is small enough that you could make the computer’s one use all remaining space in the MBR so that there’d be no room to put in a MBR virus and have it go resident and read the second password when you enter it. And the rest of the disk would be encrypted so obviously it couldn’t just write its payload to some other place in the disk and just patch the bootloader to point there, since it would try to decrypt first, and crash..
What is the problem? I’m sure I’m not the first to think of this, so there must be a real reason that this isn’t how it is done, and I want to know what that reason is. Please. I hate not knowing why things are the way they are. It is frustrating.
P.S. and yes I know that they can easily break this by just logging the first one, storing the whole thing, and then making it crash or something, and then making their own bootloader to say that password and ask for the real (second) one, but this would be impossible to hide, since they would have to make it crash or something after you enter the first password, rather then show the computer’s password, so you would know right away the computer has been messed with, and instead of giving them a chance to install ANOTHER modified bootloader and entering the second password, you would simply reinstall the bootloader and change the password. I can not think of any way attackers can avoid such a give-away. I think it should be impossible. But obviously it isn’t or all the FDEs would do this. So please tell me what is the problem? I think the current way is broken and mine would work better.. but they don’t do it my way.. so why not? :s
nvm I see the problem sorry. Too bad there is no button to edit posts on here lol.
My way would also be vulnerable to swapping out the hard drive, since they could simply put the encrypted password of the computer onto little OS in the new drive, make their own bootloader to boot into that and ask for your password and then decrypt it there and display computer password and ask for second password right away so you wouldn’t notice.. but.. even if it is broken, I think it is less broken then how it is now, since instead of just being able to swap in the new drive just like that, they would have to first take your drive to their computer, copy data from it into the new drive, and THEN plug in the new drive to your computer, for it to work, so that they will need more time to do it. And it really would be impossible with software, where as how they do it now, it is only impossible to send it, and even then, this rests on the assumption that it is impossible in 512 bytes to put code that will operate the network card (it wouldn’t need to be a full high level implementation of like the HTTP protocol you know, just send one single packet to their computer that only contains the password).
Thus I think my way is a lot better even if not perfect.
you are thinking like a sysadmin, not like a user – it’s hard enough to get people to use passwords, let alone a handshake (which as you say is trivial to reproduce). Your idea works though of course if you also have hardware encryption, because then you can’t copy the handshake response onto your rogue drive (it’s not available until after you authenticated). No user is going to go through that every time they boot though.
Well the storing it on a CD solution is even worse. It would be very hard to make sure nobody ever gets physical access to the CD or whatever (would you put it in your mouth/anus while you sleep? LOL!!). And if you do manage it why even have FDE? Just store your important stuff on the CD/DVD/BluRay/thumb drive/whatever it is. If nobody can get to it you don’t need FDE. So if the only way your FDE can work is if nobody can get to it, it is pointless.
Unless you have like a huge array of drives worth of data that would be too bulky to carry around, but then you are probably not some home user.
luckily, most people are not under targeted attack, so FDE works fine for them. FDE solves all the non-targeted attack issues which are the ones we tend to be most concerned with.
Okay I think I understand; it is just for if someone steals your computer just for the parts and doesn’t care about the data, but would like to take advantage of any credit card numbers or whatever that happen to be on it, as long as doing so doesn’t take extra effort?
I think then that it shouldn’t cost so much money.. but to each his own, I suppose.
no amount of effort is going to get you access to the data on a stolen computer. That’s why current FDE solutions are so valuable.
Only if the effort comes as an afterthought (E.G. after you have already stolen it, and the owner already knows you have stolen it), though, right? Or am I even more confused than I thought?
The only way to get the data if you have FDE, is to get the user to give you the password (or guess it). It can’t be cracked or bypassed.
???
[quote=http://www.thefreedictionary.com/bypass]1. To avoid (an obstacle) by using an alternative channel, passage, or route.[/quote]
If the design of the FDE allows you to get the password needed to decrypt the data, and there is no reasonable way for the user to know that this is happening until it’s to late, and you can do this to the user with only one access to their computer, why isn’t that considered bypassing the FDE? I thought that the purpose of an FDE is that somebody should need to access your computer more than once to get the data from it.. if it isn’t, what is?
p.s. how do I edit my posts? I am not used to the WordPress interface..
So now you realize why trojan attacks are so nasty, and why hardware based FDE is so interesting.
Hmm
By hardware do you mean TPM? I’m not sure if that will really help against this kind of attack. Or do you mean like having a little motion sensing device in the hard drive that corrupts it if it’s moved and hasn’t been logged into properly, to stop attacks like swapping the drive (or whole computer)? A defense would still be needed against software attacks like Stoned that don’t involve messing with the hardware, though, wouldn’t it? Like a three-way handshake?
Or did you mean something else entirely? I’ve heard of having keypads built into the drives to enter the password in.. but this wouldn’t help against attackers swappers drives (or the whole computer, like you mentioned).
no, I mean things like TCG OPAL.
It seems like it only helps against software attacks like Stoned? How will it help if an attacker simply swaps drives? There is a lot to read about it, so please forgive me if I missed something seemingly obvious..
this is one of the great articles that has helped me a lot thank you very much Blogging
What people are missing in the above “the os is too big to fit in the 512K mbr so its no use” is that waaaay back in the 80’s the early amiga virus writers hit the same limit. And some coders even wrote bootblock intro’s into that tiny space.
However, quite a few cheated by randomly picking a few blocks somewhere on the disk and hoping it wouldnt be overwritten before the virus had done with it, and the mbr would merely contain code to boostrap the extra sectors into ram and exec it.
You could pick some blocks right out in unallocated space or near the end of the partition and hope, maybe flag them as badblocks to stop the disk subsystem from using them after. It would only have to work most of the time to be wildly successful. We used trackdisk.device and subverted it for our own use, but there’ll be something similar in nature in modern bioses that bootstraps the machine anyway for the next boot stage. I havent played with disks for a LONG time to state the actual process.
Old dogs, same tricks just applied in a new way 😉
I was a bootblock intro coder not a virus author back in the day though.
Might dust off my x86 book next time I’m contractless 🙂
Perhaps I’m missing here something, but an extremely simple protection exists in my opinion: keep your computer running continuously (or at most in sleep/standby mode) with a strong enough screensaver password.
That way, if you return to your hotel room and find your computer still booted, you can safely assume that no one (who didn’t have your full disk encryption password before hand) could have overwritten your MBR. Else, if your computer is off and you are paranoid, assume it’s corrupted and wipe+reinstall it.
Or am I missing something here?
Yes. The attacker could just put a fake screensaver prompt instead of a fake pre-boot prompt.
How would that make a difference? Even if the attacker puts a fake screensaver prompt, how would the computer instantly resume the state it was left in?
As soon as the true owner sees that there isn’t a normal resume after the screensaver password, he could assume the system was compromised. So I still think my protection suggestion is very strong.
Too late by then unless you have no network connectivity or the attacker forgot to mirror your drive first.
Only if the attacker also mirrored the state of the RAM, and can resume the same state with the disk encryption key in memory. Otherwise, the attacker would not have the password for the whole disk encryption. Isn’t that so?
They’d have the password when you typed it into their fake prompt and it sent it to them.
(Which by the way we can safely assume that’s a capability the attacker doesn’t have, since if he would have it he could simply read the key directly and won’t have to bother with the MBR)
Which password that I typed into which prompt?
If I type the *screensaver* password and don’t get instant resume, I will never enter the disk encryption password on the compromised system, which means all the attacker will have is a mirror of the encrypted disk and the screensaver password – a useless combination.
If I type the screensaver password and *do* get instant resume, then I don’t see how the attacker would be able to change anything on my system while I was away (under the premise that the attacker doesn’t have the capability to read/write to RAM without being logged into the system)
If you have no problem remembering two strong passwords with nothing in common and ensuring that the power to your computer never gets interrupted, not even once, ever, and you prevent cold boot attacks somehow, THEN I can see it working.
Of course, with such physical resources available, why would you even need encryption at all? If the computer must be stationary and in a datacenter and never moved and have something physically protecting the RAM, why not just have something physical protecting the HDD and save yourself the performance?
I’m not even sure what you’re trying to say about the instant resume thing BTW.. are you trying to say that there’s no such thing as asynchronous network connections or threads?
1. the screensaver password doesn’t have to be *that* strong
2. there’s no problem with the computer losing power, as long as it happens in a secure location or when attended by the owner, and not during the relatively infrequent periods of time being left unattended in a “hotel room”
3. the problem is mostly relevant for laptops carried around, for which losing power when left in standby is highly improbable.
Cold boot attacks are indeed something this approach won’t mitigate.
(by “instant resume” I mean unlocking the screensaver and having all of the programs running in the same state they were left in. In other words, the RAM state should be indistinguishable to the user compared with the state it was left in)
If you keep it with you at all times then ya I guess it’s safe.