dimanche 4 avril 2010

L’authentification “pre-boot” n’est pas sans faille…

Un récent article de Joanna Rutkowska de Invisible Things décrivait comment récupérer le mot de passe utilisé pour l'authentification “pre-boot” avec TrueCrypt.

Voici une brève description du scénario d’attaque.

“Bertrand vient d’arriver à l’hôtel. Demain c’est le grand jour: la remise des prix attribués aux meilleurs vendeurs, et Bertrand en fait partie. Le lendemain, Bertrand laisse son PC éteint à l’hôtel, il traitera ses mails ce soir en rentrant. La femme de chambre profite de l’absence de Bertrand pour faire booter le PC sur sa clef USB afin de l’infecter. En rentrant Bertrand démarre son PC, entre le mot de passe de sa solution d’authentification et d’encryption “pre-boot”, saisie son mot de passe système et traite ses messages. Le lendemain matin Bertrand quitte l’hôtel comme à l’accoutumé en y laissant son PC éteint. La femme de chambre n’a plus qu’à faire booter le PC de Bertrand sur sa clef USB pour récupérer le mot de passe d’authentification et d’encryption “pre-boot”. Et Bertrand n’en sait rien! Il est maintenant simplement nécessaire d’”emprunter” le PC de Bertrand pour récupérer les informations souhaitées.”

Comme l’indique Joanna Rutkowska, TrueCrypt n’est pas la seule cible potentielle de ce type d’attaque.

Je n’ai pas résisté à l”envie de voir comment fonctionnait l’attaque dans un cas réel.

J’ai donc installé TrueCrypt sur mon PC portable et encrypté avec TrueCrypt ma partition système. En faisant cela lors du démarrage de mon PC, le mot de passe TrueCrypt m’est demandé pour permettre le lancement de mon Windows XP et la saisie de mon mot de passe système habituel.

Joanna Rutkowska dans son article nous fournit une image pour nous permettre de créer rapidement une clef USB bootable contenant l’exécutable pour récupérer le mot de passe de TrueCrypt. Mais j’ai personnellement rencontré quelques difficultés pour recréer cette image. Heureusement nous trouvons dans l’article d’Invisible Things le code source nous permettant de mieux comprendre l’attaque et de la reproduire avec quelques variantes.

Comme vous le savez déjà, si vous êtes un lecteur assidu de ce blog, je dispose d’une clef USB “bootable” avec Backtrack 3. Je vais donc simplement faire booter mon PC sur ma clef USB, puis lancer l’exécutable modifié et recompilé pour infecter TrueCrypt.

Après avoir copié le code source de l’exploit sur la clef USB et booté sur la clef, jetez un œil au répertoire qui contient le code source. Dans notre exemple:

> cd /mnt/sdb1/Misc/evilmaid/evilmaid-tc

snapshot3

Vous pouvez ensuite ouvrir avec votre éditeur préféré le fichier Makefile. On y trouve les commandes permettant de compiler notre exécutable. On note la présence d’un fichier “c” et d’un fichier “asm” qui contiennent le code de l’exploit. Le fichier “asm” est un fichier assembleur compilable avec nasm.

Vous pouvez alors compiler l’exécutable. Si vous rencontrez des difficultés avec le Makefile, vous pouvez exécuter les 3 lignes suivantes:

> nasm –f elf logger.asm

> gcc –m32 –c patch_tc.c

> gcc –m32 –o patch_tc patch_tc.o logger.o

Votre exécutable est alors patch_tc.

snapshot4

Puis allez dans le répertoire stick. Dans notre cas:

> cd /mnt/sdb1/Misc/evilmaid/stick/

snapshot2

On y trouve le script “shellstage2 qui est le point d’entrée principal de l’exploit. Le fichier stage2 est à modifier dans notre contexte. Ouvrez le fichier avec votre éditeur préféré:

snapshot5

Les lignes suivantes sont à changer:

- On associe la variable BASE au répertoire dans lequel se trouve notre exécutable patch_tc. Dans notre cas:

BASE=/mnt/sdb1/Misc/evilmaid/evilmaid-tc

- On vérifie que le disque cible correspond bien à /dev/sda. C’est notre cas.

