[EDIT]

Le projet a subit de nombreux changements depuis la publication de ce billet. J’ai publié la première version du projet ici ; en attendant un tutorial vous pouvez retrouver des informations plus à jour dans ce billet. Gardez à l’esprit que les informations qui suivent (et particulièrement le jargon associé à l’outil ainsi que les fonctionnalités) ne sont plus complétement valides…

Le projet

XeeK, pour XSS Easy Exploitation Kernel, est un projet dont l’objectif est le suivant : démontrer la puissance de la XSS en proposant un outil pour exploiter facilement ce type de faille. Les premières idées qui ont engendré ce projet me sont venues cet été, mais c’est uniquement depuis quelques semaines que j’ai vraiment commencé à y travailler.

Un noyau et des modules

Certains me trouveront peut-être un peu ambitieux, mais mon but serait de faire de XeeK une sorte de Metasploit pour la XSS. Pour dire les choses autrement, l’objectif serait de proposer un framework, c’est à dire un ensemble de classes, ou de modules capables d’interagir ensemble. En fait, si le K de XeeK signifie kernel (noyau) c’est parce qu’il sera effectivement composé d’un noyau proposant les fonctionnalités génériques de base et d’une suite de modules qui pourront s’y greffer. Dans l’idéal, ces modules pourront être développés par n’importe qui. A titre de comparaison, considérez le noyau Linux et ses modules, ou bien Firefox et ses extensions.

Architecture

Concrètement, XeeK se composera d’une interface Web déployée sur un serveur appartenant à un attaquant, disons hacker.com. XeeK étant censé faciliter l’exploitation des failles XSS, il appartient à l’attaquant de découvrir ces failles ; je n’envisage pour le moment pas d’intégrer un scanner de ce type dans l’outil. Une fois une XSS trouvée sur un site quelconque, disons victime.com, l’attaquant pourra utiliser l’interface de XeeK afin de générer un exploit personnalisé et paramétrable. Après avoir défini l’exploit, celui-ci pourra être intégré à un lien piégé exploitant la XSS sur victime.com. Il ne restera plus à l’attaquant qu’à faire cliquer la victime sur ce lien…

Dans le jargon XeeK, l’attaquant commencera par créer une session, choisira sa ou ses victimes, et sélectionnera un scheduler, ou ordonnanceur. C’est ce composant qui déterminera comment les actions de l’exploit seront exécutées sur le navigateur de la victime. J’envisage pour le moment deux types de schedulers :

• Statique — toutes les actions de l’exploit seront définies à l’avance et intégrées « en dur » de façon définitive.
• Dynamique — l’exploit chargé sur le navigateur de la victime ne contiendra pas les actions proprement dit, mais un loader qui sera chargé de récupérer les actions sur le serveur XeeK (hacker.com) de façon dynamique et transparente. Ainsi, l’attaquant pourra modifier l’exploit et suivre la progression de la victime en temps réel.

Les actions exécutées chez les victimes seront susceptibles de retourner des résultats qui seront visualisables directement par le biais de l’interface. En fait, XeeK cachera l’aspect technique de l’exploitation et sera conçu pour simplifier au maximum les choses à l’attaquant. Plus précisément, l’attaquant aura devant lui une interface ressemblant à un debugger, à partir de laquelle il lance son exploit, observe sa progression et visualise les résultats. La différence avec un vrai debugger est que cet exploit sera exécuté sur les victimes et non sur sa propre machine…

Une application : BotNet

Puisque XeeK supportera plusieurs sessions en simultanée, chacune supportant elle-même plusieurs victimes, on en arrive à une des applications potentielles de l’outil : faire office de BotNet. Pour ceux qui l’ignorent, un botnet est un réseau de machines zombies contrôlable par un attaquant via un protocole quelconque. Ici, il s’agira de simples requêtes HTTP. La différence avec les « vrais » botnets est qu’ici, le code malveillant s’exécutera uniquement lorsque la victime aura son navigateur d’ouvert sur la page piégée.

