mardi, août 30 2011

metasm, en mieux (ou pas)

Il n'y a que deux choses qui manquent à Python, à mon humble avis : metasploit, et metasm. Or il semblerait qu'il y a quelques jours/semaines, l'un de ces deux manques ait été comblé par miasm, l'équivalent de metasm en python ! J'étais donc obligé de faire au moins un petit billet là dessus :)

Engine - Creative Common by "cbowns" on Flickr
Comment installer miasm ? La page officielle du projet est relativement claire, mais ne s'applique pas immédiatement (en particulier quand on est sous gentoo). Voilà donc la démarche que j'ai suivi, ce n'est peut être pas la meilleure mais "chez moi ça marche"(c). D'abord voyons les dépendances :

  • Grandalf (https://github.com/bdcht/grandalf) in order to render graphical disassembler.
  • Modified libtcc (http://bellard.org/tcc/) to Jit code for emulation mode. see below
  • python-ply for parsing
  • numpy
  • python-virtualenv
  • python-dev
  • python-qt4

Allons y par étape en adaptant pour gentoo :

Grandalf viendra tout seul quand on clonera le méta-répertoire, on ne s'en occupe donc pas.

Concernant la libtcc on va suivre les instructions tout simplement : git clone git://repo.or.cz/tinycc.git puis on édite le Makefile conformément à ce qu'indique le site de miasm, puis make...échec texi2html: Command not found...Pas de problème emerge -v texi2html puis on re-tente le make : victoire ! Il ne reste plus qu'à make install.

Pour "python-ply" il faut en fait installer "dev-python/ply", sauf qu'il est masqué par le keyword x86. On démasque donc et on installe joyeusement : echo "dev-python/ply ~x86" >> /etc/portage/package.keywords && emerge -v ply

Pour "numpy" rien de plus simple emerge -v numpy.

Idem pour "python-virtualenv" qui s'installe sans poser de problème avec un simple emerge -v virtualenv

Pour "python-dev" c'est encore plus simple : rien à installer puisque nous sommes sous Gentoo :)

Enfin "python-qt4" est lui aussi assez simple à obtenir puisqu'il suffit d'un emerge PyQt4[1]

Maintenant on clone le répertoire hg clone https://code.google.com/p/smiasm/ smiasm...fail. Après un emerge -v hg-git ça ne se passe pas mieux...Après quelques recherches la version de mercurial stable sous gentoo est la 1.7, or le support des subrepository GIT n'apparait dans mercurial qu'à partir de 1.8 -_- ....bon...echo "=dev-vcs/mercurial-1.8.2 ~x86" >> /etc/portage/package.keywords && emerge -v =dev-vcs/mercurial-1.8.2...damned ça foire encore. Après un poil de trifouillage il semblerait que ça soit le clonage de grandalf qui foire...probablement à cause du .hgsub du répertoire smiasm qui pointe (à tort?) vers [git]https://github.com/bdcht/grandalf ...Bon on clone grandalf à la main git clone git://github.com/bdcht/grandalf.git, et également miasm parceque "chezmoiçaapasmarché"(c) hg clone https://code.google.com/p/miasm/ miasm -v --traceback ainsi que le README.txt qui est à la racine du repository smiasm et, plus important : pyMakefile et Makefile. Pfiou, tout ça ! Maintenant on revient sur le chemin tracé par le site officiel : on tape donc make && make install dans le répertoire de smiasm..victoire :) !!!

On teste si tout marche bien cd miasm/example/ && python disas_and_graph.py /bin/ls ...FAIL NameError: global name 'route_with_nurbs' is not defined

Bon, on re-trifouille et je vous fait grace des détails. Au final la méthode que j'ai employé (et qui marche sur gentoo et ubuntu 10.4 une fois les dépendances de chaque distro réglées) c'est :

  1. D'abord on se débarasse du problème de TCC en suivant à la lettre les instruction du site officiel smiasm : clone git://repo.or.cz/tinycc.git, ensuite on rajoute "-fPIC" dans les CFLAGS du fichier Makefile (CFLAGS+=-g -Wall -fPIC) puis on compile/installe : ./configure && make && make install
  2. Maintenant on attaque smiasm à proprement parler : On clone une première fois smiams : hg clone http://code.google.com/p/smiasm/, ça se termine avec un message d'erreur mais "pas grave". On télécharge ensuite à la main les fichiers "Makefile" et "pyMakefile" depuis l'accès HTTP au repository (http://code.google.com/p/smiasm/source/browse/)
  3. On clone à la main grandalf parce que le .hgsub de smiasm utilise une notation exotique qui n'est comprise ni par le mercurial gentoo par défaut ni par le mercurial ubuntu 10.4 par défaut : cd smiasm && rm -Rf grandalf && git clone git://github.com/bdcht/grandalf.git grandalf
  4. On fait un rollback de version de grandalf puisque les versions commitées depuis juillet dernier ne semblent plus compatibles avec miasm (disparition de la fonction route_with_nurbs) : git checkout a851b359185132645d9dce3d11037f3263604358
  5. Il ne reste plus qu'à compiler et installer smiasm :) ! cd .. && make && make install

A présent on peut tester le tout cd miasm/example/ && python disas_and_graph.py /bin/ls. Victoire :

miasm - test script

Il ne nous reste plus qu'à dévorer la documentation pointée par Sid[2] et à nous les joies du bas niveau avec encore plus de facilité ! A bientôt donc pour de nouveaux billets passionants (en tout cas j'espère qu'ils réussiront au moins à me passioner lors de leur rédaction lol) !

Notes

[1] Ce qui peut prendre pas mal de temps si jamais vous devez recompiler qt-core :( ...

[2] Merci d'ailleurs, sans ce blog post je ne l'aurai jamais trouvé lol

jeudi, juin 16 2011

Un geek ne vieillit pas, il level up.

Dans mon système de notation personnel j'ai obtenu un level up la semaine dernière (voire même plusieurs) ! Tout ces "level up" se sont concentrés en 3 jours, à savoir les 8, 9, et 10 juin 2011 et ça mérite bien un article "pot pourri" avec pleins de remerciement dedans (mais pas de technique, donc si c'est ça que vous aimez : passez tout de suite votre chemin et revenez pour le prochain billet :) )

SSTIC 2010 - Creative Common based on pictures from sstic.org published under Creative Common BY-NC-SA
Premier level-up : J'ai présenté, au SSTIC, un outils de cassage de mot de passe qui, en toute modestie[1], mérite qu'on y jette un oeil si jamais on est amené à casser fréquemment du mot de passe. C'est un outil que j'ai développé pour l'entreprise qui m'emploie actuellement en tant que pentesteur et que nous utilisons déjà allègrement donc vous pouvez vérifier que "je ne vous crapule pas"[2] : ça fonctionne. Pour les curieux les détails sont ici, , et probablement bientôt sur le site du SSTIC dans la section Actes.

Second level-up : J'ai rencontré des gens dont j'admire des travaux/réalisations/écrits et qui se sont avérés super sympa. Pour être certain d'en oublier je n'en citerai que deux[3] : Sid et Simon Marechal,

Troisième level-up : J'ai rencontré d'autres auteurs de travaux/réalisations/écrits admirables mais que je ne connaissais pas avant le SSTIC[4] et qui se sont avérés être des personnes très intéressantes et que j'espère revoir l'an prochain (au plus tard :)). Encore une fois pour être certain d'en oublier je n'en cite que deux : Serianox et Nicolas Prigent.

