Fonctionnement XSS basé sur les cookies | Histoire de Bug Bounty à 2300 $

Depuis un certain temps maintenant, je cherche des vulnérabilités sur la plate-forme HackerOne et j'alloue un certain temps en dehors du travail principal pour vérifier mes programmes préférés et nouveaux. D'innombrables fois je suis tombé sur une vulnérabilité XSS basée sur les cookies, qui deviendra le personnage principal de cet article. Ce type de vulnérabilité se produit lorsque la valeur du paramètre cookie est reflétée sur la page. Par défaut, ils sont considérés comme auto-XSS à moins que nous ne prouvions à leur tour leur danger. En fait, aujourd'hui, je vais vous dire comment exploiter les vulnérabilités XSS basées sur les cookies, et je vais également donner un exemple de test d'une entreprise dont j'ai reçu 7300 $ au total pour l'étude.

Afin d'exécuter javascript du côté utilisateur, vous devez trouver un moyen de définir un cookie et, si nécessaire, d'attirer la victime sur une page où, à son tour, le cookie est intégré. Façons possibles d'exploiter ce bogue:

⠀ 1. Injection CRLF. Cette vulnérabilité se produit en l'absence de vérification et de blocage appropriés des caractères de saut de ligne. Nous pouvons implémenter l'en-tête Set-cookie en réponse avec le nom souhaité ainsi que la valeur du cookie et le définir dans le navigateur. Exemple réel: injection CRLF glissante sur twitter.com dans une redirection, - https://twitter.com/login?redirect_after_login=/jjjkkk 嘍 嘍 Set-Cookie: jjjjj = a; domain = twitter.com



Les rapports sur ce type de vulnérabilité peuvent être lus sur HackerOne hackerone.com/hacktivity?order_direction=DESC&order_field=popular&filter=type%3Apublic&querystring=crlf%20injection

2. Vulnérabilité XSS sur le sous-domaine. XSS doit être accessible au public et situé sur le caractère générique * .vulnerabledomain.com. Pour de nombreux programmes de primes de bogues, les sous-domaines sont hors de portée, c'est-à-dire que, dans la plupart des cas, les bogues ne sont pas du tout acceptés ou sont reçus avec la marque «non éligible à la prime». Dans de tels cas, vous ne devez pas reculer, mais pour vous connecter avec XSS basé sur les cookies, vous pouvez investir votre temps dans la recherche de XSS afin d'obtenir une récompense. Si XSS est détecté, nous pouvons définir ou supprimer le cookie à l'aide de la fonction document.cookie.

Amélioration de l'impact: la victime fait souvent plus confiance au domaine principal de vulnéraabledomain.com qu'à, par exemple, jira.vulnerabledomain.com, et même à l'URL /plugins/servlet/oauth/users/icon-uri?consumerUri=https://maliciousdomain.com . Il est plus probable qu'il passe au domaine principal qu'au sous-domaine si ce sous-domaine n'est pas associé à un compte personnel ou à une autorisation. Sur la base de ce qui précède, nous pouvons utiliser la fonctionnalité de redirection sur site pour rediriger vers le sous-domaine vulnéraabledomain.com/login?redirectUrl=https: //jira.vulnerabledomain.com/path pour un meilleur effet.

Si la victime a une session active, la redirection sera automatique, sinon, une autorisation est nécessaire. Lorsque l'utilisateur clique sur un tel lien, le cookie sera également installé à partir du sous-domaine sur lequel Reflected XSS est présent, il peut être envoyé plus en amont - vers la page XSS basée sur les cookies, où l'exploit peut fonctionner, qui, à son tour, capturera la valeur CSRF du jeton et complétez la demande de changement d'adresse e-mail. Ainsi, une combinaison de deux vulnérabilités XSS peut conduire à une prise de contrôle de compte s'il n'y a pas de problèmes associés, comme une confirmation supplémentaire du changement du mot de passe ou du code de messagerie de l'ancienne boîte aux lettres.

3. Détection des fichiers de test qui permettent de définir des cookies. Il suffit de découvrir l'outil de détection de contenu (dirb, dirserach, etc.), de commencer à creuser, et si les développeurs ont oublié d'effectuer le nettoyage, vous pouvez tomber sur de tels fichiers.

Récemment, j'ai trouvé une page html de servlet de test sur laquelle il était possible d'installer un cookie avec un nom et une valeur arbitraires. La protection sur la demande POST, bien sûr, était absente, donc si la victime visitait l'exploit CSRF (ou vous pouvez changer le POST en GET), il serait possible d'installer un cookie dans son navigateur.