Pour aider à la propagation du botnet, la possibilité la plus simple est d’utiliser une XSS permanente, c’est à dire quand l’injection de code est enregistrée en dur sur le site et affecte tous les visiteurs. Ainsi chaque visiteur tombant sur la page piégée rejoindra automatiquement le botnet à son insu et exécutera le même exploit que ses collègues. Tout cela grâce à une malheureuse petite XSS…

Imaginez qu’un site très connu et utilisé par des milliers de visiteurs soit vulnérable à une XSS permanente. Avec XeeK, il devient possible de lancer une attaque de masse contre tous les visiteurs de la page.

Fonctionnalités

Qu’est-ce que XeeK saura faire ? A vrai dire, les fonctionnalités définitives ne sont pas encore décidées (vu que les modules seront extensibles), mais voici un aperçu de ce que j’envisage.

• Furtivité du point de vue du visiteur (le site exploité continue à fonctionner sans problèmes).
• Exécution de code JavaScript arbitraire.
• Envoi de requêtes asynchrones (Ajax) vers le site vulnérable. Une des applications pourraît être d’exploiter des éventuelles failles XSRF (Cross Site Request Forgery).
• Envoi de requêtes asynchrones vers d’autres sites.
• Détournement de formulaire. Exemple : lorsque la victime remplit un des formulaires de la page, tout son contenu est envoyé sur hacker.com de façon transparente.
• Récupération de cookies.
• Récupération du contenu de la page (code HTML vu par la victime).
• Plus généralement, récupération de n’importe quelle variable accessible par JavaScript et DOM.
• Traceur de visiteur. L’exécution de l’exploit continue même si le visiteur change de page, chaque nouvelle page visitée étant loguée et accessible directement par l’attaquant.
• Simulation de clic sur des liens / boutons / n’importe quel élément graphique des pages.
• Fonctionne aussi bien en HTTPS qu’en HTTP ; cela ne change absolument rien.

Technologies

XeeK est pour le moment développé à l’aide de PHP, JavaScript, Ajax et MySQL. Bien entendu, les langages liés tels que CSS et HTML sont également utilisés à foison. Pour ce qui est de la compatibilité des navigateurs, pour être sincère je n’ai encore utilisé que Firefox. Soyons honnête ; je ne suis ni designer ni un pros des subtilités de chaque navigateur. Mais je tiens à préciser qu’avant d’effectuer une release, je ferais mon possible pour au moins que la partie « victime » de l’outil fonctionne sur IE qui est toujours, il faut le rappeler, le navigateur le plus utilisé. Je vise au moins IE7, peut-être IE6 mais il ne faut peut-être pas trop en demander pour une 1ère release

Release

Je sens venir la question « Quand XeeK sera-t-il publié ?« . Je n’ai malheureusement pas encore de réponse pour le moment. XeeK est encore au stade de prototype même si plusieurs fonctionnalités marchent déjà bien. Il me reste à concevoir la partie interface de l’outil, améliorer deux/trois petites choses, tester la partie exploitation sous IE… Comme vous pouvez vous en douter je ne travaille pas sur ce projet à plein temps, j’ai aussi des études. Pour donner une estimation, j’espère pouvoir publier une première release avant 2009. Mais cela ne constitue pas une garantie… En effet, je préfère prendre mon temps pour bien faire les choses, plutôt que de sortir quelque chose de bancal le plus vite possible. Au pire, je sortirais une alpha ou béta avant sa vraie sortie.

XeeK sera publié sous license GPL (2 ou 3). En d’autres termes, n’importe qui pourra utiliser, développer et améliorer l’outil à condition qu’il publie ses travaux également sous GPL.

Click and hack

Certains me reprocheront peut-être :

Tu n’as pas honte, de mettre à disposition des scripts kiddies un outil aussi dangereux, où il suffit de cliquer pour pirater ?

Je leur répondrai tout simplement non pour plusieurs raisons :

