Voici Stoned Bootkit, le premier bootkit visant les OS Windows entièrement chiffré avec Truecrypt.

Stoned remplace le bootloader de Truecrypt par le sien ce qui lui permet de se lancer avant l’OS chiffré puis de lancé l’OS avec le mot de passe que l’utilisateur rentre. Un attaquant peut donc lancer des programmes avant le démarrage de Windows et ainsi rendre vulnérable l’OS chiffré. Ce bootkit fonctionne avec TC 6.x et presque tous les Windows 32bits de 2000 à la RC de 7. Stoned ne peut fonctionner qu’avec les BIOS traditionnels. Les nouveaux BIOS EFI ne sont pas vulnérable.

Toutefois Stoned Vienna n’a que 2 de façon de s’installer :

• Soit un attaquant à les droits administrateurs pour réécrire la MBR afin de s’y installer. Ce qui veut dire que l’OS chiffré est déjà compromise.

• Soit un attaque a un accés phyique à la machine et peut installer stoned bootkit directement dans la MBR.

Et c’est justement ces 2 contraintes qui ont créer la polémique entre Peter Kleissner et l’équipe de Truecrypt.  Voici toute l’histoire :

Tout a commencé mi-Juillet quand  son jeune créateur de 18 ans, Peter Kleissner, informe l’équipe de TC de son travail en les prévenant qu’il va faire une présentation de son bootkit pour la blackhat 2009.

Dear TrueCrypt Foundation,

My name is Peter Kleissner and I am going to present in 2 weeks at
Black Hat USA 2009 my Stoned Bootkit which is able to bypass your TrueCrypt software.

« A bootkit is a rootkit that is able to load from a master boot record and
persist in memory all the way through the transition to protected mode and
the startup of the OS. It’s a very interesting type of rootkit. »

The bootkit which I am programming is able to bypass TrueCrypts system
partition encryption, and is doing its job very fine. You can find
more information about it at the projects website www.stoned-vienna.com.
Find a short PoC video uploaded at http://www.stoned-vienna.com/downloads/TrueCryptProof.mp4.
In short this means everyone can install a trojan to a fully (via TrueCrypt) encrypted computer.

Yet, there is no fix. It cannot be fixed. The master boot record
always stays unencrypted. The only solution would be using the Trusted
Platform Module in connection with securing the key for decryption. Are you
going to support the TPM module? (like bitlocker does)

Feel free to ask me for further information and technical details.

Kind regards,
Peter Kleissner
Independent Operating System Developer
Website: http://web17.webbpro.de/
Blog: www.peterkleissner.com

L’équipe de TC répond que son attaque ne les concerne pas car elle n’attaque pas une vulnérabilité de Truecrypt mais une vulnérabilité lié à l’ordinateur. Soit à travers un malware avec une session  admin soit en attaquant physiquement la machine.

Le lendemain, l’équipe de TC remet une couche mais cette fois-ci ils essayent de le dissuader de faire sa présentation en remettant en cause son travail de chercheur en sécurité informatique. Et en lui laissant entendre que le publique va se moquer de lui.

L’équipe de TC utilise cette argumentation :

• Si quelqu’un à les droit admin sur le PC, mettre un bootkit est inutile vu qu’il est admin c’est trop tard. Un utilisateur avec les droits admin peut tout faire sur la machine et donc lire la clé de chiffrement en claire dans la RAM ou les données déchiffré à la volée.

• La TPM n’est pas une source sure non plus pour les même raison. Avec les droits admin il est possible de reset la TPM.

Les dev de TC ne considère que ce n’est pas a TC de se protéger de se genre d’attaque s’appuyant sur les 10 lois de base écrite par Microsoft sur la sécurité. Ce qui en soit est vrai.

Von: ennead@truecrypt.org [mailto:ennead@truecrypt.org]
Gesendet: Sonntag, 19. Juli 2009 22:34
An: Peter Kleissner

Betreff: Re: AW: Stoned Bootkit attacking TrueCrypt’s full volume encryption

Hello Peter,

>1. Prevent writing the MBR under Windows – why would anyone would do
>that (if not for malicious purposes)?

Again, if the attacker can modify the MBR, then he already has administrator
privileges or physical access to the computer.

