IDOR à la prise de contrôle de compte

May 06 2023

Résumé Salut les gens ! À la fin de ma certification OSCP et voulant me replonger dans les primes de bogues, j'ai décidé que je devrais peut-être écrire des blogs basés sur mes découvertes précédentes dans l'espoir que quelqu'un puisse le trouver utile ou en tirer des leçons. Cette description implique de trouver deux vulnérabilités IDOR et de les exploiter pour divulguer des PII entraînant une prise de contrôle de compte.

Résumé

Salut tout le monde! À la fin de ma certification OSCP et voulant me replonger dans les primes de bogues, j'ai décidé que je devrais peut-être écrire des blogs basés sur mes découvertes précédentes dans l'espoir que quelqu'un puisse le trouver utile ou en tirer des leçons.

Cette description implique de trouver deux vulnérabilités IDOR et de les exploiter pour divulguer des PII entraînant une prise de contrôle de compte . La prise de contrôle de compte a été possible grâce à la manière dont l'entreprise a géré le processus de récupération de compte et a en fait été l'une de mes premières découvertes lorsque j'ai commencé les primes de bogues. Le frisson de trouver cela m'a amené à apprendre continuellement des heures supplémentaires.

Quel est cet IDOR dont je parle ?

Insecure Direct Object Referencele plus souvent abrégé en "IDOR" est un type de vulnérabilité qui peut être classé sous access control. IDORsse produisent dans l'application lorsque l'application utilise l'entrée fournie par l'utilisateur pour accéder directement à l'objet sans effectuer de vérification pour voir si l'utilisateur dispose des autorisations d'autorisation appropriées. Le plus souvent associé à une élévation horizontale des privilèges, IDORscela peut avoir des effets délétères sur l'application et sa base d'utilisateurs.

Un excellent exemple de paramètres typiques généralement vulnérables aux IDOR comprend : id= | userID= | messageId=. Comprendre le flux de l'application peut faciliter l'identification de ces types de problèmes.

L'image ci-dessus illustre deux scénarios. Scenario Asur la gauche transmet une application plus sécurisée où users 2 and 3essayez d'accéder à des enregistrements sensibles qui ne leur appartiennent pas, mais cela se traduit par un access denied errorcomme il se doit.

Scenario Bsur la droite, cependant, représente une application vulnérable où l'auteur de la menace peut envoyer des requêtes au serveur Web et récupérer des enregistrements sensibles pour n'importe quel utilisateur donné sans se voir refuser l'accès.

Si vous souhaitez en savoir plus sur IDORs Vickie Li, un article de blog fantastique met en lumière les principes fondamentaux de ce type de vulnérabilité. Vous pouvez le vérifier ici .

L'exemple ci-dessus est simple, mais selon l'application, vous pourrez peut-être exploiter les informations avant de les signaler afin d'augmenter l'impact, ce que je vise toujours à faire.

Maintenant que nous avons une idée de ce qu'ils IDORssont, où ils peuvent être trouvés ainsi que de l'impact, plongeons dans l'une de mes premières découvertes ! :)

Reconnaissance

Bien que le problème ait été résolu, je n'ai pas pu obtenir l'autorisation d'une divulgation publique complète, la cible sera donc appelée : example.com. Comme pour toute cible, en fonction de scope, l'énumération des sous-domaines est essentielle pour étendre la surface d'attaque. Cependant, l'énumération des sous-domaines n'est pas le seul moyen d'étendre la surface d'attaque, car nous pouvons également analyser JavaScriptles fichiers à la recherche d'informations sensibles. Dans ce cas précis, j'ai décidé de commencer par l'utilisation d'un rapide Google Dorkpour voir si je pouvais trouver des sous-domaines intéressants avant d'utiliser des outils automatisés pour plus de résultats.

Google Dork :site:*.example.com

Example.comavait environ 36 sous-domaines, donc un assez bon nombre de sous-domaines avec lesquels travailler !
En les parcourant un par un, j'ai noté deux sous-domaines qui avaient beaucoup de fonctionnalités. J'ai pris environ un jour ou deux pour naviguer dans ces sous-domaines et tester différentes fonctionnalités tout en prenant note mentalement de certaines des fonctionnalités les plus intéressantes spécifiques à cette application. Par exemple, l'application comportait une fonctionnalité permettant de créer des tickets pour recevoir l'assistance du personnel dans différentes catégories telles que « Problèmes de paiement ».

Bogue initial

J'ai décidé de commencer par analyser le fonctionnement du processus d'inscription et de connexion - une fonctionnalité essentielle qui est implémentée dans presque tous les sites Web de nos jours. Le flux d'inscription de l'application Web pourrait être résumé comme suit :