Bref le SSTIC c'était vraiment excellent, mais il faut être rudement rapide pour obtenir des places (tout part en quelques heures) et l'an prochain je n'aurai certainement pas ma place réservée bien au chaud :-/ ... Je comptais conclure ce billet en vous résumant les conférences que j'ai le plus apprécié mais finalement c'est trop difficile tant j'ai aimé de conférences...Allez donc plutôt jeter un oeil chez les gens qui écrivent bien mieux que moi.

Me reste donc à remercier :

  • tout ceux qui m'ont permis de travailler sur les Rainbow Tables probabiliste et d'arriver à ces résultats
  • tout ceux qui m'ont permis de présenter ça au SSTIC[5]
  • tout ceux qui m'ont écouté
  • tout ceux qui sont venu me poser des questions après la conf ou juste me dire que c'était bien
  • Milin et tout les autres[6]
  • Ceux que j'oublie.

Notes

[1] ou pas

[2] Pour citer Stéphane DUVERGER lors de son excellente conférence présentant ramooflax

[3] à noter qu'une rumeur voulait que Zythom soit au SSTIC cette année mais après moult débats sur la façon de prononcer "Zythom" et surtout après une enquête discrète lors du social event il m'a été impossible de confirmer/infirmer la rumeur :(

[4] on ne saurait tout connaitre

[5] ce qui inclus tout ceux qui travaillent pour que le SSTIC ait lieu

[6] remerciement privé, ouais je sais c'est mal

dimanche, octobre 24 2010

Dans l'estomac du python

Après un long silence sur ce blog (mais une longue période d'intense activité IRL) il est temps de résumer certains trucs qui m'ont occupé niveau informatique ces derniers temps :) ! Comme le titre le laisse présumer ça parle pas mal de python mais ne vous enfuyez pas pour autant si vous ne maitrisez pas ce langage de script sur le bout des doigts : je vais esquiver les détails gorets du code cette fois et me contenter de donner un aperçu high-level des possibilités qui sont offertes.

Cave - Based on a work published under Creative Common by "Kevin Lawver" on Flickr
J'en avais déjà parlé dans mon précédent billet mais j'insiste lourdement : pefile est une excellente extension python. Pour vous résumer certaines des fonctions qui me plaisent le plus :

  • ouverture, modification, puis sauvegarde du fichier PE modifié (il parait qu'il ne faut pas trop modifier la structure PE pour que ça marche, qu'à celà ne tienne il suffit de modifier "sur place" !)
  • accès ultra simple à toute la table d'importation du fichier PE (et donc éventuellement modification de cette dernière si on en a envie ;-))
  • accès ultra simple au contenu des diverses sections du PE et à leurs propriétés (donc éventuellement modification du contenu ou des propriétés...par exemple on peut rendre des sections "exécutable" ou "writable", je dis ça totalement au hasard... )
  • accès ultra simple à l'arbre des ressources du fichier PE (et donc éventuellement modification de ces ressources si le coeur vous en dit...)
  • cross platform !!! Ca c'est un vrai bonheur, les scripts qui utilisent pefile tournent sans modification sur linux ou windows.

Une autre extension super cool que j'ai découvert en jouant avec pefile : pydasm. C'est un binding python vers la librairie libdasm qui, comme son nom l'indique, permet de faire du désassemblage. Pour la petite histoire pydasm est livré avec pydbg dont je ne parlerai pas dans ce billet-ci mais que je vous conseille vivement de regarder si vous avez envie de jouer sous windows. Si on combine donc pefile avec libdasm on est en possession d'un vrai couteau suisse pour désosser et comprendre comment tourne un fichier PE donné.

Si vous avez tout suivi vous devez vous douter de ce que fait la prochaine extension dont je vais parler...On a du désossage et modification de fichier PE, on a du désassemblage de langage machine, il ne manque donc plus que....de l'assemblage :-D ! Et c'est là que vous allez (peut-être) être surpris : je ne vais pas parler de python dans ce paragraphe. Il y a bien des librairies d'assemblages pour python mais je n'ai, pour l'instant, été convaincu par aucune d'entre elles. En revanche j'ai été tout à fait convaincu par fasm qui cumule deux avantages non négligeables :

  • Il est open source
  • Il tourne aussi bien sous linux que windows

Donc tant pis pour le 100% python, je me suis laissé tenté par la simplicité absolue d'écrire un fichier temporaire[1] à partir de mon code python puis d'enchainer avec un petit

if re.match('win.*',sys.platform):
        system('FASM.EXE tmp.asm tmp.bin')
else:
        system('./fasm tmp.asm tmp.bin >> /dev/null')
assembly=open('tmp.bin','rb').read()

Bref, on a du désassemblage, on a de l'assemblage, on a de la manipulation de fichiers PE...je vous laisse imaginer tout seul ce qu'on peut faire avec ça parce que de mon coté je manque de "motif légitime" pour publier sur ce blog ce que j'en ai fait jusqu'à présent[2]

Enfin, le dernier bout de code python qui m'a occupé ces derniers temps c'est sulley. Pour ceux qui ne connaissent pas c'est un framework de fuzzing[3] qui permet de fuzzer des services accessibles par TCP ou UDP[4]. J'ai un petit peu joué avec et ça tourne pas mal; on peut très facilement avoir un script sulley qui tourne sur une VM windows afin de monitorer le processus cible alors que les autres processus sulley tournent sur une autre machine (au hasard une linux) et se chargent d'offrir une belle interface web de suivi de la campagne de fuzzing, de générer les requêtes réseau à destination du process à fuzzer, etc. Seule petite astuce à vous communiquer si vous voulez y jeter un oeil : si jamais vous galérez à installer pcapy ne vous prenez pas la tête plus de 2mn et allez plutôt directement faire de la boucherie dans network_monitor.py pour vous débarasser des appels à pcapy; en 10mn vous les aurez tous remplacés par l'équivalent en scapy ou carrément par des os.system("tcpdump blabla")[5].

Voilà, la prochaine étape sera peut-être de faire un binding amusant entre sulley et d'autres scripts python qui trainent dans mes cartons en les adaptants en pydbg...ou bien ça sera tout autre chose, allez savoir :) ! D'ici là : geekez bien ;)