• Il existe des outils similaires encore lus puissants et plus simples à utiliser. Exemple : Metasploit. Personne ne se plaint de cet outil (enfin pas à ma connaissance) alors qu’il permet de rooter une machine sans aucune connaissance technique. C’est un outil utilisé par des professionnel pour le penetration testing.
• Cet outil n’est pas plus « dangereux » que les possibilités offertes par la faille XSS. Il essaye juste d’utiliser ces possibilités au maximum.
• En sortant cet outil et en le faisant connaître, j’espère faire prendre conscience à plus d’un que les failles XSS sont vraiment dangereuses, ce qui semble ne vraiment pas encore être le cas.

Sur ce, je crois que j’ai tout dit… Je vais continuer le développement de ce projet en espérant ne pas mettre trop de temps à le publier. Si vous avez des questions ou suggestions, les commentaires sont là pour ça !

Pour concevoir une application parallèle, on utilise assez souvent la programmation par messages. Dans le cadre de notre projet, nous utilisons la bibliothèque LAM/MPI qui fournit toute une API permettant d’envoyer des messages à des processus tournant sur des machines distantes. De plus, le but étant d’injecter des fautes, nous avons choisit de provoquer ces fautes lors des envois et réceptions de messages. Ainsi nous pouvons facilement simuler aussi bien les pannes logicielles (déni de service) et matérielles (coupure de lien d’un réseau, paquet perdu ou corrompu). Pour détourner les fonctions fournies par la bibliothèque LAM/MPI, nous utilisons la variable d’environnement LD_PRELOAD. Cette variable des systèmes UNIX/Linux permet de charger dynamiquement une bibliothèque au lancement d’une application. Le point intéressant est que cette bibliothèque peut redéfinir des fonctions qui existent déjà dans les autres bibliothèques, donc peut potentiellement les appeler tout en modifiant leur comportement.

LD_PRELOAD permet alors de modifier le comportement d’une application tout en n’ayant pas besoin de la recompiler ! Il est toutefois important de préciser que cette technique ne permet de détourner (hooker) que les fonctions définies dans des librairies dynamiques. C’est un point crucial et qui nous a posé quelques problèmes. En effet nous utilisions au départ la librairie MPICH 1, et il se trouve que lorsqu’une application est compilée avec, les appels MPI sont liés de manière statique. Un simple appel à la commande ldd permet de le voir. C’est pourquoi nous avons choisis d’utiliser LAM/MPI à la place.

Ainsi, nous avons développé une bibliothèque dynamique (fichier .so) dont le but est de venir d’interposer entre l’application parallèle et LAM/MPI. Cette bibliothèque (que nous avons nommé bibliothèque d’interposition) redéfinit les fonctions MPI_Send() et MPI_Recv() en injectant des fautes comme des corruptions de données et des dénis de service. Les fautes ne sont pas générées de manière permanentes ; nous utilisons en plus un processus qui tourne en tâche de fond (démon) qui communique avec la librairie par l’intermédiaire d’un segment de mémoire partagé. Ce démon est en réalité un serveur utilisant CORBA. Son rôle est de rester en attente de requêtes et de dialoguer avec la librairie pour déclencher l’injection de fautes. Il surveille également l’application ainsi que le système par l’intermédiaire de sondes logicielles afin de suivre en temps réel les valeurs de quelques variables, comme la charge CPU, l’occupation mémoire, etc. Ces valeurs sont sauvegardées dans une base de données pour être retraitées plus tard par un module de statistiques.

Sur chaque machine tournent donc : une instance de l’application distribuée, une instance de la bibliothèque d’interposition, et une instance du démon. Mais en plus de tout cela, il faut être capable de déployer l’application parallèle. Nous avons donc conçu un module dédié à cela, le simulateur. Il est contrôlable en ligne de commande ou via une interface graphique. Son but est de lancer l’application parallèle, les démons et activer le détournement de fonction en exportant la variable LD_PRELOAD sur toutes les machines.

