L'autre jour je lurkais sur 4chan lorsque j'ai pu assister, en l'espace de 5mn, à deux Epic Fail ayant la même cause : la méconnaissance complète de l'existence des métadonnées EXIF. Comme je ne suis plus tout à fait certain d'avoir déjà abordé ce sujet ici, je le fais maintenant :)

Qu'est ce que les données EXIF ?

Expliqué très brièvement les données EXIF sont des métadonnées ajoutées à des fichiers images afin de stocker tout un tas de trucs intéressant (date de la prise de la photo, modèle de l'appareil utilisé, taux de compression, résolution, etc.). De nos jours 99% des appareils photos rajoutent des données EXIF quand ils prennent une photo (la pseudo-norme EXIF reprenant intégralement la norme JPEG il y a une totale compatibilité et l'utilisateur lambda ne voit qu'une image JPEG alors qu'il s'agit d'une image JPEG agrémentée de méta-données EXIF). Bien que cette pseudo-norme soit donc très répandue de nos jours et que certains savent clairement en faire bon usage, on trouve encore des gens qui ne sont pas conscients de l'existence de ces méta-données, comme vont vous le prouver les deux petites histoires qui suivent.

Se cacher derrière son petit doigt

Premier ''Epic Fail'' : quelqu'un publie une photo de sa future femme, dans une tenue que nous qualifierons de "Olé Olé", en prenant bien soin de masquer son visage au préalable pour qu'on ne la reconnaisse pas. Afin de protéger l'anonymat de sa promise notre amusant Anon¹ avait en effet pris soin de lancer son logiciel de retouche photo préféré et de rajouter un gros carré noir au dessus du visage de sa chère et tendre avant de publier la photo. Pourtant, moins d'une minute après avoir publié la photo ainsi censurée, une version dé-censurée a ressurgie sur 4chan...Comment cela est-il possible ? Va-t-on nous ressortir le coup des carrés noirs pdf mais sur le format JPEG qui n'a pourtant rien d'un format objet ?

Non c'est bien plus simple : l'appareil photo utilisé devait être de bonne facture puisque la miniature embarquée en donnée EXIF dans l'image censurée était, de mémoire, d'une résolution proche de 640x480 et elle n'a pas été mise à jour lors de la censure grossière appliquée avec un logiciel de retouche un peu cheap...L'image censurée embarquait donc une version 640x480 non-censurée, et c'est largement assez pour reconnaitre un visage : FAIL.

Jouer à cache-cache avec une balise A.R.V.A. dans la poche

Deuxième Epic Fail : Un autre Anon a utilisé son super smartphone pour prendre une photo de lui dans un miroir en pleine activité que nous qualifieront de "compromettante". Bien entendu il avait pris soin de porter un masque sur la photo afin de protéger son anonymat (pas folle la guêpe). Encore une fois la sanction est pourtant tombée en moins d'une minute : son smartphone ayant enregistré sa position GPS dans les données EXIF, un plan google map et une photo google streetview correspondant à son domicile ont fait écho à la publication de sa première photo...FAIL.

Conclusion

Pour jouer avec les tags EXIF je vous conseille ce super outil online, ou ce super outil offline. En tout cas maintenant vous ne pourrez pas dire que vous n'êtes pas prévenus ;) !

1. http://encyclopediadramatica.com/Anonymous ↩

Billet en vrac sur pleins de petites choses qui m'ont interpellé récemment.

L'oeil de moscou

Depuis quelques temps je tombe sur de plus en plus de moteurs de recherches orienté sécurité, et vu que pas mal de monde autour de moi ne les connais pas je me dit que partager leurs adresses ici ne sera pas inutile. D'abord il y a sucuri qui part d'un enregistrement DNS et qui vous donne une page synthétique présentant pleins d'informations utiles prêtes à être copiées/collées dans votre rapport de test d'intrusion (whois, enregistrements DNS, headers http, ...).

