TrueCrypt Foundation is a joke to the security industry, pro Microsoft

21. July 2009

The TrueCrypt Foundation is a joke and their software is a security hole to the PC industry. I would recommend any company using Microsofts bitlocker solution instead of their encryption product. Why? Because of their security politics. They basically say if someone has access to your computer there is no longer need to protect it.

They are trying to fix their security holes with a bad security policy. Of course this does not work out, if there is a software security issue then it cannot be handled by security politics. It has to be fixed, by developers, not a policy. Saying “it is pointless to try to prevent” (from their mail) does not solve the problem.

I suggested them solutions, offered them my help, however they are ignoring the security issue, so I will make my TrueCrypt attack open source. The software I have developed is able to bypass the full volume encryption of TrueCrypt when booting the computer. And they could easily prevent the attack from a running Windows – but they do not.

My “SecureTrueCrypt” patch to secure TrueCrypt:

DriverFilter.c:663 in function DriveFilterDispatchIrp():

        else if (irpSp->Write.ByteOffset < 63*512)
          return STATUS_ACCESS_DENIED;

These 2 lines would secure the MBR from overwriting and would prevent the TrueCrypt attack in Windows. I am a developer, not a “security policy” propagandist as the TrueCrypt Foundation representer Ennead. Of course these two lines are not perfect, there should be a GetMBRSize() function that dynamically determinates the max. size of MBR (i.e. = start of first partition), and there should be additional checks in the driver and the boot software if the MBR is genuine. However, even if not perfect, this would be a good start in securing TrueCrypt.