Ce projet, bien que relativement complexe, se révèle très intéressant. Cela nous a permis de découvrir et d’utiliser des libraires et des technologies très utiles, comme CORBA, MPI, Boost, MySQL++. Nous utilisons également Flex et Bison pour la conception de l’interpréteur de commandes du simulateur.

Au fut et à mesure du développement, je mettrai sans doute en ligne quelques billets exposant de façon plus détaillée la conception de certains des modules.

Avec un ami, nous avons eu une idée commune : tant qu’à faire une application de simulation, autant se faire plaisir et la réaliser en 3D. Fans des technologies libres, nous avons donc choisi OpenGL et Glut. Nous avions tous les deux une petite expérience en OpenGL, pour ma part ce fut mon deuxième projet C++/OpenGL, bien que je trouve bien plus complexe que le 1er. Étant donné que nous n’avions pas des talents d’artistes, nous avons choisi de faire simple pour ce qui était de la représentation du monde et des individus. Les adeptes de Glut ou plus généralement de la 3D connaissent probablement la fameuse Théière de l’Utah utilisée dans un certain nombre d’applications 3D. Ce modèle étant déjà présent par défaut dans la bibliothèque GLUT, nous avons décidé de l’utiliser pour représenter les individus de nos colonies. Et nous en avons profité pour baptiser notre projet «Teapot Colony Wars».

Nous avions le choix du langage, et nous avons choisi le C++ non seulement pour sa rapidité, sa portabilité, mais aussi parce que nous souhaitions progresser dans ce domaine. Et tant qu’à faire, nous l’avons développé dans le but de le diffuser sous licence GPL 2, pour qu’il continue à vivre et évoluer si certains veulent le reprendre. De plus, nous avons vraiment eu la volonté de développer un projet en nous rapprochant du monde professionnel, tout en n’utilisant que des logiciels libres. Nous avons utilisé Subversion, un excellent outil de gestion de versions qui nous a bien simplifié la tâche pour le développement, ainsi que Doxygen, pour la génération de la documentation. Le rapport de conception a été réalisé en LaTeX, et la compilation de l’exécutable a été grandement facilité par l’emploi des Autotools (AutoConf, AutoMake, …).

Au final, Teapot Colony Wars, c’est :

• 96 fichiers sources (uniquement les .h et .cpp)
• Un diagramme de 45 classes
• Plus de 9600 lignes de code C++
• Un délai de 6 semaines pour réaliser le projet (pendant lesquelles nous avons eu des examens…)
• Plus de 280 heures de travail
• 268 révisions dans le dépot Subversion
• Une documentation PDF de 449 pages générée par Doxygen
• Un rapport de 28 pages décrivant la modélisation et nos choix conceptuels

Nous avons profité de la livraison du projet pour publier la version 1 sur Sourceforge.net. Voici quelques unes des caractéristiques de l’application :

• Le monde est composé de plusieurs colonies, chacune ayant sa couleur.
• Chaque colonie peut créer des individus qui possèdent des caractéristiques propres comme sa taille. Une colonie consomme de la nourriture pour créer un individu.
• Le monde est composé d’une grille de cellules qui ont chacune des propriétés. Certaines sont inaccessibles (murs), d’autres contiennent de la nourriture qui se renouvelle au fur et à mesure de la simulation (certaines sont à renouvellement instantané, mais pas d’autres). Certaines cases sont des couloirs et inaccessibles aux individus trop grands.
• Les individus évoluent selon certaines stratégies comportementales que la colonie leur impose. Leur but est de trouver de la nourriture et de la ramener à la colonie. Mais à chaque pas, un individu consomme de la nourriture proportionnellement à sa taille.
• Chaque individu ne peut voir que les 8 cases adjacentes et a une très petite mémoire : il ne peut se souvenir que de la dernière case qu’il a franchie. Mais pour l’aider, il peut déposer des phéromones sur son passage. Chaque colonie définit ainsi 3 phéromones qui ne peuvent être comprises que par ses individus. Chaque phéromone a une durée de vie et se dégrade au fur et à mesure, jusqu’à disparaître.
• Quand deux individus ennemis se croisent, il y a combat. C’est le plus fort qui gagne ! Le vainqueur peut alors se nourrir du cadavre de ses adversaires.
• L’utilisateur peut à sa guise faire une offrande en déposant une source de nourriture sur le terrain.
• Il était demandé de tester deux stratégies différentes pour les individus. Les algorithmes heuristiques, qui peuvent être simples mais souvent imparfaits, et les algorithmes génétiques, consistant à définir des gènes pour les individus et effectuer un brassage génétique de la population en sélectionnant les meilleurs.