Notes

[1] Pour info, si vous voulez faire propre, vous pouvez utiliser os.tempnam ou os.tmpfile à la place de toujours réutiliser 'tmp.bin'.

[2] En revanche je ne manquais pas de motif légitime pour en faire profiter mes collègues pentesteurs, c'est déjà ça. D'ailleurs l'un d'entre eux m'a fait remarquer qu'un certain "Nick Harbour" avait fait des choses similaires en 2008, si ça vous intéresse d'aller jeter un oeil ... ;-)

[3] Moins complet que Peach mais infiniment plus simple à prendre en main, ce qui explique à 100% pourquoi je l'ai préféré à Peach :)

[4] Pas de fuzzing de fichier donc, ni de ligne de commande, ou autre.

[5] c'est quand même très moche de faire ça à coup de os.system('tcpdump blabla') puis os.system("killall tcpdump"), préférez scappy qui sera bien plus précis et moins lourd (faites ce que je dis, ne faites pas ce que je fais ^^)

lundi, octobre 5 2009

Encore de beaux jours pour l'huile de coude

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 !

Black Hats - Photo under CreativeCommon by "BitHead" on Flickr
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[1] ...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 :)

Notes

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

mardi, septembre 29 2009

Le fond de la trousse à outil de papy

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 !

Tools - Creative Common by mtneer_man on Flickr

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[1] 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.

Notes

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

- page 2 de 3 -