Ensuite il y a shodan qui me laisse un peu plus circonspect...en effet il permet de trouver des IP sur lesquelles écoutent des logiciels serveur de votre choix. Typiquement vous tapez "Apache 2.0" et shodan vous retourne des IP où des Apaches 2.0 écoutent (il vous retourne les headers HTTP en même temps afin que vous puissiez vérifier sa déduction). Ca peut être utile pour faire des statistiques et des jolis graphiques en couleur, mais à part ça... Enfin il y a des google dorks basées sur sucuri qui font à peu près la même chose. Franchement si l'un d'entre vous à une idée de l'utilité de ces deux derniers services, à part "faire des stats (dont la représentativité n'est pas certaine)" et "Victim as a service", je suis intéressé !

Pourquoi autant de café dans l'informatique ?

Du café, encore du café, toujours du café... Il y a quelques mois (vers Mai 2009 si ma mémoire est bonne) Microsoft a offert aux autorités américaines des clés USB baptisées COFEE et qui permettent, en gros, de lancer pleins d'outils de forensics lorsqu'elle sont branchées à un PC windows. Premier rebondissement de l'histoire : le contenu de ces clés USB a leaké à plusieurs endroits début Novembre (le plus sûr d'entre eux étant wikileaks). Second rebondissement (datant d'il y a à peine quelques jours) : Un outil "anti-COFEE" (baptisé, non sans humour, "Decaf") se promènerait sur la toile. L'outil est censé effacer des logs (windows et COFEE), en pourrir d'autres (rajoutant des infos aléatoires), désactiver le support de l'USB, ... bref Decaf est censé empêcher COFEE de fonctionner proprement. Pour la petite histoire Decaf n'est fournit que sous forme exécutable (donc pas de code source) et la licence en interdit la décompilation... j'attend impatiemment le troisième rebondissement de l'histoire où on apprendra que Decaf embarque une backdoor (que ça soit de l'info ou de l'intox).

La réalité rattrape la fiction

L'une des planches de xkcd qui m'avait le plus amusé est presque devenue réalité :) J'avais moi même faillit bricoler un système analogue à la lecture de ces vignettes, puis j'avais abandonné le projet faute de temps (et de réelle utilité...) mais visiblement quelqu'un d'autre est allé au bout d'une idée similaire (à priori sans avoir eu auparavant connaissance de la planche d'xkcd). Le projet s'appelle "VirusZoo" et est accessible via internet. Le concept est simple (et plus épuré que celui d'xkcd) : on choisi un virus depuis une collection de virus¹, ce virus infecte alors une machine virtuelle sous windows, et il ne nous reste plus qu'à observer la machine virtuelle grâce à des screenshot pris automatiquement et accessible depuis le site web de viruszoo :) Simple, efficace, et presque totalement dénué d'intérêt autre que le coté "fun" de voir vivre des virus informatique dans leur milieu naturel² :)

1. Pour autant que je sache il n'est hélas pas possible de proposer des nouveaux échantillons à rajouter à la collection ↩
2. Certains y voient comme intérêt la possibilité de mener des actions de sensibilisation en se servant des screenshots comme support visuels...pourquoi pas après tout. ↩

Le mois dernier a débarqué un thread sur bugtraq que j'ai trouvé assez intéressant et qui, chose rare pour cette ML, s'est étalé sur plus d'une semaine sans perdre en qualité dans les interventions. Je vous propose donc de résumer ici ce qui s'y est dit, vous allez voir c'est astucieux :)

Généralement sur un unixoïde, si vous avez des fichiers confidentiels à stocker, vous allez créer un répertoire, vous donner des droits dessus, retirer tous les droits pour le reste du monde, et enfin copier vos fichiers confidentiels dans ce répertoire. Les droits de votre dossier "secret" ressemblent donc à ça :

rwx------  2 toto toto 4.0K Nov  8 18:30 secret