Once an attacker has gained administrator privileges or physical access
to the computer, the computer is insecure (compromised) and must not be used.

When the encrypted OS is running, a privileged attacker can easily do,
for example, the following:
– Disable any protection (such as checking of the hash value of the MBR)
implemented in the disk encryption software (by patching the running
program in RAM and then on the disk).
– Reset the TPM.
– Read the master key (or decrypted plaintext) from RAM and save it
unencrypted to an unused sector on the disk or send it to the attacker
over the Internet.

If the attacker can access the computer physically, he can easily do,
for example, the following:
– Install a hardware keystroke logger, which will capture anything the
user types (such keyloggers are inexpensive and readily available in
many computer shops).
– Attach a hardware component to the main board that will periodically
take snapshots of RAM and transmit them wirelessly to the attacker. Such
RAM snapshots will sooner or later contain the master key.

Therefore, it is pointless to defend against any attacker who already
has administrator privileges or physical access to the computer.

If you want to work as a security researcher, we highly recommend that
you first become familiar with the field. For example, start by reading
the « 10 Immutable Laws of Security »: http://technet.microsoft.com/en-us/library/cc722487.aspx

The law #1 and #3 apply to your report:
– Law #1: If a bad guy can persuade you to run his program on your
computer, it’s not your computer anymore.
– Law #3: If a bad guy has unrestricted physical access to your computer,
it’s not your computer anymore.

« Privileged attacker » is a non-existent term in the security field and
any attacks performed by a « privileged attacker » are invalid.

The above is fairly common knowledge among security experts (and if you
are really going to present this to the public, you seriously risk
discrediting yourself). We recommend you to withdraw the presentation,
because the attack is invalid (privileged attacker) and the other
information might even mislead someone into falsely believing that
TMP/BitLocker can protect against a privileged attacker.

>  2. You do not perform any security checks if the master boot record
> is still the original, why not?

Such checks would be redundant. If an attacker can modify the MBR, then
he has either administrator privileges or physical access to the
computer. It’s pointless to defend against such an attacker. See above.

> That would make full-volume encryption secure, even in an unsecure
> physical environment.

No, it wouldn’t (see above for explanation).

Regards,
Ennead

Forcément aprés un mail pareil, les choses s’envenime et Peter leurs réponds :

First of all I want to thank you for your response, I really appreciate
that. It would be unfair if I would not tell you what I am going to tell
about the TrueCrypt Foundation and TrueCrypt software at Black Hat, so
find the one slide handling the TrueCrypt attack in my presentation
attached (the whole talk is about « Insecuring Windows and the pre-boot environment »).

I will state in another slide and tell at Black Hat that my message to you
is « Secure your own software ». You can, could but you do not prevent
overwriting the MBR in Windows, and considering the signed driver
policy of Microsoft your driver would be secure (regarding the patching) – at least
under 64 bit Windows. So do not excuse to other problems/software, you are
responsible for securing your own software. Even I love TrueCrypt, and
that it is open source, and I use it, your security policy is simply lame.

An attacker (hacker) does not care about your physical access rules or
your 10 laws of security and so neither do I. Ignoring (invalidating) my attack
does not invalidate it for hackers, so please think twice about your policy.

At least this is your decision what to do with that attack and information
about it – well better for me and better for my attack.

Regards,
Peter Kleissner
Independent Operating System Developer
Website: http://web17.webbpro.de/
Blog: www.peterkleissner.com

Comme prévu Peter Kleissner fait sa présentation à la Blackhat qui est trés bien reçut.

Mais l’échange 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 protéger la réécriture de la MBR sous Windows. Cette solution est loin d’être suffisante et son autre solution en utilisant les TPM l’est encore moins comme le démontre l’équipe de TC ici.

Mon opinion est assez partagé les dev de TC ont raison, si un utilisateur à les droits admin ou un accés physique sur la machine, la machine est compromise c’est trop tard. Ce n’est donc pas la faute de TC. Mais c’est aussi vrai que si TC peut aider a éviter que la MBR soit réécrite a partir de Windows ce n’est pas plus mal non plus.

La réponse de TC ne devrait pas tarder. Rendez-vous pour le changelog TC 6.3 ? En tout cas le framework open-source de stoned bootkit est déjà disponible ici.