46 Kommentare zu 'TrueCrypt Foundation is a joke to the security industry, pro Microsoft'

  1. Thomas sagte am 31. July 2009 um 12:37 am Uhr:

    Hi Peter,

    its very sad to read that you really really didn’t understood what truecrypt wanted to tell you. I’m happy that you attached the mailing to you source code. You are offending them and just don’t realize what they want to tell you, thats just ridiculous.

    Well first of all, congrats to your “bootkit”. It’s great to such a young man with a great coding knowledge, i’m impressed. But maybe your a bit _too_ young to understand whats the matter here.

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

    So whats the difference? The difference is that your bootkit is:
    1) very hard to detect
    2) able to read the “you name it”-crypt master key

    These are facts which are logical derviated without knowing how exactly your bootkit works. A “ordinary” rootkit can also read fully encrypted data after windows boots. So your rootkit can.

    It’s sad that _you_ are so ignorant and ignoring that simple facts. Everyone who has some little knowledge about computer since/security laughs at this blog entry. Please rethink your statement and tell anybody the truth about it.

    Your patch is actually patching nothing. Even _your_ bootkit could hook that call easily and you surely know that. I don’t really understand why are you don’t realize that truecrypt or any other software _can’t_ be secured. In fact, no software could.

    Beside that, your’e a great coder. I wish you much luck in your future, but please think twice before you throw something “big” in the security community.

    Best regards,

  2. Thomas sagte am 31. July 2009 um 7:32 am Uhr:


    you are _unable_ to overwrite the MBR if you don’t have administrator privileges or physical access. It’s not truecrypt’s (or any other software app’s) task to overwatch if a program on your computer gets administrator privileges.

    Even if truecrypt would check the mbr checksum (which by the way any current motherboard also does), your computer is _lost_ when something/someone gained admin privileges on your computer. This check would also be useless if someone gets physical access.

    Please stop offending others, that’s not how you should behave in public. If you would be right, no offending yould be necessary :-)

    Best regards,

  3. Philipp sagte am 31. July 2009 um 8:47 am Uhr:

    Hi Peter,

    Thomas is right. In all his points.

    First technical: As long as you do not have administrator priviledges, you are not able to overwrite MBR. You said yourself: “they could easily prevent the attack from a running Windows”. Well, they don’t need to. Windows prevent’s changing the MBR for nonadmins.
    But what if Windows ain’t running yet? If you are “on the RAM and CPU” before the OS, there’s literally nothing you can’t do.
    Be the one who calls the OS’s bootloader (and thus kernel) and you can do whatever you want to any OS. It can’t prevent or fight it, cause you have the “older” priviledges.

    Second social: Even if you were right and those guys don’t want to fix that issue it’s a no-go offending them as you did. Don’t get me wrong, I am as impressed as Thomas on your technical skills.

    You’ve impressed lots of computer guys with your hack. Don’t kick yourself out of business by attacking them with no need.

  4. Christian sagte am 31. July 2009 um 11:32 am Uhr:

    Hi Peter,

    you have a point with the idea, that one should make it harder for an attacker to override HDD cryptography, but I think you are assigning the task to the wrong people.

    TrueCrypt’s job is it to encrypt the hard drive. An administrator may disable or modify the encryption and TrueCrypt just does not make it harder for an administrator to do so. An administrator may have legitimate reasons to change the TrueCrypt bootloader, maybe to replace it with Grub to chainload TCBL, just an example. Why should TrueCrypt obstruct this?

    Who’s job is it, to ensure that ONLY a legitimate administrator can do these potentially harmful changes? In my opinion, it’s the operating system’s. If each do their job, TC encrypts the drive and the OS makes sure, no unauthorized program or person changes the encryption tool.

    This is a kind of “It’s not a bug, it’s a feature.”: Administrators should be allowed to tamper with the TrueCrypt bootloader. It’s not TrueCrypt’s job to make sure that an unauthorized program/person does not gain administrator privileges.

    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.

    best regards


  5. Christian sagte am 31. July 2009 um 11:49 am Uhr:

    Here’s a little paragraph that I forgot:

    Please compare: With the Linux soltion dm-crypt (, the whole kernel is in an unencrypted partition (usually /boot). Still, the procedure is considered secure, because only root or someone with physical access should be able to write /boot. Read access is not critical, since the kernel is free software anyway ;-) As you can see, it’s not only TrueCrypt but kinda common practice.

  6. Thomas sagte am 31. July 2009 um 4:47 pm Uhr:

    Hi Peter,

    thanks for giving a chance for a neutral discussion, i appreciate that.

    Of course it’s correct that truecrypt _could_ be checking the MBR for alteration. But that is no fix at all. A virus which gains privileges is possible to replace the whole TC bootloader. And so modify the MBR check. Thats why no software could ever protect this attack, beside the OS. And yes, the MBR is not part of the OS but part of the hardware. And the OS has control over the hardware. If you let software gain control over the OS, it’s YOUR fault (or the OS’s if it’s simply a bug).

    The only method i know about would be a hardware verification like TPM or intel’s TXT does. Please tell us why this doesn’t work out for _you_.

    Best regards,

  7. Airflow sagte am 31. July 2009 um 5:14 pm Uhr:

    I agree with Toaster, I dislike admin or non-admin gibberish whereas most of those non-admin preachers likely never use non-admin because of its bad handling. 90% of people uses admin nobody of you non-admin preacher will change this fact.

    It is Truecrypts task to secure computer systems the most effective way. Critics are justified.

  8. Spliff sagte am 31. July 2009 um 5:38 pm Uhr:

    I disagree, if TC tried to protect the bootloader with checksums it still would not secure against this kind of attack. As the malware running as admin could just as easily modify the stored checksums.

    Everybody knows you should not run untrusted binaries as root. This is nothing new.

  9. Airflow sagte am 31. July 2009 um 7:34 pm Uhr:

    Binaries should have no access to mbr. The computer hardware concept fails by default. The industry is the key problem. I suggest a alert system for truecrypt, it should not also verify checksums and lock up critical areas but also surveil mbr.

  10. Christian sagte am 31. July 2009 um 8:00 pm Uhr:

    Hi Peter,

    You asked for a non-malicious purpose of rewriting the MBR. Here is an example: Grub is put into the MBR to replace TC, then Grub chainloads the TC BL from a different sector to run windows. (

    Besides, TrueCrypt may need to update its own bootloader from time to time. An administrator (and only an admin) should be able to perform that update.

    Okay, the world is full of AWAKs (admins without any knowledge), so there should be software that protects the MBR from accidental or malicious writing. Good places:

    - The OS: Because it really is responsible for who may change the system configuration and the MBR is system configuration
    - The BIOS or EFI: Because it can reduce the risk to physical accessors
    - Antivirus Software: Because it shall protect the OS from malware (And even here, it would give me a bad taste, because the OS should not need an AV to prevent MBR tampering)

    But now let’s face the problem from a whole different side: Let’s assume, TC would include MBR checking. Then how would we make sure, that a rootkit does not override it? I don’t think we can, but TC offers a nice way to deal with it: Create a TC rescue CD-ROM, delete the HDD’s MBR and always boot from the CD. Keep it in a safe place, when you’re away. This prevents us from the risk 100%. So why not use this in first place? Software MBR checking will just provide another injection vector.

    best regards


  11. Daniel sagte am 31. July 2009 um 8:14 pm Uhr:

    Hi Peter,

    when I first read abour your attack on TrueCrypt, I was alarmed. Then I spent an hour reading more details about Soned, and I calmed down again. I don’t see a security breach here.

    What you have developed is some code that can be installed on a hard disk that’s fully encrypted with TC. There are two scenarios:

    1) Installation while Windows an TC are running. This is not a very interesting case, because while Windows is running, TrueCrypt does not offer any security. The encryted disk can be accessed as if it was unencrypted anyway.

    2) Installation while the TC-encrypted disk is not mounted (e.g., by booting from a USB stick etc). Until now, other boot kits could not infect a Windows on a TC-encrypted disk. Yours now can at the very moment someone inputs the TC pass phrase. This is new. However, there are many ways a similar result could be achieved – a key logger is one example.

    In this second scenario, TC is not running while the MBR is being overwritten, so they can’t prevent this from happening. And once TC boots, your boot kit is already active and can intercept all attempts to validate the MBR’s integrity. That means adding such checks to TC would not improve security. On the contrary: they’d be snake oil – they’d create a false sense of security for the user.

    This is why I think TC is right in *not* adding such bogus and misleading checks. Instead they do the only reasonable thing: they clearly state what TC can do, and especially what it CANNOT do.


  12. Myk3 sagte am 31. July 2009 um 8:17 pm Uhr:

    Where can i get a copy to test with???

  13. Spliff sagte am 31. July 2009 um 9:11 pm Uhr:

    Even if the mbr was protected. (TC does offer a way to do this – boot from the CD – there is no way you can overwrite that!)

    That does not matter, running malicous code as admin can never be secure, even I as an amateur programmer could craft an executable that would compromise a fully encrypted system if run with admin privildges:

    I could:

    - Setup an ftp server with access to the entire filesystem.
    - Capture all the users keystrokes.

    Once you run untrusted code with such elevated priviledges it’s game over, writing the mbr is just one way to compromise your data, there is no way to protect against this.

    Peter – do you run every executable file strangers email you with admin access? I suspect not.

  14. Toaster sagte am 1. August 2009 um 1:04 pm Uhr:

    Ok I think I should give this discussion now a final thought. Well, the TrueCrypt Foundation is perfectly valid with their sayings – it is not the job of TrueCrypt to secure the Master Boot Record.

    Beside attacking the MBR there are of course other attacks as people have mentioned, e.g. use of hardware keyloggers, cameras, a software keylogger in the MBR etc. Of course a developer will not be able to handle all this threats, and for this we need security guidlines (policies) to define an environment where software is secure.

    Where this is all true my intentions were making TrueCrypt a bit more secure. My suggestions were just suggestions, no personal offendings. We are all professional here and can handle differences.

    For me there is a point where software can secure its own and I think that a possibility should be taken regardless of a security policy or to whom a task belongs (if Windows should prevent the MBR writing or not, Administrator or not etc). We want to protect the end-user that does not know anything about the computer stuff.

    My advice to volume encryption software vendors are still (the same I mailed TrueCrypt Foundation):
    1. protect the MBR in Windows from being overwritten
    2. add in the driver a verification of the MBR (if not genuine then restore and display the user a warning)
    3. take use of the Trusted Platform Module to verify the startup, that would be a nice extension to encryption software!

    These 3 points would make the software and the pre-boot environment much more secure (especially against previous boot viruses). And these points are advices – I will not tell TrueCrypt how to develop their software, that is their job.

    And finally I want to point out that TrueCrypt was only “beside development” of Stoned (bypassing encryption was 1 slide out of 38 on the presentation). My target was to pwn all Windows versions from XP up to 7 RC, and I got that working. So I think I was very successful and have reached my target. Thank You.

    Beside that, I am the good guy. I have provided Microsoft, TrueCrypt and AVs with samples, information and help. Off the list, I have not told anyone, so no one knows, but why should I tell someone? It is also really crazy how many critics say “Nothing new.” or other curious things, I wonder how many of these people read the paper (in which I make perfectly clear statements). I am against any offendings that I would be a hacker or anything like that – I am a developer, keep that in mind.

    Peter Kleissner

  15. Airflow sagte am 1. August 2009 um 1:11 pm Uhr:

    There are some things I still don´t understand. Can stoned bootkit compromise a offline computer before anything is loaded? I guess a living windows system is needed to install it, isn´t it? A pure encrypted offline computer isn´t affected except someone accidentally executes infected.exe, right? Or dos it work from Dos Bootdisk or Boot-Usb?

    I ask this because you mentioned that it could work for the police e.g. as forensic tool to generally break disk encryptions.

  16. Airflow sagte am 1. August 2009 um 1:31 pm Uhr:

    Okay then I understand and I agree with you that this is a checkmate situation for truecrypt foundation. I don´t see any sense to use truecrypt for windows in future because this technology easily circumvents every approach to secure data for windows computers. So TC makes only sense for linux users.
    Everyone who tries to defend TC for Windows is therefore on the wrong way. Thanks for the clarifications.

  17. Michael sagte am 1. August 2009 um 2:12 pm Uhr:

    Peter, you are very wrong saying “Stoned is able to bypass TrueCrypt”. Stoned cannot bypass anything. It behaves like many known boot sector viruses. It just installs itself in the OS, does not bypass TrueCrypt. TrueCrypt bypass should allow to boot the system without knowing the password. Your trick does not allow that.

    Another wrong statement: “you can install any software with Stoned”. That is not true. Imagine one partition disk drive protected with TrueCrypt. Assume you somehow gain physical access to it. How would you install “any software”? Do you know how little space you have on the boot sector? That is simply impossible.

    And what about antivirus software? They do not allow to modify MBR, so your trick will be easily detected while attempting to run it on a computer protected with AV.

    Conclusion: similar viruses (more advanced) exist in the world for many years. Please do not try to rename old ideas.


  18. Spliff sagte am 1. August 2009 um 2:27 pm Uhr:

    @Peter, You were successful in writing a boot sector rootkit that effects all current versions of windows. This is a major acheivement.

    People will not notice that when you make silly claims like you have defeated true crypt, or any encryption for that matter.

    Your sensationalist headlines like “True crypt defeated” or “bypassed” are misleading. As Michael pointed out, for this to be true you would need to be able to mount a true crypt system or volume without knowing the password – your software does not allow this.

    If you want to salvage the respect you rightfully deserve for your acheivement, you should make a statement to that effect.

    You say you did not want to offend anyone, the title to this blog post “TrueCrypt Foundation is a joke” suggests otherwise.

    @Airflow. An approach like this is not exclusive to Windows. Encrypted linux installations also have unencrypted boot partitions that software running as root could modify. Peter has even stated in another post that he was working on a linux version.

  19. Toaster sagte am 1. August 2009 um 2:52 pm Uhr:

    Calm down : )

    How many people here read my paper? The TrueCrypt attack is only 1 page out of 46. And in the presentation it is 1 slide out of 38.

    I am not making any sensational about it – you are. All those comments here making it. I am only about developing it and writing about the development. Also it is the way how you interpret this (these headlines) – and do not take everything too literal.

    Peter Kleissner

  20. Airflow sagte am 1. August 2009 um 4:51 pm Uhr:

    So linux is also included. The statement of TC is questionable. Physical security is not a prerequisite if someone needs to secure a stolen laptop. Nobody needs full system encryption if it doesn´t cover physical insecurity.

  21. Spliff sagte am 1. August 2009 um 5:22 pm Uhr:

    True crypt _will_ protect the data on a stolen laptop.

    They are talking about physical security during normal use.

    This attack requires that a user already logged in with correct credentials executes a program as with root privilidges which installs itself in the bootloader and captures the password/encryption key the next time you boot your computer.

    This attack has been known for years and it’s not unique to Windows or True crypt.

    The way to protect against it is the same way you should protect against all viruss, trojans, keyloggers and other malware – don’t run untrusted binaries as root.

  22. Spliff sagte am 1. August 2009 um 6:29 pm Uhr:

    He means you can patch the bootloader in this way.

    You can’t install, or even read anything on the disk without the encryption key or password.

  23. Michel sagte am 1. August 2009 um 6:40 pm Uhr:

    I would like clarification from Peter. Simple question, Yes or No. Can somebody with physical access to my shutdown laptop (not running) have the ability to execute your exploit? Again, add all you want but a simple Yes/No would suffice.

  24. Spliff sagte am 1. August 2009 um 6:45 pm Uhr:

    @Michel, I assume you mean’t to say “true crypt system encrypted laptop”?

  25. Christian sagte am 1. August 2009 um 8:19 pm Uhr:

    @Michel: If you are asking “yes or no”, you have not understood Peter’s work. I will try to give you a short comprehensive answer:

    Yes, but the exploit has 2 phases: One, the attacker installs the exploit on your MBR and leaves. Two: You return and think nothing has happened, enter your password and the exploit takes over your PC.

    Countermeasures: Do not use a TrueCrypt bootloader on your hard drive but only boot from CD.

  26. Michel sagte am 1. August 2009 um 8:35 pm Uhr:

    On different boards there seems to be differing information. This is a VERY important point as to whether this can truly be executed against a shutdown PC with TrueCrypt system-encryption. It appears he presented it one way and then now is saying something different in a reply in this thread. It’s either one way or the other. Either it CAN be done (via USB, etc.)on a shutdown system encrypted with TrueCrypt or it CANNOT. If one must need adpriv and such, the answer is clearly no. This means this “bootkit” is no more sinister than a keylogger or anything else that could be placed on a system. As I read somewhere else, “a compromised system is a compromised system.”

  27. Daniel sagte am 2. August 2009 um 12:27 am Uhr:

    @Michel: I have read Peter’s paper, his presentation and this thread. Your question (“Can somebody with physical access to my shutdown laptop (not running) have the ability to execute your exploit?”) can only be answered the way Christian did. Let me say this again, in different words: Stoned *can* be installed onto your shut-down, TC-protected laptop, that is true. BUT (and that a very big BUT :)) your encrypted data is still secure until the next time you input the TrueCrypt pass phrase and boot the OS. Exactly at this point in time, Stoned can infect your OS, because TC now allows read/write access as if it were unencrypted.

    So, TC still secures your data if ever your laptop gets stolen. TC is *not* compromised.


    PS: Unfortunately, Peter routinely forgets to mention the fact that you need to enter the TC pass phrase *after* Stoned was installed (I am ignoring the rather uninteresting case that Stoned gets installed while the OS is running, i.e. TC allows access to the encrypted file system anyway.)

  28. Dand sagte am 2. August 2009 um 1:38 am Uhr:

    If people are actually worried that they got infected, all they would have to do is run truecrypts rescue disk. Your attack is not new, indeed tonnes of people have downloaded truecrypt source and recompiled it to make mallicious 63 sector code versions. I have my own MBR that hard-wires a password so I don’t have to put it in when I don’t want to.

  29. [...] [...]

  30. Airflow sagte am 2. August 2009 um 7:38 am Uhr:

    “PS: Unfortunately, Peter routinely forgets to mention the fact that you need to enter the TC pass phrase *after* Stoned was installed (I am ignoring the rather uninteresting case that Stoned gets installed while the OS is running, i.e. TC allows access to the encrypted file system anyway.)”
    “If people are actually worried that they got infected, all they would have to do is run truecrypts rescue disk. Your attack is not new, indeed tonnes of people have downloaded truecrypt source and recompiled it to make mallicious 63 sector code versions. I have my own MBR that hard-wires a password so I don’t have to put it in when I don’t want to.”

    By the way Peter could show us a video with live action of stoned bootkit I mean client (framework) – server (infected mbr) activity. I found this cmd.exe escalation video very boring and featureless.

    Note by Kleissner: Again, I am a developer, I don’t care if you like the show or not. The cmd.exe privilege escalation shall only show (proof) that the bootkit attacks the Windows operating systems. However, feel free to write your own payload! You can simply write your own driver and exchange it. If its good, I’ll place it up to the projects site. Kind regards.

  31. Toaster sagte am 2. August 2009 um 3:15 pm Uhr:

    This is a developer blog! I will delete all non-technical statements and personal offendings.

    You should post for example
    – feature requests
    – bug reports
    – technical questions
    – compatibility reports
    – overall impression/experience on the software

    You should not
    – tell me “Nothing new.”
    – tell me about MBR bootkits, read my papers and analyses if you want to learn something
    – personal offend me

    Note that
    – in 60% I agree to your statements (even I don’t say), so don’t repost everything!
    – TrueCrypt is perfectly valid without changing anything, however they have the possibility to (and they should use it)

    Stay technical, calm and be polite, just like I am =).

  32. Anonymous sagte am 3. August 2009 um 8:43 am Uhr:

    does it work for 64bit Windows? 32bit Windows are almost dead

    what about 64bit compatibility? can you run there your driver?

  33. [...] avec l’équipe de TC lui reste en travers de la gorge et publie le 31 juillet un billet virulent sur on blog personnel attaquant les dev de TC tout en proposant des solutions pour [...]

  34. shuba sagte am 4. August 2009 um 8:39 am Uhr:

    No, it won’t work with x64 Windows :(

  35. George sagte am 4. August 2009 um 9:22 am Uhr:

    Can this read the password for a true crypt hidden os as well?

  36. anon sagte am 4. August 2009 um 1:05 pm Uhr:

    This “trick” is a rootkit (virus). It WILL NOT read any password.

  37. [...] 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 [...]

  38. Serianox sagte am 12. August 2009 um 5:33 pm Uhr:

    I read your paper and your presentation with a lot of interest. I found it very clear and with a lot of good ideas.

    I’m actually on the other side of the fence. For now, I’m on internship working on a boot loader that can prevent your kind of attack using, but not limited to, integrity measurement (that’s the reason why I found it interesting).
    I believe that TC developers are completely overlooking where the real danger is. Of course, someone with elevated privileges on your computer can access your MBR thus adding a malicious boot loader. But then, why would he need to do so, because he already has access to your data.
    However, let’s imagine that someone power off your computer and reboots it with a USB pen drive that add a malicious boot loader. When you power on your computer again – Hey, my comp’ went off! – , it would steal your password. Then the attacker only needs to physically steal the hard drive and your data are stolen, with the key.
    Of course, this scheme can be very easily avoided with an integrity measurement that would be located inside the encrypted device. This is, I think, the idea behind your sample code (I don’t know anything about TC source code).

    “Some encryption programs use TPM to prevent attacks. Will TrueCrypt use it too? … No. Those programs use TPM to protect against attacks that require the attacker to have administrator privileges or physical access to the computer … However, if any of these conditions is met, it is actually impossible to secure the computer … If the attacker has administrator privileges, he can, for example, reset the TPM … The only thing that TPM is almost guaranteed to provide is a false sense of security”

    After having worked two months on TPM, I’m sure they are completely misled. They do not even understand what this technology is for and how it can be used to secure data. Also, I do not even understand why they aren’t making any integrity measurement; it only requires a few lines of code!

    Again, good job. I’ll keep an eye on it.

  39. Eddie sagte am 20. August 2009 um 3:21 am Uhr:

    Ok so I need to put my two cents in because your headline is very misleading. It got me intrigued on the concept. But I quickly disregarded for two reasons.

    1) This type of concept and hack has been around for years..makes no difference if I authenticate the TC bootloader with the password and browse the internet and get infected with a virus..

    2) TC is not concerned with the MBR…I’m not either.. TC is meant for one thing… IF my desktop gets stolen.. it prevents the theif from accessing my data because they will need to know the admin password to the bootloader. Thanks for making your code open source.. it makes antivirus vendors jobs easier on coming out with definition files to detect this kind of attack vector.. I commend you with the hack.. its a great find. But still mislead..

  40. Flo sagte am 22. August 2009 um 2:16 pm Uhr:

    Hi Peter!

    Congrats to your attack vector! You did a great job there.

    But as everyone else, I agree with Thomas. You didn’t really get what TrueCryptF was trying to tell you.

    Your Bootkit is indeed hard to find an hard to remove but it’s not really an attack against Truecrypt. Again, like most, if not every, virus, it’s relying on the stupidity of the user. If someone authorizes a program he does not know and lifts the rights of the program to administrative level, TrueCrypt can’t really do anything about it. If you have administrative priviledges or physical access, it’s over. Then you wont even need a rootkit or anything. A simple keylogger will do the job. And you could make that thing as hard to detect as your bootkit. With physical access it gets easier to attack. Just let that person boot and perform a Cold Boot Attack.

    And the second thing I wanted to say, I don’t really think your living up to the expectations of a real “Hacker”, simply because you want to help the authorities. This simply shows that you are coding without knowing what harm you could do. The “Bundestrojaner” even combined with your Bootkit is, for the people who know what they are doing, no threat. Honestly, take your time and think about your motives.

  41. Nick sagte am 8. September 2009 um 6:10 am Uhr:

    Since this scenario is dedicated to Disk encryption, can this also bypass folder/data the is encrypted with TC (note: machine is already infected by the user did not mount the encrypted folder).

    Can Stoned forcely open this encrypted Folder or Data? how?

  42. JackDevlin sagte am 27. September 2009 um 8:13 pm Uhr:

    As everyone else has already said your attack is nothing new it is a simple man in the middle attack. The fault is on the user running as admin for 1) running as admin 2) executing untrusted code 3) for not verifying the system was not tampered with while the admin was away. People tend to be complacent in their security policies, and policy is where the failure takes place in your attack. Your exploit can be installed from any os and no os, you could simply write it directly to disk using a hex editor on a macintosh. As you had PHYSICAL access to the computer which is almost as much privilege as ADMIN. The admin does not verify the disk is untouched since their last use and thus opens theirself up to any bootloader booting the computer. There is NO WAY TO PREVENT A BOOTSECTOR ATTACK UNLESS YOU PREVENT ANYONE FROM WRITING THE BOOTSECTOR AND PHYSICALLY LOCK DOWN THE PC…but lets face it if you did that to your test system you would not have been able to develop exploit which is a marvel in itself but as said previously nothing new, just a new name for an old trick, even the old boot sector viruses of the 1980s were capable of intercepting calls the the disk and modifying data etc if the user did not verify they had a clean bootsector prior to letting the computer boot the drive up. That is the insecurity, the policy is no physical access or a good reason, if you can touch the computer any attempt to lock down the boot sector is futile, your platform depends on a complacent admin to trust a bootsector on a system that was not physically secure which is a violation of most IT policies. Any software loaded after the infected bootsector is blind to the infection and can not without doubt verify the system as clean. The insecurity is the computer HARDWARE makes no effort to protect the drive or verify its contents to a known good image prior to boot, as NO SUCH HARDWARE EXIST in the PC world. The computer simply boots and does not care what it boots. As others said previously booting from CDROM would prevent this problem. Theoretically you could hard code the bootsector into bios but bios itself can be modified using software thus it is not secure either from a physical attack. What if you did have such a secure computer? How secure is the data on your drive if someone takes the drive and puts it in an identical computer without said bios protection and back in your hands…how closely will you check that computer before turning it on (especially if you did not know anything was switched) and trusting that it is your computer? Again the only full proof policy is NO ACCESS as all….but then what computers are useful when no one can access them?

  43. Der Kuchen ist eine Lüge - 2 + 2 = 5 sagte am 21. October 2009 um 11:41 am Uhr:

    [...] zu übernehmen. Worauf ich hinaus will, ist eigentlich auch etwas ganz anderes. Folgt man der Diskussion im Internet und klickt sich durch die Trackbacks, dann landet man nach kurzer Zeit bei einem [...]

  44. [...] Stoned Bootkit adalah virus yang menyerang sistem operasi Windows, mulai dari Windows 2000 sampai dengan Windows 7RC. Stoned sendiri sebenarnya adalah virus jaman baholak… virus stoned pertama kali muncul pada tahun 1987, kemudian Peter menulis versinya yang lebih canggih. Virus ini menyerang Master Boot Record dengan cara mengoverwritenya.. , bisa di download di…; kalau mau.. hehehe…Stoned Bootkit inilah yang kemudian membawa Peter menjadi pembicara pada acara BlackHat: Hacking at Random 2009. setelah menjadi pembicara di BlackHat, Peter diminta keluar dari Ikarus karena banyak komplain. Yah… hmmm.. gimana ya.. dia kerja di perusahaan anti virus, tapi malah bikin virus… banyak yang pro maupun kontra dengan kejadian ini. Stoned Bootkit juga pernah rame dengan TrueCrypt, baca di Peter Kleissner VS TrueCrypt. [...]

  45. Neil sagte am 21. December 2009 um 12:23 pm Uhr:

    Hi Peter.
    Nice work (though the title of this page is a bit of a shame :-)).

    One point others have raised and I’ve not seen a clear answer to above:
    If someone obtains physical access to a powered-off TC-encrypted PC and tampers with the MBR, it seems clear that they could install a keylogger etc. (space is very limited, but let’s assume they find enough). My question is: do you have any comment on this particular attack, and its apparent unpreventability, and Bitlocker’s susceptibility (or not) to the same attack?
    (When I say unpreventability btw, I do realise that booting with removable media is a way to protect against it.)

  46. duoug sagte am 24. May 2010 um 5:11 am Uhr:

    In conclusion, the joke is on you, Toast-Brain.

Hinterlasse einen Kommentar

Theme von BenediktRB • Powered by Wordpress • Abonniere den RSS Feed