Parmi les jeunes langages de scripts à la mode de nos jours on distingue assez clairement deux leaders : le python et le ruby. Le nombre de trolls velus entre ces deux langages est d'ailleurs assez impressionnant ! Personnellement j'utilise le python puisqu'il répond à tout ce que j'attend de la part d'un langage de script (je ne prétend donc pas qu'il soit mieux ou moins bien que le ruby que je n'ai juste pas testé), et quand par hasard une fonctions que j'aurai aimée n'est pas présente de base il est souvent enfantin de la rajouter comme je me propose de vous en donner un exemple dans ce billet !

L'une des bibliothèques standards du python que j'ai apprécié le plus vite c'est la bibliothèque "urllib"¹ qui permet, entre autres choses, de récupérer une page web en une toute petite ligne de code :

urllib.urlopen("http://www.ozwald.fr").read()

Quand on compare aux dizaines de lignes nécessaires en C pour obtenir la même chose, ça donne des frissons de bonheur ! Avec cette librairie tout ce que l'on peut vouloir faire se fait très simplement : ajout de headers HTTP, lecture des headers HTTP de la réponse, passage par un proxy HTTP, etc. Seulement voilà : une fonction manque à l'appel (à mon gout), c'est la possibilité d'utiliser un proxy SOCKS :( !

Pourquoi vouloir utiliser un proxy SOCKS me direz vous ? Après tout "C'est relativement rare comme besoin et donc certainement contournable". Et bien non, là ça n'est pas contournable puisque le but du jeu c'est de faire passer notre script python par TOR, or TOR vient par défaut en tant que proxy SOCKS :)

Comment faire pour que notre script python passe par TOR du coup ? C'est enfantin : Vous télécharger socksipy, vous enregistrez le fichier que vous venez de télécharger dans le même répertoire que le script que vous voulez TORifier, et dans ce script que vous voulez TORifier vous ajoutez les 4 lignes suivantes :

import socks
import socket
socks.setdefaultproxy(socks.PROXY_TYPE_SOCKS4,"127.0.0.1",9050,True)
socket.socket = socks.socksocket

Voilà c'est fait :) Vous avez remplacé l'ouverture de socket standard de python par celle de socksipy (qui utilise le proxy TOR que vous avez configuré), donc suite à ces 4 lignes toutes les fonctions de python qui reposent sur des socket sont TORifiées, en particulier les fonctions d'urllib qui vont lire des pages web. Alors, c'était enfantin ou pas ?

1. Et son évolution : urllib2 ↩

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 ↩

Hop étant très occupé ces temps-ci je vais me contenter de billets nettement plus court qu'à l'accoutumée, mais au moins ça vous laisse tout le loisir de creuser par vous même si le sujet abordé par l'un d'eux vous interpelle.

Pour ce premier "mini-billet-parce-que-je-suis-occupé" je vais simplement parler un petit peu d’un site web que j’ai découvert récemment (je ne sais même plus où) et qui porte l’alléchant nom de "La grotte du barbu". Pour résumer c’est un geek (barbu) qui fait des vidéos sur ses bricolages et je trouve que ses vidéos font merveilleusement écho à la définition du hack que je donnais il y a quelques semaines ! Typiquement regardez la vidéo "hacker sa cuisine", c’est dans la pure lignée de l’état d’esprit de mon billet précédant.

Le site souffre néanmoins de quelques travers comme typiquement le ratio "technicité sur durée de la vidéo" que je trouve bien trop faible. Par exemple la vidéo expliquant comment monter un mini robot dure presque 25mn alors qu’il s’agit juste de coller deux piles à deux moteurs via deux boutons inverseurs…

Bref c’est un site distrayant avec un état d’esprit que j’aime bien mais qui requiert hélas beaucoup de temps pour être apprécié et dont le niveau de technicité est très faible. C’est donc plus à voir comme une petite série donnant des idées de bricolage que comme de véritables tutoriels vidéo mais moi j'aime bien. Maintenant que vous êtes prévenus entrez donc à vos risques et périls dans la grotte du barbu !

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é ↩