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

J’ai justement décidé de rédiger ce billet afin de sensibiliser les lecteurs aux véritables dangers qui se trouvent dans la face cachée de cet iceberg qu’est la faille XSS. Comme mon but n’est pas d’aider les script-kiddies à exploiter cette faille, je ne donnerai pas de code ni d’exploit tout fait. Je suppose que les lecteurs ayant quelques connaissances en JavaScript pourront tester eux-mêmes et vérifier la véracité de mes propos…

Les « vraies » possibilités de la XSS

Pour comprendre les enjeux qui se cachent derrière la faille XSS, revenons à la base : qu’est-ce qu’une XSS ? Les initiales XSS signifient Cross Site Scripting, le C ayant été remplacé par le X du fait que CSS signifie déjà Cascade Style Sheets. La faille XSS permet à un attaquant potentiel d’exécuter du code (un script) sur le navigateur du client. Elle apparaît quand un site Web affiche des variables provenant d’une entrée utilisateur sans les filtrer. Ainsi, le simple code PHP suivant est vulnérable :

<?php
echo $_GET['var'];
?>

En effet, un attaquant visitant cette page contrôle directement (par le biais de l’URL) le contenu de la variable $_GET['var']. Il peut alors insérer du code HTML ou JavaScript, et il s’exécutera comme s’il faisait partie du site Web.

Quel intérêt ? Tout simplement le fait de pouvoir manipuler un visiteur en lui donnant un lien piégé. En cliquant sur un lien exploitant la faille XSS, le navigateur du visiteur va afficher le code HTML du site et exécuter le code JavaScript. Cela permet alors de récupérer des informations propres au visiteur, puisque tout le code est exécuté comme s’il provenait du site original. En effet, il faut savoir que si un site X envoie par exemple un cookie à un visiteur, le site Y ne pourra pas le lire. Le fait que la XSS permette d’injecter un script malveillant directement dans le code envoyé par X va donc autoriser ce script à récupérer des informations telles que des cookies.

Mais la récupération de cookie est loin d’être la seule possibilité des XSS. A vrai dire, la XSS offre absolument toutes les possibilités qu’offre JavaScript, puisqu’elle permet l’exécution de code JS arbitraire sur le navigateur. Citons quelques exemples :

• Vol de cookies, détournement de session
• Accès aux mêmes privilèges que la victime
• Accès au contenu de pages protégées (du moment que la victime peut y accéder)
• Exécution de requêtes arbitraires en se faisant passer pour la victime
• Espionnage de la victime, récupération de toutes les actions effectuées telles que les pages visitées, les saisies dans les formulaires — qui contiennent au passage probablement des mots de passe
• Ouverture de fenêtres de téléchargement de logiciels (pouvant être des spywares, trojans, rootkits…) lorsque la victime surfe sur ce site auquel elle fait confiance — et par conséquent, baisse sa garde

Il faut bien comprendre que la faille XSS permet à l’attaquant d’avoir un accès direct au navigateur de la victime, et qu’il peut alors absolument tout faire sur le site en se faisant passer pour la victime. Si la victime est par exemple un utilisateur lambda d’un forum, l’attaquant pourra poster des messages sous son nom, modifier son profil, et même dans certains cas changer son mot de passe. Si la victime est l’administrateur du forum, je vous laisse imaginer les possibilités offertes…

Attention, il faut cependant bien voir que la XSS ne permet pas l’élévation de privilèges au delà de ceux de la victime, autrement dit un attaquant ne pourra pas faire plus que ne le peut sa victime. Par exemple, s’il piège un utilisateur lambda du forum, il ne pourra pas effectuer des tâches d’administration — à moins bien sûr qu’une autre faille soit présente sur le site.

Est-ce difficile à exploiter ?

Non ! Et c’est une raison de plus pour prendre au sérieux la menace réelle que constitue cette faille ! Concrètement, il suffit d’avoir quelques connaissances en JavaScript pour pouvoir exploiter une faille XSS sur un site de base non protégé. De plus, la popularité grandissante d’Ajax offre encore de nouvelles possibilités, puisque l’objet XMLHttpRequest permet d’effectuer des requêtes asynchrones sur le serveur. Cela permet d’effectuer des requêtes en se faisant passer pour la victime tout en restant invisible. Et même si Ajax ne permet pas d’effectuer de requêtes sur un autre serveur (les requêtes sur des serveurs autres que celui visité ne sont pas permises par le navigateur), il existe une technique permettant de passer outre et d’effectuer des requêtes cross-domain de façon détournée. Il devient alors possibles d’envoyer des requêtes sur un site distant, comme par exemple le site Web de l’attaquant.

