23
juil.
'12

Reverse-engineering d'application Flex

Publié le 23 juillet 2012

Tout récemment, j'ai eu à auditer un jeu en ligne pour un client, et je m'attendai à un jeu super travaillé qui repose sur des standards connus (un jeu en HTML5/CSS3/JS comme l'excellent CutTheRope). Mais non, je me suis retrouvé face à un jeu basé sur Flash et la technologie Flex. Si vous êtes un lecteur régulier de ce blog, vous devez savoir que les applications Flash ne me rebuttent pas, bien au contraire !

La prise en main du jeu est simple, mais le dialogue avec le serveur de jeu reste très obscur (car il s'agit d'un MEUPORG, bien sûr). D'après les captures effectuées, les données respectent le format Action Message Format (AMF) défini par Adobe, j'y avais déjà touché à l'époque des débuts de Deezer mais je suis loin d'en être un grand fan. Après de plus amples recherches, j'ai découvert qu'il s'agissait d'une application Flex, dialoguant avec plusieurs serveurs de jeu via de l'AMFRPC, un protocole activement employé par Flex. J'ai donc du m'équiper.

1. Outillage

Pour analyser des applications Flash, rien de mieux qu'un décompilateur Flash de renom. Pour ma part, je n'utilise pas Flare car incompatible avec les dernières versions de Flash, mais son pendant payant et pour Windows SWFDecompiler de Sothink. Cet outil reste LA référence dans le domaine, et permet de désassembler (presque) toutes les applications Flash. A cela s'ajoute la suite SWFTOOLS, bien pratique pour extraire des informations d'applications Flash (des ressources notamment).

Pour le proxy web, j'ai opté pour Charles Web Proxy. Il s'agit encore une fois d'un outil pour Windows, mais vu que de toute façon j'utilise déjà SWFDecompiler ... Charles Web Proxy permet de faire ce que tout bon proxy web transparent doit normalement savoir faire: espionner les requêtes, autoriser des points d'arrêt et surtout être capable de décoder et d'encoder les données selon plusieurs formats, dont l'AMF. On pourrait aussi employer Burp, qui possède la même fonctionnalité.

Pour terminer, la bibliothèque Python PyAMF permet de coder rapidement des clients AMFRPC en Python, très pratique dans notre cas.

Muni de ces outils, il est alors aisé d'intercepter les appels AMFRPC, de les analyser et de comprendre le fonctionnement global du service distant.

2. Flex, services et méthodes

Les applications Flex reposent sur des endpoints dans lesquels des services sont exposés, qui implémentent des méthodes que l'application Flash peut appeler à distance. Il s'agit ici de ce qu'on appelle couramment un système d'appel de procédure distante, ou Remote Procedure Call (RPC). Ce système de service est très courant, et permet d'offrir plusieurs services sur un seul point de connexion (ou endpoint.

Du point de vue d'un pentester, un service Flex est une grosse boîte noire possédant des services qui implémentent des méthodes, qu'il va falloir découvrir. Pour cela, plusieurs solutions sont envisageables:

Le dernier point est un peu plus ardu, car nécessite le développement d'un client AMFRPC dédié. Les deux premières méthodes sont donc préférables. J'ai ainsi débuté mon analyse par une décompilation du fichier SWF contenant le coeur de l'application. Et les ennuis ont commencés: SWFDecompiler plante lâchement durant l'analyse, et impossible donc d'obtenir le code de l'application. J'ai fait de nombreuses tentatives, avec différents logiciels, sans succès. Il semblerait que SWFDecompiler ait montré ses limites. Cela signifie-t-il qu'il est impossible d'extraire quoique ce soit de ce fichier ? Que nenni (© Tixlegeek)

2.1. Flasm + strings + grep = FTW (plan B)

N'ayant pas la possibilité de désassembler l'application, le plan B consiste à extraire directement du fichier les chaînes de caractères et à essayer de déduire les services des informations s'y trouvant. Avant toute chose, on fait appel à la commande file pour identifier le type d'application:

$ file ZOMFG.swf
ZOMFG.swf: Macromedia Flash data (compressed), version 10

Il s'agit d'une application Flash >=10 compressée. Autrement dit, rien ne sert de grepper directement le contenu du fichier, c'est compressé. Il nous faut donc décompresser ce fichier, grâce à flasm:

$ flasm -x ZOMFG.swf
ZOMFG.swf successfully decompressed, 7958828 bytes
$ file ZOMFG.swf
ZOMFG.swf: Macromedia Flash data, version 10

Il est ensuite trivial d'extraire les chaînes de caractères avec strings, et de grepper le résultat à la recherche d'éléments intéressants:

$ strings ZOMFG.swf > ZOMFG.txt
$ grep ZOMFG.txt -e "some keywords here"

Il est aussi possible d'utiliser vim et ses recherches par motif, ou autre.

2.2. Analyse de flux

L'analyse de flux est relativement simple à réaliser grâce à Charles Web Proxy: celui-ci parse vraiment bien les messages AMF mais n'affiche pas tout (comme par exemple certaines listes), cependant cela reste un compagnon de choix ! Cette analyse de flux permet de mettre à jour un certain nombres de services, ainsi que de méthodes.

Il suffit d'utiliser l'application, et de noter les différents services et les méthodes associées. De plus, il peut être intéressant de repérer les différents messages et les champs associés, afin d'envisager des attaques par rejeu par la suite.

Le champ destination contient la référence au service, ici appelé "SMC". Le champ operation décrit la méthode à appeler, en l'occurrence "ExecuteServerCall".

{2.3. Enumération des {services et des méthodes associées}}

Cette dernière possibilité repose sur les résultats produits par les deux étapes précédentes: à l'aide de la première analyse, on établit une liste potentielle de services et de noms de méthodes, puis à l'aide d'un client AMFRPC maison, on teste la validité des services puis on détermine les méthodes existantes à partir des services identifiés.

Cette technique permet de déterminer de manière plus efficace les services et les méthodes associées, et permet de trouver dans certains cas des éléments non-présents dans l'application. J'ai développé dans le cadre de ce test d'application un outil semblable à DeBlaze, mais permettant de tester un service Flex distant (et aussi beaucoup moins poussé). Cet outil repose sur la bibliothèque Python PyAMF, et tente de déterminer les services offerts par un endpoint donné. Cela suppose que l'on connaisse le nom de cet endpoint, qui peut être trouvé via les deux méthodes précédentes.

Je ne peux pas dévoiler le code source de cet outil dans ce post (ooooh!), car il est soumis à des règles relativement strictes de confidentialité, propres à Sysdream. Cependant, l'algorithme de base est le suivant (aaaah !):

Pour chaque nom de service probable:
    resultat = tenter un appel à la méthode Trololololo
    Si pas d'erreur d'invocation:
        Affiche 'Service: ' + service
        Pour chaque méthode probable:
            resultat =appeler  la méthode 'methode' du service
            Si aucune erreur d'invocation ni message de méthode non trouvée:
                  Affiche '- Methode:' + methode

De cette manière, on teste l'ensemble des services possibles et des méthodes probables. On peut aussi envisager des combinaisons de nom, des changement de casse, etc ... A noter que la référence à l'endpoint est obligatoire dans les headers Flex.

3. Sessions Flex

Lors de mes tests, j'ai été rapidement rejeté par le service Flex à cause des sessions. En effet, les applications Flex font appel à une gestion de session en Java (donc un cookie JSESSIONID par défaut), et il faut gérer ce cookie dans le client AMF pour pouvoir maintenir une session correcte. De même, l'envoi des requêtes via des "messages" AMF est basé sur une numérotation qui est continuellement incrémentée. Celle-ci doit aussi être maintenue par notre client AMF.

Lors des tests, et tout particulièrement lors des tests fonctionnels, les sessions sont primordiales et bien souvent mises de côté par les outils qui ne font pour la plupart que des tests unitaires. Ce qui impose dans bien des cas l'implémentation d'un client Flex maison prenant en charge ces sessions, quand il n'y a pas d'autres éléments de cookie à prendre en compte, bien sûr.

4. Conclusion

Les tests d'applications Flex se rapprochent fortement des tests de services web, car au fond le système Flex n'est rien d'autre qu'un service web basé sur AMF (au lieu des services SOAP que l'on retrouve souvent). Sans les possibilités de découverte des services et méthodes offertes par WSDL. Je pense avoir fait le tour des principaux soucis rencontrés durant le test de ce type d'application, même si le cas évoqué ici était un brin récalcitrant. D'ailleurs à ce jour, je n'ai pas trouvé de logiciel de décompilation permettant de décompiler ce satané SWF. Si quelqu'un a une idée (ou une révélation divine), me contacter via twitter ou via gmail.

07
juin
'12

La difficile publication de vulnérabilité

Publié le 07 juin 2012

La philosophie du hacking implique une curiosité constante, et donc le fait que l'on mette notre nez un peu partout. C'est grâce à cela que des problèmes voire même des vulnérabilités sont identifiés, et résolus. Le problème, car il y a problème, réside dans la difficile communication et le fait que l'on fasse une très bonne cible en faisant part d'une trouvaille.

La curiosité est un vilain défaut

Tout le monde le sait. C'est pas bien. Mais il est des personnes qui ne peuvent s'empêcher de se poser des questions, légitimes ou non. Ce n'est pas (encore) une maladie, mais c'est ce qui motive certaines personnes. Dont moi. Et je dois avouer que la plupart du temps, c'est assez payant. Cette curiosité est le moteur essentiel de ce blog, de mes outils, etc ... Tout vient de questions que n'importe qui (enfin, je suppose que n'importe qui se les pose) pourrait se poser, et de la réflexion qui s'ensuit.

Malheureusement (sic), cette curiosité pousse des fois à tester ou vérifier des faits, à la limite de la légalité. Ce qui permet de cerner correctement un problème et de le reporter ou d'alerter. Et c'est lorsqu'on alerte, que l'on prévient, que les choses se corsent. Car dans certains cas de figure, la question d'où part une analyse ou une réflexion peut être considérée comme inopportune voire comme une action offensive. Alors qu'il s'agissait de pure curiosité, sans animosité aucune. Mais certaines personnes ne voient pas cela d'un bon œil, car le fait d'alerter ou de reporter peut nuire à leur image (ou celle de leur entreprise, ou administration) et je comprends tout à fait le besoin de se couvrir. Il est vrai qu'en France on a cette aversion naturelle contre les hackers (favorisée par les médias), et d'autant plus pour ceux qui publient des choses qui fâchent ou ennuient.

La nécessité de transparence ?

Il est évident que la publication, la diffusion, le fait d'alerter sur une vulnérabilité ou un problème identifié ne doit pas être fait n'importe comment. Certains préfèrent l'anonymat, et dévoilent à coup de pastebin des fuites d'informations, ou des vulnérabilités originales. S'ensuit généralement une tentative d'identification de la source, qui des fois aboutit après de fastidieuses recherches. Mais le fait de publier sous couvert d'anonymat vous place directement dans la mauvaise catégorie: pourquoi vous cachez-vous, si vous n'avez rien à vous reprocher ?

A contrario, beaucoup d'entre-nous pensent que la transparence est le meilleur atout. Nous nous permettons de publier des alertes, de reporter des problèmes ou des erreurs en toute bonne foi, sans nous cacher forcément derrière un pseudonyme (bien qu'on puisse en avoir un) et revendiquer la trouvaille. Si jamais quelqu'un est froissé, ou ennuyé par une publication, l'auteur de celle-ci est identifiable et joignable. De fait, annoncer sur Twitter ou par email sans masquer son identité est gage de sérieux, ou de grande folie. Malheureusement, lorsque les choses se gâtent, la seconde option est préférée.

Heuu ... à quand une prise de conscience ?

De suite, on tape sur la personne qui a identifié le problème. Vous annoncez sur Twitter que vous avez identifié une vulnérabilité dans un produit sans donner trop de détails ? Vous dévoilez un fichier planqué au fin fond du web et contenant des informations critiques ? Vous avez identifié un problème ou une anomalie et communiquez dessus au monde entier ? You're doing it wrong. Et même si l'envie vous prend de le transmettre par email, l'issue est globalement la même: l'annonceur est fautif. Victime de sa curiosité. Et peut-être de sa volonté d'alerter et de faire connaître sa trouvaille. On tire sur le messager, meme si je dois avouer que dans certains cas il n'est pas forcément tout blanc.

La problématique est ancienne: comment dévoiler une vulnérabilité/anomalie/faille en toute bonne foi, sans se cacher, et sans risquer les foudres des personnes concernées ? Quid du responsible disclosure ? C'est un débat qui dure, bien qu'en France il soit déjà plié, j'en ai bien peur. Par expérience, j'ai tendance à dire que lorsque l'on tente de dévoiler ou d'alerter, on devient une cible (que cela soit justifié ou non, là n'est pas la question). Certes, nous pronons le hacking "éthique", et cette volonté de transparence et de communication fait partie de cette éthique. Mais sincèrement, il est plus risqué de communiquer sur une vulnérabilité que de se taire et de la garder pour soi. Beaucoup en ont fait l'expérience: Guillermito [1], Damien Bancal [2] par exemple.

Alors, comment dévoiler/communiquer ?

Le constat est triste: soit on dévoile et on risque les sanctions prévues aux différents articles de la loi française (pour rappel, les articles 323-1 à 323-7 [3], avec des peines allant de 2 ans d'emprisonnement et 30 000€ d'amende à 5 ans d'emprisonnement et 75 000€ d'amende), bien que de bonne foi, soit on se tait et les choses ne bougent pas. J'avoue que cette vision est pessimiste, mais sincèrement je ne vois pas comment on pourrait éviter cela. Triste constat, disais-je.

Allons-nous devoir attendre que les responsables sécurité arrêtent de faire la sourde oreille et tentent de sauver leur place sans assumer les problèmes qui se posent ? Faut-il encore diaboliser Internet, l'informatique et le hacking en général, ainsi que les personnes compétentes en France ? L'ANSSI a ouvert la voie (du moins on ose le croire), en faisant appel à la culture hacker (il n'y a qu'à voir leur wallpaper `4]), en recrutant massivement et en le faisant savoir à différentes conférences sécurité prisées des hackers (non, pas de troll sur l'AN^W^WSSTIC). A qui le tour ?

Références

[1] [L'affaire Guillermito <http://guillermito2.net/archives/2004_12_28.html>`_

`2] [Damien Bancal (Zataz) vs le FTP anonyme <http://www.pcinpact.com/news/48753-zataz-faille-securite-trou-signalement.htm>`_

`3] [Code pénal, Livre III, Titre III, Chapitre III: Des atteintes aux systèmes de traitement automatisés de données <http://www.legifrance.gouv.fr/affichCode.do;jsessionid=DBA449F582FD48DF11068D44A409B79B.tpdjo07v_3?idSectionTA=LEGISCTA000006149839&cidTexte=LEGITEXT000006070719&dateTexte=20120510>`_

`4] [Wallpaper ANSSI <http://www.ssi.gouv.fr/IMG/png/wallpaper-anssi-2560x1920.png>`_

24
janv.
'10

Back from Insomni'hack 2010

Publié le 24 janvier 2010

De retour de Genève, où j'ai participé avec le reste de la team HZV à Insomni'hack 2010. Insomni'hack est un concours d'ethical hacking qui regroupe divers hackers (espagnols, français, suisses, et autres) autour de challenges concernant divers domaines de la sécurité informatique.

Nous sommes allé à Genève en train, où nous avons retrouvé les gars de Maubeuge (FaSm, Koreth, TiteFleur, Shatter) et Nagual. Après un bref passage à l'hotel, histoire de poser les bagages, nous sommes partis en direction de l'Hepia. On salue, s'installe, et là on subit le classique problème des prises: en effet, la Suisse a des prises bien particulières (on le savait avant de venir), mais nous n'avions pas trouvé d'adaptateur(s) entre le départ et l'arrivée à l'Hepia. Un autre challenger français a partagé son adaptateur, et on a pu brancher notre série de rallonges dessus, ouf.

Petit discours du directeur avec un bon accent suisse, puis début du challenge. On boit, on bouffe, on code, et on cherche. Au programme: analyse par rétro-conception, attaques web par rejeu, vulnérabilités web "classiques" (htaccess avec limit get, CAPTCHA, ...), un peu de crypto, et puis du forensics (pcap et pdf). C'était bien fun. 1h du mat, fin du contest, et le résultat: Trance premier (représentant HZV), suivi de Samsa, de Nagual et d'Acissi (les gars de Maubeuge). Remise des lots: Trance reçoit une panoplie de tshirts, une suite av offerte par kaspersky (je suis sur que Heurs va adorer travailler dessus), et un boitier fortinet anti-virus, pare-feu, etc ...

Nous saluons nos challengers, et puis grande séance de tentative de discussion avec Samsa, le second du contest, qui est d'origine espagnole. Mais il parle français, sous la torture. Un gars super simple, très sympa, et qui nous a convié à passer à Madrid en mars. On va essayer de pas manquer le rendez-vous. On salue ensuite tout le monde, et on termine la soirée à l'Ibis, avec 1l de vodka, 4 cannettes de redbull, et plein de trolls. Quelques heures plus tard, on se lève et on joue les touristes, histoire de pas partir sans avoir vu le lac et son jet d'eau de malade (qui doit faire mal au cul si on s'assoit dessus, comme le dit F|UxIuS). Puis rentrage en TGV, dodo, et de retour sur Paris.

Un évènement bien sympa, quoique court (à 1h du mat ils ont tout fermé, et nous ont mis à la porte, c'était moyen ^^). De même, les épreuves étaient de qualité (quoique parfois irréalistes, et kikoololz) Mais on reviendra peut-être. Néanmoins, il y a de bonnes idées et quelques erreurs qui sont formatrices (réseau saturé, notamment lors des phases de bruteforce nécessaires pour réussir certaines épreuves).

Petit bonux: on a retrouvé l'hotel de Billou à Genève. Il y a même garé sa voiture devant ...

<center><embed type="application/x-shockwave-flash" src="http://picasaweb.google.fr/s/c/bin/slideshow.swf" width="288" height="192" flashvars="host=picasaweb.google.fr&hl=fr&feat=flashalbum&RGB=0x000000&feed=http%3A%2F%2Fpicasaweb.google.fr%2Fdata%2Ffeed%2Fapi%2Fuser%2Fvirtualabs%2Falbumid%2F5430576548463802369%3Falt%3Drss%26kind%3Dphoto%26authkey%3DGv1sRgCKmIq6aVvqSu2wE%26hl%3Dfr" pluginspage="http://www.macromedia.com/go/getflashplayer"></embed></center>

Liens connexes

http://www.tdg.ch/actu/hi-tech/hacking-defient-geneve-2010-01-24



Les contenus disponibles sur ce blog sont publiés sous licence Creative Commons BY-NC-SA.
Vous pouvez réutiliser tout ou partie de ces contenus à condition de citer l'auteur et l'origine, vous ne pouvez en faire une utilisation commerciale, et enfin vous devez partager tout travail ou œuvre dérivée sous les mêmes conditions — c'est-à-dire avec la même licence d'utilisation Creative Commons.