samedi 31 décembre 2011

Petit conte de fin d'année, mais histoire vraie quand même.

En cette période de fin d'année, je propose un petit conte qui sort de l'informatique et de la sécurité, ou pas.

L'histoire qui suit se passe il y a quelques années et aucun nom ne sera cité.
Or donc, il existait un centre commercial comme il en existe tant, avec, dans la galerie une bijouterie. Cette bijouterie se présentait en forme de L. La barre principale était ouverte sur la galerie, agrémentée d'une caisse en son milieu, et la barre du bas, au fond, avait un second comptoir, réservé aux réparations.

   +-----+
G      V |
A        |      V: victime
L        |      C: caisse principale
E   C    |      R: comptoir de réparation
R        |
I        `-----+
E             R|
              R|
   +-----------+    

Le week-end avant les fêtes, une foule importante se pressait dans la galerie marchande et dans la bijouterie. Comme cela se fait souvent, pour absorber ce surplus de clientèle, quelques intérimaires aidaient à la vente. Ils étaient habillés sobrement, d'une chemise blanche et d'un pantalon noir.
Sur ces entrefaits, aidé d'un complice, je me suis glissé vers le haut du magasin, habillé également d'une chemise blanche et d'un pantalon noir, couvert par un pull. J'ai rapidement repéré une cliente ayant en main un bon de réparation de bijou. Prestement défait de mon pull, je l'aborde en lui demandant si je peux l'aider. Discussion, vérification que son bon de réparation avait été payé, et je la laisse sur place en consultation des nouvelles collection de nouvel an. Je remet le pull et arrive au comptoir du fond pour récupérer le bijou.
Le bijou m'a été donné sur présentation et vérification du bon, et j'ai pu partir discrètement de la bijouterie par le côté opposé à la victime. Du fait de la foule, la cliente ne m'a pas vu partir, et les vendeurs légitimes n'ont pas vu la manipulation.
J'étais donc hors de la bijouterie un splendide collier orné d'un rubis dans la poche.
[Petite précision pour ceux qui s'en inquiéteraient: mon honnêteté n'ayant pas de limite, je suis retourné dans la bijouterie pour rendre le collier à sa propriétaire, c'est donc une histoire morale qui finit bien :-) ]

Etant sur un blog de sécurité informatique, que peut on dire?
  • J'ai joué le rôle d'un proxy malveillant entre un client et un serveur pour intercepter des données d'authentification. 
  • La surcharge de fin d'année a empêché la détection du "rogue proxy" (si vous ne pouvez effacer vos logs, noyez les!)
  • Le client n'a pas pensé à authentifier le serveur. Pensez http"S"! ou typosquatting. Un peu de social engineering a suffit.
  • Enfin, le véritable serveur a fait confiance uniquement au cookie d'authentification (le bon de réparation). Une double authentification aurait été préférable: bon de réparation+authent via CNI par exemple, il était évident qu'un bon intitulé à un prénom de consonance féminine aurait du éveiller un soupçon. Le cookie d'authent pour entrer et faire des opérations (demander l'état de réparation du bijou) mais une seconde authentification pour la remise du payload reste une option intéressante.
  • L'extrusion du payload fût caché dans un paquet de données standard: moi, un client lambda avec un pull gris qui n'éveillait aucune suspicion ou regard de la part des vendeurs légitimes. Pour extraire des données, chiffrez les (flux SSL)!
Sur ce, bonne année, et happy hacking! (et n'allez pas dans les bijouteries faire des bêtises!)

EDIT: Christophe Pradier (RSSI de l'hôpital de Valenciennes) a traduit ce conte en anglais sur son blog!

mercredi 14 décembre 2011

dm-steg : la plausible deniability sous linux, ou pas.

Un lecteur du blog m'a fait suivre un message de la mailing list dm-crypt: http://permalink.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5543. L'auteur, Samulis Leopold propose un module noyau et les outils associés proposant un nouveau mode de chiffrement. Ce projet s'appelle DM-steg et la documentation est disponible. Les sources sont composées d'un patch noyau (pour le 3.2) et des outils.

1/ Quels sont les points positifs de DM-steg?
Tout d'abord, les performances de DM-steg ont été mesurées en regard d'un RAM disk, et elles sont honorables (partie 6 Benchmarks du .pdf de doc).
Je ne m'étendrai pas sur les différents modes de chiffrements. L'auteur s'est basé sur de l'existant (un openssl récent > 1.1 doit être utilisé pour pouvoir compiler le projet).

Le point clé du projet réside dans la mobilité des données sur le disque.
Le disque est tout d'abord découpé en parties équivalentes, les blocs. Deux blocs vont jouer un rôle particulier. La taille totale de l'espace est amputée de deux blocs: le premier sert d'en-tête, le second de zone temporaire.Au cours de l'emploi du disque, les données des blocs vont être déplacées sur l'ensemble de l'espace du disque de manière aléatoire. Le bloc temporaire sert à stocker les données pendant le déplacement. Ainsi, un attaquant qui n'aurait accès qu'a la version chiffrée du disque verrait des réécritures sur tout le disque, ne pouvant ainsi absolument rien déduire sur l'usage de ce disque.

Et puis l'auteur indique "no crash" ce qui est rassurant :-)

Et DM-steg est particulièrement intéressant car il propose par défaut de la plausible deniability.
J'ai déjà blogué sur la plausible deniability faite par truecrypt pour en conclure que la méthode n'est pas satisfaisante.
Petit résumé: Pour truecrypt le disque caché est situé vers la fin du disque. Un attaquant en possession de plusieurs versions du disque au cours du temps et qui verrait des données être modifiées à cet endroit alors qu'elles ne correspondent à aucun fichier sur le disque normal pourrait donc vraisemblablement intuiter qu'un disque caché est présent.

2/ La plausible deniability par DM-steg

Etudions la partie deniable plausability. Tout d'abord, sur la possession de ce programme, ensuite sur les containers imbriqués, et enfin sur les attaques réalisables par un attaquant.

La possession de ce programme est sans doute un piège en soi. Si je suis un attaquant et que je vois un utilisateur avec DM-steg, je vais immédiatement le soupçonner de cacher des données. On peut considérer cela comme un faux problème puisque le jour ou DM-steg sera inclus dans les sources officielles du noyau linux et dans les distributions linux sa possession ne sera plus compromettante.

DM-steg permet d'utiliser un disque avec plusieurs mots de passes. Chaque mot de passe donne accès à une vue différente du code déchiffré. Il est possible d'avoir donc un nombre illimité de conteneur cachés (si ce n'est la taille du disque), au contraire de Truecrypt qui ne propose qu'un disque normal contenant un disque caché.

Après discussion avec l'auteur par mail, il m'indique qu'il préfère la méthode de conteneur imbriqué sans limite. Les arguments sont inversibles avec ceux de Truecrypt. Truecrypt dit qu'en cas de gros problème, il est toujours possible de donner les deux mots de passe, prouvant donc que plus rien n'est caché (si on vous tape dessus pour obtenir les mots de passe, cela peut être la solution la moins pire), et DM-steg dit précisément l'inverse, que l'attaquant arrêtera forcément au 'n-ième' mot de passe, à vous de cacher la donnée dans un conteneur n+1. Je n'ai pas d'avis tranché à ce sujet.

Le mode de dispersion des données de DM-steg empêche un attaquant de différencier plusieurs versions du disque pour détecter quels sont les octets qui bougent, et si le cas échéant des octets vers la fin du disque bougent sans lien avec les données présentes. Il semble donc que c'est un excellent moyen pour faire de la plausible deniability. Mais il y a encore deux points qui ne sont pas réglés:
  • Les données sont éparpillées sur le disque (mettons /dev/sda1). Donc un attaquant avec plusieurs copies de /dev/sda1 n'a aucune information. Mais la plausible deniability dit que l'attaquant peut posséder le mot de passe du container principal. Et donc l'attaquant peut monter les disques avec DM-steg. Et il aura accès aux données sous /dev/mapper/steg1. Et là, les données deviennent "linéarisées" et non plus "éparpillées". L'attaquant peut donc étudier les modifications entre deux versions de /dev/mapper/steg1 et ainsi détecter des modifications illégitimes de manire analogue avec l'attaque sur truecrypt.
  • Aucune limitation sur le filesystem employé n'est faite. Ainsi, si un utilisateur crée un container principal formaté en ext3 et un container caché sur les 100 derniers Mo du disque, alors un attaquant à l'aide du mot de passe du premier container pourra consulter tous les superblocks d'ext3 sur le container principal. Les superblocks des 100 derniers Mo seront illisibles puisqu'écrasés par le container caché. Une fois de plus sa présence est révélée. On peut utiliser du FAT, mais l'emploi de FAT dans une distribution linux est suspicieux en soi.
  • Or donc la plausible deniability n'est pas garantie. 
3/ One more step to infinity
Le fait d'éparpiller les données chiffrées sur le disque est donc un premier pas très intéressant. Un attaquant a donc l'obligation impérative d'avoir le premier mot de passe pour attaquer la plausible deniability, ce qui n'était pas le cas auparavant.
Nous avons aujourd'hui de plus en plus de disques SSD ou la localisation des données n'a plus aucune importance en terme de performances. L'usage de DM-steg pourrait donc rivaliser avec dm-crypt. Néanmoins, on cherche encore une vraie méthode de plausible deniability pérenne et fiable dans le temps.