Ainsi, en ayant un minimum de connaissances JavaScript, il est possible de concevoir un exploit permettant de dumper un site Web vers une base de données contrôlée par l’attaquant, tout en se faisant passer pour un visiteur et donc en ayant accès à toutes les pages qu’il peut voir. Ainsi, même si l’attaquant n’a aucune connaissance au préalable d’un site Web et des éventuelles zones à accès réservés, il peut étudier ces dumps en off-line de façon totalement invisible puisqu’il ne consulte jamais le serveur directement. Il pourra alors mettre au point un second exploit qui lui permettra par la suite d’effectuer véritablement l’attaque en effectuant des requêtes pour le compte de la victime.

Les techniques qui ne protègent pas un site contre les XSS

Les pratiques suivantes ne protègent en rien un site Web contre les XSS :

• Vérification les IP des visiteurs authentifiés — inutile puisque le code est exécuté par la victime !
• Protections par .htaccess — inutile puisque si la victime est authentifiée, la requête forgée pourra être exécutée
• Utilisation de HTTPS — ne change absolument rien, JavaScript et Ajax fonctionnent très bien en HTTPS…

Attention, je n’ai pas dit que ces mesures de protections étaient complètement inutiles ; juste que dans le cas de la XSS, elles le sont.

La seule solution pour en finir avec les XSS

On ne le répétera jamais assez, il faut filtrer toutes les entrées utilisateur, en particulier celles que l’on affiche sur le site. Cela est valable pour toutes les variables envoyées par GET, POST, récupérées via les cookies, et plus généralement tout ce qui transite dns les requêtes HTTP, comme les entêtes (dont le célèbre X-Forwarded-For) donc même certaines variables du tableau $_SERVER de PHP. Pour être efficace, la fonction de filtrage doit :

• Remplacer les caractères spéciaux par leurs entités HTML correspondantes
• Supprimer toutes les balises HTML (dont <script>)

En fait, le deuxième point est inclus dans le premier, puisque les caractères < et > sont spéciaux et peuvent donc être remplacés.

En PHP, pour sécuriser efficacement les entrées utilisateurs contre les XSS, il faut utiliser la fonction htmlentities() en n’oubliant pas de lui passer la constante ENT_QUOTES en deuxième argument afin de considérer les guillemets simples et doubles comme des caractères spéciaux et de les remplacer elles aussi. Un exemple :

<?php
echo htmlentities($_GET['var'], ENT_QUOTES);
?>

Ainsi ce code est sécurisé, contrairement au premier. L’utilisation de cette fonction permet de sécuriser des variables affichées aussi bien entre des balises que dans des valeurs d’attributs de balises, comme c’est le cas dans des champs de formulaires. En effet, comme les caractères <, >, ‘ et  » sont filtrés, il est impossible de s’évader des champs et d’injecter du code JavaScript.

Il s’agit à ma connaissance de la seule protection valable pour sécuriser une variable contre les XSS dans toutes les conditions. L’utilisation d’autres fonction, comme par exemple striptags(), ne suffit pas dans toutes les conditions puisques les guillemets ne sont pas filtrées, laissant la possibilité d’injecter des attributs supportant le JavaScript comme onload, onmouseover, etc.

La XSS, une faille finalement pas si inoffensive que ça…

Pour conclure, j’espère vous avoir convaincu que la faille XSS représente une réelle menace, et qu’il est très important de la prendre au sérieux. Si le filtrage des variables contre les injections SQL commence à rentrer dans les mœurs, on ne peut pas en dire autant pour les XSS. Et pourtant, cette dernière permet dans certains cas de rooter complétement un site…

Mise en évidence de la faille

Supposons que nous disposons d’un serveur Apache local et que nous avons une page index.php très simple comme ceci :

<h1>Bonjour !</h1>

Pour accéder à la page, nous accédons à l’URL http://127.0.0.1/~trance/vuln/ avec un navigateur Web. La requête envoyée est grossièrement la suivante :

GET http://127.0.0.1/~trance/vuln/ HTTP/1.1
Host: 127.0.0.1