Ce bug a été qualifié de sous-alternative à l'injection CRLF, corrigé en supprimant / examples / et payé 150 $ comme pour un bug de faible gravité. Bien que le trieur h1 ait fourni un support moyen, les développeurs étaient toujours enclins à croire qu'il s'agissait d'une gravité faible.



4. Man in the middle attack (MITM). Cette méthode ne peut être appliquée que s'il n'y a pas d'indicateur sécurisé sur le cookie. Si vous ne savez pas de quel type de drapeau il s'agit ou si vous souhaitez simplement vous rafraîchir la mémoire, je vous conseille de regarder la présentation sur la sécurité des cookies de OWASP London 2017 www.owasp.org/images/a/a0/OWASPLondon20171130_Cookie_Security_Myths_Misconceptions_David_Johansson.pdf .

Pour une attaque réussie, il est nécessaire que la victime se trouve dans le réseau de l'attaquant ou que la résolution DNS puisse être affectée. Afin de vérifier la vulnérabilité, il est nécessaire:

1) hébergez le fichier index.php avec le contenu suivant:

<?php if ($_SERVER['HTTP_HOST'] == 'non-existed-subdomain.vulnerabledomain.com') { setrawcookie("VID",'\'+alert(123123123)+\'', time()+36000, "/", ".vulnerabledomain.com",0,1); } ?> 

2) Ajoutez la ligne suivante à votre fichier / etc / hosts /: 127.0.0.1 nonexisting-subdomain.vulnerabledomain.com

3) Rendez-vous sur sous-domaine non-existant.vulnerabledomain.com et ensuite ouvrez la page sur laquelle le cookie est reflété.

Https://hackerone.com/reports/312548 est un excellent exemple d'exploitation MITM sur e.mail.ru, comme vous pouvez le voir, MITM était suffisant pour prouver un petit danger de vulnérabilité, mais le prix ne correspondait pas au niveau de Stored XSS, car il n'était affiché que Mode de fonctionnement "local", c'est-à-dire non "à l'état sauvage". Si le chercheur passait un peu de temps à chercher des injections XSS ou CRLF (qui sont innombrables) situées sur * .mail.ru, la récompense pourrait être légèrement augmentée.

Mais tous les programmes hackerone n'acceptent pas XSS basé sur les cookies via MITM. Si les exclusions de portée indiquent «Self XSS», cette opération peut être considérée comme Self XSS et définie comme informative ou n / a, ce qui n'est pas toujours agréable. Je vais maintenant parler d'un incident similaire qui m'est arrivé lors de la prochaine chasse sur la plate-forme.

En testant le site, j'ai soudainement vu que la valeur des cookies expurgés se reflétait dans l'un des sous-répertoires du site. La première chose que j'ai faite a été de vérifier l'affichage des caractères "/ <>. Il s'est avéré que seuls les caractères <> ont été filtrés, et cela nous dit que nous ne pouvons pas aller au-delà, mais il devient également clair que les autres caractères ne sont pas filtrés Sans réfléchir à deux fois, nous implémentons '-alert (document.domain) -' et js est exécuté.

Étant donné que les développeurs n'ont pas donné au cookie l'indicateur sécurisé, dans ce cas, la méthode MITM fonctionne. Il a été décidé d'envoyer un rapport au programme avec l'impact suivant:



Le personnel de HackerOne (triager) a clairement indiqué qu'il s'agissait d'un auto-XSS et je dois faire plus d'efforts:



Après cela, j'ai commencé à surfer sur le site et à essayer de trouver une injection CRLF ou XSS pour prouver le danger.

⠀ J'ai dû étendre la liste des sous-domaines à l'aide d'un grand dictionnaire, en grattant les sous-domaines avec des certificats SSL et en utilisant d'autres astuces. Le résultat ne s'est pas fait attendre, car la plupart des outils que j'utilise avec VPS. De temps en temps, d'autres bogues ont également été détectés en cours de route, ce que j'ai signalé, ce qui rendait la portée hors de la portée, si nécessaire. J'ai rencontré de nombreuses redirections ouvertes et même un bogue de contrôle d'accès incorrect pour 5 000 $, mais je ne pouvais toujours pas détecter les vulnérabilités nécessaires pour l'ensemble. Le bogue mentionné ci-dessus est assez intéressant et dangereux, l'ensemble du sous-domaine a été mis hors ligne immédiatement après le rapport, peut-être qu'à l'avenir j'ouvrirai le rapport sur hackerone.com/w2w, si le programme devient public.