Une fois le dossier "secret" sécurisé de la sorte les fichiers confidentiels créés dedans le sont généralement sans prendre garde aux droits qu'on leur attribue parce que, de toute façon, personne d'autre que vous ne peut lire le contenu du dossier "secret", et ne peut donc avoir accès à vos fichiers (car personne n'a pu avoir connaissance des inodes de vos fichiers). En effet quand bien même quelqu'un d'autre que vous connaitrai le chemin complet vers l'un de vos fichiers confidentiel toute tentative d'accès à ce fichier (et donc à l'inode correspondant) échouera lamentablement car la chaine de références à suivre pour obtenir le numéro de l'inode de votre fichier s'arrêtera, pour lui, au niveau du répertoire secret :)

C'est une méthode de contournement de ce type de cloisonnement qui a été abordé dans le thread de bugtraq dont je parlais en introduction et que nous allons voir ici. En effet dans certaines circonstances (assez particulières il faut bien l'avouer) Pavel Machek a trouvé une astuce permettant d'accéder à des fichiers sur lesquels on possède des droits, bien que l'on ne possède plus aucun droit sur une partie de l'arborescence menant à ce fichier. Alléchant non ?

D'abord voyons une méthode simple et connue comme le loup blanc pour parvenir à ce résultat : le hard link. Si jamais un hardlink existe entre /secret/himitsu.txt et /tmp/foo.txt n'importe qui avec les droits d'accès sur /tmp et sur /tmp/foo.txt aura accès à /secret/himitsu.txt. En effet un hardlink référence directement l'inode du fichier. En passant par le chemin /tmp/foo.txt vous avez donc directement accès au fichier sans aucun problème :) Par contre ça ne marche pas avec le symlink ! Les liens symboliques (ln -s) fonctionnent plutôt comme des raccourcis dans le monde de windows, c'est à dire que si /tmp/foo.txt est cette fois un lien symbolique vers /secret/himitsu.txt ce qui sera pointé par /tmp/foo.txt sera le chemin /secret/himitsu.txt et non pas le fichier en lui même, il faudra donc de toute façon résoudre le chemin /secret/himitsu.txt pour obtenir accès à l'inode du fichier, ce qui n'est pas possible si vous êtes bloqué au niveau du répertoire /secret

Si vous créez vos fichiers après avoir sécurisé le dossier /secret/ vous n'avez aucun souci à vous faire : personne n'a pu accéder un jour aux fichiers contenus dans le répertoire, et donc personne n'a pu créer de hard link vers ces fichiers (car personne n'a pu avoir connaissance de leur numéro d'inodes). En revanche le problème se pose si vous sécurisez l'accès au répertoire /secret/ après avoir créé les fichiers ! Par exemple si vous créez un répertoire /journal_intime et un fichier novembre2010 dedans, que vous fixez les permissions sur /journal_intime afin que personne d'autre que vous ne puisse accéder à ce répertoire, puis que vous vous mettez enfin à rédiger votre novembre2010 en toute quiétude=. Qu'est ce qui vous dit que quelqu'un n'a pas créé un hardlink vers /journal_intime/novembre2010 avant que vous ne coupiez les droits sur /journal_intime ? Et bien à priori rien ne vous le garantie et donc il est possible que vous rédigiez tranquillement novembre2010 alors que quelqu'un d'autre que vous y accède via un hardlink qu'il aura créé rapidement ! Pour parer ce cas de figure il y a une méthode simple : ls -l, le premier chiffre apparaissant après les permission représente le nombre de hardlink existant pour chaque fichier (attention : il est impossible de créer des hardlink sur des répertoires¹, ne tenez donc pas compte de ce chiffre sur les lignes correspondant à des répertoires). Par exemple ci-dessous on voit que novembre2010 a été compromis car quelqu'un a eu le temps de créer un hardlink vers lui, et que decembre2010 n'est, lui, bien référencé que par un hardlink (certainement parce qu'il a été créé en decembre, et que l'on a sécurisé le répertoire en novembre, donc avant sa création :) )

-rw-r--r--  2 toto toto 40.0K Nov  8 18:30 novembre2010
-rw-r--r--  1 toto toto 40.0K Nov  8 18:30 decembre2010

Grace à cette méthode toute simple de vérification du nombre de hardlink on aurait donc pu se croire à l'abri, mais ça aurait été sans compter sur le thread de bugtraq dont je parlais en introduction et qui apporte un raffinement amusant à la méthode de contournement de la protection par répertoire via hardlink.

