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