Une semaine plus tard, les résultats du script de détection de contenu ont été vérifiés, où le point de terminaison / vérification a été trouvé, auquel je n'accordais pas d'importance particulière au début, mais quand même j'y ai placé le script - le sous-répertoire / verification / login a été trouvé. Après la transition, la page /verification/login/?redirect_uri=https://vulnerabledomain.com s'affiche, qui redirige vers la valeur redirect_uri après la connexion ou redirige immédiatement s'il y a une session. Après avoir volé vers l'intrus, un contournement de la protection de redirection ouverte a été découvert - vulnéraabledomain.com@anotherdomain.com. J'ai essayé de dérouler le bogue vers XSS - la charge utile javascript: alert (1) a échoué, javascript: alert (1) // aussi. Mais la charge utile javascript: // https: //vulnerablesite.com/%250A1? Alert (1): 0 tir, car en raison de la présence de vulnéraablesite.com , le paramètre a réussi la validation de la liste blanche.



Après avoir frénétiquement conduit la souris à travers la fenêtre de notification (je le fais toujours), je me suis immédiatement mis à travailler sur mon XSS basé sur les cookies. Utilisation de javascript: https: //vulnerabledomain.com/%0A1? Document% 2ecookie% 20% 3d% 20% 27SID% 3d137gf6g67f76fg6766123% 5c% 27-alert% 28document% 2edomain% 29-% 5c% 27% 3b% 20expires% 3dFri% 2c% 203% 20Aug% 202019% 2020% 3a47% 3a11% 20UTC% 3b% 20path% 3d% 2f% 3b% 20domain% 3d% 2evulnerabledomain% 2ecom% 3b% 27% 3a0 Le cookie s'est assis avec succès sur * .vulnerabledomain.com . Après être allé sur la page avec le cookie, l'alerte précieuse a décollé! Double XSS, bravo! :) J'ai complété le rapport et attendu une réponse.



Le même jour, "Nice catch" a volé depuis la triadger (si vous pouvez l'appeler ainsi), et une prime a été payée. Que Dieu bénisse les entreprises qui paient le triage!

Pour XSS basé sur DOM, avec lequel j'ai installé le cookie, la prime est également arrivée.

Résultats des tests

1000 $ + 1000 $ + 200 $ (OU) + 100 $ (OU) = 2300 $

Ce programme fonctionne depuis plus d'un an, mais en moins d'un mois, j'ai pu prendre la première place et aller un peu avec les tests - j'ai essayé de mettre en phase la majorité des points de terminaison, d'évaluer leur réaction, de comprendre le fonctionnement du site et même de tester l'application de bureau. Ce programme de bug bug est devenu l'un des plus appréciés sur HackerOne. J'espère que vous aussi, un jour, retrouverez le même! :)



En outre, c'est ce programme qui m'a donné un nouvel élan (mail.ru - le premier), - avec lui, j'ai atteint 2500 points de réputation (bonjour sweat à capuche) et j'ai atteint la 36e place dans le classement pour la réputation en 90 jours, ce qui devrait donner de nouvelles chances . Bien qu'il semble que les greffes arrivent indépendamment de leur présence dans le classement, j'annule souvent les anciennes greffes et j'attends les nouvelles en ligne.

Bref bref

• Les XSS basés sur les cookies sont entièrement exploitables. Si vous essayez de creuser un peu plus profondément, vous pouvez obtenir une prime au lieu de n / a, détruisant le signal et la réputation de -5.
• Si le programme est ancien, cela ne signifie pas qu'il n'y aura aucune vulnérabilité. Si le fruit est accroché à l'arbre pendant une longue période, les fruits à faible pendaison seront cueillis et pris immédiatement (rachats de sous-domaines, etc.). D'autres fruits continuent de pendre, mais plus haut. Pour les obtenir, vous devez faire des efforts.
• Parfois, il vaut mieux se concentrer sur un programme pendant une longue période, trouver autant de vulnérabilités que possible et le surveiller. Il vaut mieux trouver le programme que vous préférez et le casser.
• La persévérance et le désir de comprendre le fonctionnement d'une application Web, ainsi que certaines fonctionnalités et leur interaction les unes avec les autres, sont la clé pour réussir la recherche de vulnérabilités dans une prime de bogue.

Si vous souhaitez vous tenir au courant de mes derniers articles et nouvelles, je vous conseille de vous abonner à la chaîne télégramme / twitter, dont les liens se trouvent ci-dessous.