L'utilisateur s'inscrit par e-mail
L'utilisateur est invité à définir a PIN No.et a security questionavant que le processus de création de compte puisse être terminé. Cela ne peut être défini qu'une seule fois et ne peut pas être modifié
L'utilisateur est invité à confirmer l'adresse e-mail avant de pouvoir se connecter

En utilisant account A, j'ai lancé Burpsuiteet commencé à tester la fonctionnalité de billetterie et j'ai créé deux comptes de test suivis de la création de quelques billets sous différentes catégories de support à des fins de test. En regardant le HTTP Historydedans Burpsuite, il y avait des appels intéressants en cours.

Ce qui suit POST requesta été lancé lors de la réponse à un membre du personnel dans un ticket lié à des réclamations de prix :

POST /account/prizes/view/{123456} HTTP/1.1
Host: subdomainX.example.com

grant=w&prizeClaim_id={123456}&action=add_comment&comment_body=Hello+admin+...

Donc, pour conclure les résultats jusqu'à présent:

Lors de l'inscription, chaque utilisateur doit créer un PIN No.etsecurity question
Le site Web permet aux utilisateurs de créer des tickets d'assistance pour obtenir de l'aide
Pour recevoir de l'aide, l'utilisateur doit répondre avec son PIN No.et security question answerpour des questions sensibles telles que la récupération de compte, les réclamations de prix et les problèmes de paiement
IDORune vulnérabilité découverte dans le système de billetterie permet à un adversaire de commenter dans n'importe quel ticket d'assistance sans être le propriétaire du ticket ou un membre du personnel

Donc, si je pouvais publier un commentaire sur n'importe quel ticket sans en être le propriétaire ou sans avoir les privilèges d'un membre du personnel… cela signifiait sûrement que je pouvais aussi lire n'importe quel ticket, n'est-ce pas ?

J'ai capturé la requête GET suivante pour tenter d'afficher un ticket appartenant à account Avia account B, cependant, cela a conduit à l' 403erreur illégale ! Ainsi, je pouvais écrire à n'importe quel ticket d'assistance mais je ne pouvais pas en lire le contenu. À ce stade, je voulais vraiment trouver un moyen possible d'aller plus loin.

GET Endpoint pour lire un ticket sur l'application Web

GET /management/ticket?id=343433 HTTP/1.1
Host: subdomainX.example.com
Upgrade-Insecure-Requests: 1
Connection: close

En essayant d'exploiter la fonctionnalité de billetterie, je suis tombé sur la requête suivante ;

GET /go.php?du=example.com/ HTTP/1.1
Host: subdomainX.example.com
Connection: close
Upgrade-Insecure-Requests: 1
Cookie:

Fuite du contenu du ticket via l'API dans l'application IOS

Lors de la reconnaissance initiale, j'avais remarqué que certaines APIdemandes étaient envoyées lors de la récupération des informations de profil. De plus, la cible avait également une mobile appportée. Il était fort probable que bien que la lecture des tickets d'autres utilisateurs sur l'application Web elle-même ne soit pas possible, cela pourrait être réalisable via l'application mobile car elle pourrait utiliser une application différente de API version/endpointcelle de l'application Web.

En lançant Burpsuiteet en naviguant vers la session de ticket dans l'application IOS, je suis arrivé au point de terminaison suivant :

GET /api/v3/tickets/123456/posts HTTP/1.1
Host: x-api.example.com

Alors maintenant, j'avais trouvé deux bogues - il était possible d'écrire dans n'importe quel ticket ET de voir le contenu de n'importe quel ticket appartenant à un autre utilisateur.

Escalade Ticket Lire IDOR > Prise de contrôle de compte

À ce stade, j'avais à peu près tous les éléments nécessaires pour réaliser une prise de contrôle de compte. Comme il était possible de lire n'importe quel ticket, la prise de contrôle du compte utilisateur pouvait être effectuée via les étapes suivantes :

Visitez le /api/v1/support-tickets/234567/postspoint de terminaison et envoyez-le à intruderpour Burpsuiteénumérer autant de tickets que possible
Greppour des mots-clés tels que Pin Numberou Security Questionà partir des réponses
Créez un nouveau compte sur le site et ouvrez un ticket sousaccount recovery
Le membre du personnel affecté vous demandera le nom d'utilisateur du compte que vous souhaitez récupérer ainsi que le security question answeret PIN No., qui pourraient tous être divulgués via le deuxième IDOR trouvé ; entraînant ainsi une prise de contrôle de compte.

Bien que la prise de contrôle de compte ait déjà été réalisée, l'IDOR d'écriture de ticket pourrait également être exploité. Les noms d'utilisateur du personnel étaient précédés du nom de l'entreprise, par exemple example-John. Un adversaire pourrait ;