Toute la méthode de Pavel se base en fait sur la présence du pseudo filesystem /proc (et ne fonctionne donc que sous linux). Quand Pavel a décrit son astuce sur Bugtraq il l'a présenté comme une faille de sécurité causée par /proc lui même sans beaucoup plus d'explication, et de là le débat est parti pour tenter d'expliquer plus précisément le phénomène observé. Je vais donc vous présenter directement les conclusions plutôt que tout le débat².

Quand /proc est monté et qu'un process ouvre un fichier une entrée est automatiquement créée dans /proc/PID/fd/ et c'est là qu'un comportement contre-intuitif a lieu : bien que le répertoire se nomme "filedescriptor" l'entrée stockée n'est pas un filedescriptor mais un objet particulier au pseudofilesystem /proc. Là où ça devient amusant c'est que cet objet particulier se comporte comme un hardlink mais n'en est pas un ! Vous pouvez donc exploiter cette "astuce" dans un scénario complexe du type suivant :

• Alice crée un répertoire /secret avec des permissions qui autorisent Eve à y accéder
• Alice crée un fichier supersecret.txt dans le répertoire /secret avec des permissions quelconque qui autorisent Eve à y accéder en lecture seule
• Alice change les permissions de /secret pour que personne ne puisse y accéder à par elle
• Alice vérifie le nombre de Hardlink pointant sur le fichier supersecret.txt et constate qu'il n'y en a qu'un et que personne ne peux donc plus contourner la protection apportée par /secret.
• Alice change, pour d'obscure raisons, les permissions de supersecret.txt pour que tout le monde puisse y accéder en lecture/écriture

Normalement Alice est tranquille : son fichier est innaccessible, et en tout cas impossible à modifier. Mais voilà : si Eve a ouvert le fichier avant qu'Alice coupe les permissions sur /secret Eve peut toujours lire le contenu de supersecret.txt mais il y a pire encore (c'est le comportement qui avait fait tiquer Pavel) : Eve peut modifier le contenu du fichier en ouvrant simplement l'entrée stockée sous /proc/PID/fd/³ puisque cette entrée se comporte en fait exactement comme un hard link !

Amusant n'est-ce-pas ? Bon comme je vous avais prévenu c'est "exploitable" uniquement dans des contextes très très très particuliers, mais moi j'ai trouvé ça distrayant :-)

1. Sauf sour MacOS10.5 me souffle-t-on à l'oreille... ↩
2. pour les détails menant à cette conclusion référez vous au thread original (vous trouverez un lien en début d'article) ↩
3. Pavel pensait qu'il s'agissait en fait d'un vrai "filedescriptor" et que /proc permettait de le ré-ouvrir, ce qui n'est en fait pas le cas ↩

Ca va bientôt faire deux mois que la BH 2009 est fini, mais ça n'est que maintenant que j'arrive à pondre un petit billet qui lui est vaguement relié...décidément j'ai encore du chemin à parcourir pour atteindre la réactivité de certains !

En survolant les présentations faites à la dernière black hat il y en a une qui m'a tout particulièrment interpellée, c'est la présentation faite par Egypt (projet metasploit) sur le tout nouveau module browser_autopwn. En résumé ce module ouvre un serveur HTTP en écoute, quand un navigateur s'y connecte il note tout un tas d'informations pour essayer de l'identifier (principalement le user-agent en fait), puis il répond avec un javascript obfusqué dont le seul but et d'aider à l'identification précise du navigateur et de l'OS qui le fait tourner. Les informations receuillies par le javascript sont retournées au module qui lance alors tous les exploits dont il dispose et qui correspondent au navigateur et à l'OS identifié :) Bref c'est le même état d'esprit que l'excellent db_autopwn, mais coté exploitation client plutôt qu'exploitation serveur.

Quand j'ai lu cette présentation je me suis dit qu'il fallait absolument que j'essaie ça, mais je n'ai finalement eu le temps que très récemment et comme j'aime bien partager (et que j'ai monté mon blog pour ça lol) je vais vous relater les tests que j'ai fait :