- On commente les lignes permettant de monter le répertoire contenant notre exécutable dans la fonction run_evilmaid

Notre clef est prête pour la mise en œuvre de l’exploit.

Sur le PC cible on boote sur la clef USB et on lance stage2. Ce script permet soit d’infecter le PC, soit de lancer un shell, soit de rebooter. On choisit de lancer notre exécutable. Le PC est alors infecté. On attend que notre utilisateur se soit de nouveau connecté à son PC puis on reboote sur la clef et on relance stage2. On obtient le résultat ci-dessous:

snapshot1

Le script détecte que le PC est déjà infecté et récupère alors le mot de passe. Dans notre cas le mot de passe est “ErtyErty”.

C’est gagné…!

Source: Evil Maid goes after TrueCrypt de Joanna Rutkowska. Merci à Matthias pour le lien vers le blog de Joanna Rutkowska!

Tags:

del.icio.us Tags: ,,,,, -

4 commentaires:

  1. bonjour,

    cet article est très interressant et montre encore une fois qu'aucune protection n'est parfaite.

    cependant ne serait il pas interressant de proposé des parades à ce type d'attaque ?

    je vois 3 parades possibles (à dévelloper techniquement parlant, mes connaissances ne me le permettent pas) :

    1) interdire le fichier de "pré-boot" en écriture afin d'empêcher l'infection

    2) créer un fichier log signalant toute modification du fichier pré-boot (afin d'avertir et de permettre à l'utilisateur de contrôler)

    3) réécrire à partir d'une sauvegarde saine (à la création) le fichier pré-boot à chaque connexion (ainsi même si le fichier à été infecté il sera écrasé dès la connection)

    la 3ème solution me paraît la meilleure, mais les 3 sont compatibles.
    merci de m'éclairer si vous connaissez une parade à ce type d'attaque (vol de login en pré-boot)

    à bientôt

    RépondreSupprimer
  2. Une solution à ce type d'attaque est l'utilisation du TPM (Truster Platform Module).

    En simplifiant, on peut dire que le TPM est un micro-controleur qui permet de stocker les clefs, les mots de passe et les certificats. Il est fixé sur la carte mère d'un PC et il permet d'interdire l'accès aux données et aux secrets si la séquence de boot ne se déroule pas comme prévu.

    Chaque composant de la séquence de boot impliqué dans le démarrage calcule la signature du composant suivant. Si la confiance est rompue, un redémarrage est effectué.

    Par exemple BitLocker peut être configuré pour utiliser le TPM.

    Malgé tout on peut également imaginer de modifier EvilMaid pour qu'il affiche le "prompt" de Bitlocker, récupére le mot de passe et le stocke (en utilisant un accès réseau) puis informe l'utilisateur que son mot de passe est erroné. Bien que le TPM détecte la présence d'EvilMaid et refuse l'accès à l'utilisateur, le mot de passe est connu de l'attaquant.

    Le "graal" serait de stocker la clef d'encryption en deux endroits différents: dans une carte à puce et dans le TPM. L'attaquant ayant récupéré le mot de passe, devrait également posséder la carte à puce de l'utilisateur pour pouvoir accèder aux données.

    RépondreSupprimer
  3. Bonjour,

    Étant très intéressé par votre article, serait-il possible de m'indiquer avec quelle version de TrueCrypt avez vous effectué le test.
    De plus, si ce n'est la dernière version, savez-vous si le bug a été corrigé. En effet quand on regarde le site de TrueCrypt, il ne me semble pas qu'ils spécifient cette attaque.

    En vous remerciant.

    RépondreSupprimer
    Réponses
    1. Bonjour,
      Je n'ai pas effectué le test avec la dernière version de Truecrypt.
      Mais voici un lien traitant de la position de Truecrypt par rapport à la sécurité physique (http://www.truecrypt.org/docs/?s=physical-security). Vous devriez y trouver votre réponse. En gros, Truecrypt nous dit qu'il ne peut assurer la sécurité du poste de l'utilisateur si l'attaquant a accès à la machine de la cible et si la cible utilise la machine corrompue.
      Sinon re-contactez moi!
      Bien cordialement,
      Buz

      Supprimer

Partager avec...