La réponse reçue comporte alors le code HTML de la page Web. Jusqu’ici, tout est normal : Apache n’a fait qu’interpréter la requête GET qu’on lui a envoyé. Maintenant, imaginez que nous envoyons une requête mal formée qui n’est pas de type GET, comme :

n1Mp0rTeKwa http://127.0.0.1/~trance/vuln/ HTTP/1.1
Host: 127.0.0.1

Et là, nous constatons qu’Apache ne fait absolument aucune différence entre cette et la requête précédente ! Il n’y a aucune erreur ; il renvoie la même chose. A première vue, cela ne choque pas forcément, mais on s’aperçoit assez vite que l’on peut tirer profit de cette faille pour contourner certaines protections .htaccess.

Contourner le « Limit GET POST »

Dans de nombreux cas, un webmaster peut souhaiter restreindre l’accès à un fichier ou à un dossier sur son site Web. Pour cela, il place des fichiers .htaccess. Ces fichiers modifient localement la configuration d’Apache et utilisent une certaine syntaxe qui permet de faire des choses assez puissantes. La description de cette syntaxe est connue, et beaucoup de sites Web l’illustrent. Certains proposent une solution simple pour protéger l’accès à un fichier par un mot de passe. Il suffit, selon eux, de créer un .htaccess selon ce modèle :

<Files fichierAProteger.php>

AuthUserFile /chemin/vers/.htpasswd
AuthName "Zone à accès restreint"
AuthType Basic
    <Limit GET POST>
    require valid-user
    </Limit>
</Files>

Ce fichier permet d’indiquer à Apache de refuser toute requête POST ou GET si l’utilisateur n’est pas identifié avec un login et un mot de passe apparaissant dans le fichier .htpasswd correspondant. En fait, peu importe qu’il y ait de .htpasswd ; la faille ne se situe pas à ce niveau.

Souvenez-vous de ce que nous avons vu plus haut. Nous avons vu qu’Apache interprétait toutes les requêtes qu’il ne comprenait pas comme des requêtes GET. Ainsi, nous pouvons utiliser cela à notre avantage pour accéder à la page protégée sans s’authentifier !

Exemple : imaginons que nous avons un .htaccess rudimentaire de ce type dans le même dossier :

<Limit GET POST>
Deny from all
</Limit>

Logiquement, ce fichier est censé interdire tout accès aux pages du dossier. Le hic, c’est que seules les requêtes GET ou POST sont concernées… Tentez d’accéder à la page avec le navigateur : vous obtenez une erreur 403, puisque votre navigateur envoie implicitement un GET. Maintenant, envoyez une requête incorrecte avec un outil comme Netcat :

n1Mp0rTeKwa  http://127.0.0.1/~trance/vuln/ HTTP/1.1

Host: 127.0.0.1

Et vous obtiendrez la réponse suivante :

<h1>Bonjour !</h1>

Voila donc comment contourner la protection… Simple, n’est-ce pas ? Le pire, dans tout cela, c’est que la majorité des webmasters protègent leurs sites de cette façon. Et j’en faisais partie, jusqu’à ce qu’on me le signale

Correction

La correction est ultra-simple : n’utilisez pas l’instruction « limit » quand vous voulez restreindre l’accès à un fichier ou dossier ! Bannissez les lignes « <Limit GET POST> » et « </Limit> » de vos fichiers .htaccess et vous éviterez ce genre de problèmes.

D’ailleurs, la documentation d’Apache précise bien qu’en général, il ne faut pas utiliser <Limit> lorsque l’on cherche à restreindre l’accès. Je cite : « In the general case, access control directives should not be placed within a <Limit> section. »

Limites

Un petit bémol cependant : pour le moment, nous n’avons pas trouvé le moyen de fausser les requêtes POST en injectant des données. Ainsi, si vous avez des formulaires POST protégés par des .htaccess, ils sont à priori sûrs. Mais je vous conseille quand même de patcher vos .htaccess en retirant les lignes « <Limit> » un peu trop dangereuses…

D’autre part, je suis loin d’être un expert en configuration Apache. Il est possible qu’il existe une option demandant à Apache de refuser systématiquement toutes les requêtes qui ne sont pas comprises. Si vous la connaissez, vous pouvez laissez un commentaire, cela m’intéresse…

Merci encore à Geo pour m’avoir averti de la présence de la faille sur GITS !