D'abord j'ai re-téléchargé metasploit puisque ça faisait plusieurs mois que je n'y avais pas touché puis je me suis rendu compte que j'avais oublié comment on faisait pour faire une mise à jour (histoire d'être certains d'avoir tous les derniers exploits)...Ca m'a bien pris une heure avant de me le rappeller et même si ça me fait passer pour un con (parce que, franchement, faut être con pour avoir mis 1h à se souvenir de ça lol) je vous donne la méthode ici, ça vous évitera de longues minutes de googlages inutiles : svn update¹ ...Ah bah ouais, j'vous avais prévenu que c'était con ;)

Une fois dans metasploit je recherche le petit nom exact du module > search browser_autopwn et le framework me répond gentiment server/browser_autopwn Je charge donc le module > use server/browser_autopwn , je regarde les options > show options et je renseigne les essentielles, en particulier l'adresse sur laquelle mettre le serveur http en écoute > set SRVHOST 192.168.69.1 et l'URI que le navigateur devra demander pour tomber sur le piège automatique >set URIPATH boum. Je suis donc fin prêt, il n'y a plus qu'à lancer le jouet > exploit. Tout impatient j'attend que metasploit ai fini de charger tous ses exploits puis je lance ensuite mon navigateur préféré sur le même pc que tourne metasploit et j'accède à l'URL http://localhost:8080/boum et là : rien. Mon firefox 3.5.2 tournant sous linux est certainement trop solide parce que metasploit a beau avoir tenté un ou deux exploits je ne retrouve aucun reverse shell établi avec succès ( > sessions -l ).

Qu'à celà ne tienne, j'ai plus d'un tour dans mon sac :) ! Il y a quelques années quand j'avais acheté mon ordi portable j'avais du m'acquiter de la taxe microsoft, mais comme j'utilise très très très peu cet OS il y avait de vives chances que je ne sois pas à jour en termes de patchs de sécurité. Je boot donc mon pc portable sous windows, et c'est avec délectation que je lance un gentil Firefox 2.0 depuis mon brave XP SP2....résultat : néant :( Firefox rame un peu, mais toujours aucun reverse shell n'apparait dans metasploit en réponse à mes > sessions -l. Petite déception, mais je ne me laisse pas démonter et je lance mon arme ultime : le vieil IE6.0 qui traine. Hop je le lance et j'accède à http://192.168.69.1:8080/boum. Metasploit envoie son armée d'exploits et là....rien :( Toujours aucunes sessions ouvertes.

J'ai ensuite lu un petit peu les paramètres des exploits que browser_autopwn automatise et il me semble que le IE6.0 aurait du tomber (pas les autres, faute d'exploits adéquats)...N'ayant pas assez de temps pour regarder plus en détails je vais donc pour l'instant conclure de ces petits tests que browser_autopwn est certes redoutable mais qu'il ne remplace pas encore un peu d'huile de coude, de milw0rm, et de social engineering :)

1. à lancer dans le répertoire de metasploit bien entendu... ↩

J'avais initié il y a un moment une série de billets sur les outils que j'aime bien et que j'utilise en sécurité et/ou bidouillages puis j'y ai repensé cet après midi en me disant que, depuis cet éclaireur, je n'avais pas donné suite...Le temps est donc venu de parler de deux ou trois autres outils bien pratiques !

L'outil central de ce post sera tcpflow :) ! Cette superbe commande sert à reconstituer le contenu brut des sessions TCP capturées (en live ou dans un fichier pcap). Il prend donc en argument une interface réseau (ou un fichier pcap) puis il génère, pour chaque session TCP, un fichier qui contient les données brutes qui ont transitées dans le flux TCP en question (en bref il supprime les en-têtes IP, il ordonne les paquets TCP, supprime les en-têtes TCP, et sauvegarde bout à bout le contenu complet de la session ainsi allégé). Les fichiers générés suivent une convention de nommage intuitive de type "IP1 PORT1 IP2 PORT 2" et vous pouvez donc assez facilement retrouver celui que vous voulez. A quoi ça sert me direz vous ? A tout ce que vous pouvez imaginer, mais comme je suis beau joueur (et bavard) je vous donne quelques exemples :