Les commandes souris et clavier du simulateur sont les suivantes :

• Pavé numérique (4, 6 8, 2) : déplacements horizontaux et verticaux
• Molette ou touches + et – : zoom
• Maintien de Ctrl et défilement de la molette (ou + et -) : inclinaison verticale
• Maintien de Ctrl + Clic gauche ou droit : rotation à gauche ou à droite
• Espace : Activer / enlever le mode pause
• Clic gauche : effectuer une itération
• Étoile (*) : donner une offrande aux individus, qui apparaîtra sur le curseur de sélection (tore en bleu clair)

Nous sommes globalement très satisfaits de ce projet, car nous avons pu finir dans les temps, même si nous aurions aimé rajouter quelques fonctionnalités supplémentaires. Mais cela restera tout à fait possible étant donné la grande extensibilité de notre application. En effet, grâce à un usage intensif de toutes les techniques propres à la modélisation orientée objet, comme le polymorphisme et les designs patterns, nous avons construit un ensemble de classes génériques, qui peuvent s’apparenter à un framework. Il est ainsi tout à fait possible de rajouter à moindre coût des nouvelles cases, des nouveaux types d’individus, changer leur représentation (pour ceux qui n’aiment pas les théières…), changer le système de combat, et même pourquoi pas rajouter de nouveaux mouvements (comme le saut ou la téléportation).

Si cela vous intéresse, vous pouvez télécharger la version 1.0 du projet, tel que nous l’avons rendu à nous professeurs. Les sources sont disponibles, ainsi que les exécutables pour Linux et Windows. Attention toutefois pour ce dernier, il semble que la portabilité soit encore un tout petit peu imparfaite ; en effet nous n’avons pas encore eu le temps de changer quelques détails qui peuvent bloquer la génération de l’exécutable selon le compilateur utilisé. Mais nous allons bientôt remédier à cela…

Voici les liens pour accéder aux ressources du projet :

• Site du projet sur Sourceforge.net
• La page de téléchargement
• Le dépot SVN accessible en ligne
• Les détails pour effectuer un check-out du SVN
• La documentation HTML en ligne

Pour lancer l’application sous Windows, vous avez juste à lancer l’exécutable. Sous Linux, pensez toutefois à lancer l’application en mode console pour éviter les surprises ; en effet, il faut que le dossier de textures se trouve dans le dossier courant.

Pour compiler le projet sous Linux, assurez-vous de disposer des bibliothèques pour le développement d’application graphiques, en particulier Glut. Décompressez l’archive dans un répertoire, puis tapez les instructions suivantes :

$ ./configure --prefix=$HOME

$ make

$ make install

L’application s’installera automatiquement dans votre homedir, dans le dossier bin. Si la documentation vous tente, vous pouvez générer le HTML et les fichiers LaTeX en tapant :

$ doxygen Doxyfile

Ensuite, placez-vous dans le dossier doc/latex et tapez simplement :

$ make

Le PDF résultat se nomme «refman.pdf» et sera généré dans le dossier courant. Bonne lecture…

Un site internet du projet verra peut-être le jour au courant de l’année, si je trouve un peu de temps à y consacrer. N’hésitez pas à me faire part de tous vos commentaires sur ce projet. Profitez de sa licence et faites le vivre !