Un scénario d'utilisation simple consisterai à sniffer une session FTP et à vouloir récupérer les fichiers qui ont été téléchargées. Grâce à tcpflow c'est simple comme "bonjour" ! Vous lancez tcpflow et il va vous créer un fichier par session TCP sniffée. Vous allez donc avoir un fichier qui contient les commandes et réponses qui ont transitées par la session TCP de controle FTP (à destination du port 21 du serveur), et un fichier pour chaque autre session TCP. Si vous connaissez un peu le protocole ftp vous savez que les autres sessions TCP contiennent précisément chacune le contenu d'un fichier téléchargé, et que donc le fichier généré par tcpflow est l'image exacte du fichier qui a été téléchargé :) ! Job's done.

Second scénario d'utilisation simple : vous sniffez du traffic HTTP. Premier réflexe pour "gratter" des trucs intéressants : urlsnarf, voir carrément dsniff. C'est pas mal, mais si j'ai envie de récupérer les images, voir les animations flash¹ comment pourrais-je faire pour extraire simplement ces fichiers de la bouillie informe d'un pcap qui contient pèle mèle les en-têtes IP et TCP et ne garantie en rien l'ordre de lecture des paquets ? Aussi compliqué que ça puisse paraitre c'est en fait presque immédiat avec tcpflow :) ! En lançant tcpflow vous obtiendrez un fichier par session TCP, si vous êtes en HTTP/1.0 vous obtenez donc un fichier dump par fichier ayant réellement transité en HTTP. Seul problème : ces fichiers contiennent les en-têtes HTTP...et si par malheurs vous êtes en HTTP/1.1 c'est encore pire : un seul fichier de session généré par tcpflow peut contenir plusieurs fichiers téléchargés en HTTP les uns à la suite des autres, avec des en-têtes HTTP intercalés dans tout ça...Donc on s'est bien débarassé des en-têtes IP, on s'est bien débarassé des en-têtes TCP, on a bien réordonné les paquets avant d'en coller le contenu bout à bout, mais il nous reste les en-têtes HTTP. C'est là qu'un petit effort de mémoire devient utile pour trouver une bidouille sale mais qui marche : foremost :) ! Pour rappel foremost extrait des fichiers à partir de suite d'octets bruts en se basant sur du pattern matching de header et de footer, foremost permet donc bien d'extraire les fichiers à partir des dump générés par tcpflow en ne faisant pas attention aux headers HTTP (testé et approuvé) ! Alors, bien sur, c'est un petit peu "sale" comme méthode, et vous raterez pas mal de fichiers (typiquement ceux qui transitent compressé puisque foremost ne sait pas les reconnaitre), mais ça a au moins l'avantage de marcher super vite pour récupérer la majeure partie de ce qui a transité :) ! De plus cette méthode est adaptable, en remplaçant foremost par un gentil petit photorec par exemple, qui a le bon gout de récupérer plus de type de fichiers que foremost (un jour il faudra vraiment que je le teste quand même...).

Dernier scénario où tcpflow peut s'avérer salutaire : si vous avez un pentest à faire sur une application client-serveur et que vous réussissez à récupérer une trace réseau. Dans ce cas là pensez à faire un petit tcpflow, ça vous permettra d'analyser tranquillement les informations qui transitent entre le client et le serveur sans avoir à vous encombrer des couches réseau basses. A la base c'est même pour ça que tcpflow a été écrit il me semble : pour faciliter la rétro-ingénierie des protocoles obscurs.

Bref vous l'aurez compris : tcpflow est un outil très pratique, et vu qu'en plus il est très léger et rapide ça serait vraiment dommage de s'en priver.

1. pour éventuellement en extraire la bande son, la convertir en mp3, et la sauvegarder conformément à l'exception aux droits d'auteurs et droits voisins au nom de la copie privé ↩