En mars 2020, la pandémie a commencé, j'ai donc eu beaucoup de temps libre. Ils devaient être gérés avec sagesse et j'ai décidé d'obtenir la certification OSWE. Après avoir réussi l'examen le 8 août, j'ai pris quelques semaines de congé, puis à la mi-septembre, je me suis dit: «Tu sais quoi? Mon nom n'apparaissait pas dans le Temple de la renommée de Facebook en 2020, bien que cela y arrive chaque année. Il est temps de résoudre ce problème! ».
Je n'ai jamais trouvé de vulnérabilité sur l'un des sous-domaines Facebook, j'ai donc étudié les articles et trouvé un article sur le sous-domaine Facebook qui a attiré mon attention. C'est un excellent article, je recommande de le lire: [Le bogue de conversion HTML en PDF conduit à RCE sur le serveur Facebook] .
Après avoir lu cet article, j'ai réalisé que de nombreuses vulnérabilités peuvent être trouvées dans une application Web aussi énorme.
Mon objectif principal était
https://legal.tapprd.thefacebook.com
, j'avais l'intention d'implémenter RCE (Remote Code Execution) ou quelque chose de similaire.
J'ai exécuté des outils de fuzzing pour découvrir tous les points de terminaison de cette application Web, j'ai fait une sieste de deux heures et j'ai regardé un film. Puis je suis retourné à mon ordinateur et j'ai trouvé de bons résultats.
403:
/tapprd/
/tapprd/content/
/tapprd/services/
/tapprd/Content/
/tapprd/api/
/tapprd/Services/
/tapprd/temp/
/tapprd/logs/
/tapprd/logs/portal/
/tapprd/logs/api/
/tapprd/certificates/
/tapprd/logs/auth/
/tapprd/logs/Portal/
/tapprd/API/
/tapprd/webroot/
/tapprd/logs/API/
/tapprd/certificates/sso/
/tapprd/callback/
/tapprd/logs/callback/
/tapprd/Webroot/
/tapprd/certificates/dkim/
/tapprd/SERVICES/
Je pense que ce résultat est bien suffisant pour confirmer ma théorie sur l'énormité de cette application. Ensuite, j'ai commencé à lire les fichiers Javascript, pour comprendre comment le site Web, quelles méthodes il utilise, etc ...
J'ai vu un moyen de contourner la redirection vers le Login SSO sur
https://legal.tapprd.thefacebook.com/tapprd/portal/authentication/login
et après avoir analysé la page de connexion, j'ai trouvé ce point de terminaison:
/tapprd/auth/identity/user/forgotpassword
Après fuzzing par point de terminaison de l'utilisateur, j'ai identifié un autre point de terminaison en
/savepassword
attente d'une requête POST, Après avoir examiné les fichiers Javascript, j'ai compris comment la page fonctionne, que le jeton généré et le jeton xsrf sont nécessaires, etc. Au début, j'ai pensé que cela valait la peine d'essayer pour vérifier, vous pouvez les modifier manuellement avec l'aide
burp suite
, mais vous avez une erreur échec de l'opération .
J'ai pensé que c'était peut-être la mauvaise adresse e-mail ou quelque chose de similaire. Essayons de récupérer l'e-mail de l'administrateur. J'ai commencé à noter des adresses e-mail arbitraires, à faire une liste de mots, puis à utiliser burp pour tester ce qui s'était passé.
Quand je suis revenu quelques heures plus tard, j'ai vu les mêmes erreurs, plus un autre résultat. C'était une redirection 302 vers la page de connexion. Wow, putain ça a marché!
Laissez-moi vous expliquer ce qui s'est passé ici: j'ai envoyé des demandes aléatoires avec un jeton CSRF en utilisant un pirate et des adresses e-mail aléatoires avec un nouveau mot de passe de point de terminaison
/savepassword
, et l'un des résultats était une redirection 302.
Rediriger
Maintenant, je pouvais aller à la page de connexion, entrer mon email et un nouveau mot de passe - BOOM, la connexion à l'application a réussi et j'ai eu accès au panneau d'administration!
J'ai lu le rapport d'un pirate informatique qui a trouvé un précédent RCE implémenté avec PDF, la société lui a donné une récompense de seulement 1000 $. J'ai donc décidé: ok, il faut faire bonne impression et écrire l'exploit parfait pour obtenir un impact élevé.
J'ai rapidement écrit un simple script Python pour exploiter cette vulnérabilité: vous entrez une adresse email et un nouveau mot de passe, et le script change le mot de passe.
L'impact était si grand ici parce que les employés de Facebook se sont connectés avec leurs comptes professionnels. Autrement dit, ils ont utilisé leurs propres jetons d'accès au compte Facebook, et il est probable que si un autre attaquant voulait utiliser cet exploit, cela lui donnerait accès aux comptes de certains employés de Facebook.Ensuite,
j'ai signalé la vulnérabilité et mon rapport a été examiné. .
J'ai reçu un prix de 7500 $ le 2 octobre
J'ai tellement aimé l'exploit de cette vulnérabilité, et j'ai décidé que ce n'était pas suffisant, le script est trop faible! Cela vaut la peine de continuer à creuser plus profondément.
J'ai donc trouvé deux autres vulnérabilités, dont je parlerai dans la deuxième partie de l'article.
Deuxième partie
Dans la première partie, j'ai découvert la possibilité de détourner un compte avec une API non sécurisée, ce qui m'a permis de changer le mot de passe de n'importe quel compte administrateur sans intervention de l'utilisateur, pour lequel le service de sécurité de Facebook m'a payé 7500 $ . Dans la deuxième partie, j'ai découvert un moyen de détourner un compte en utilisant la manipulation de cookies. En le combinant avec le SSRF interne , j'ai reçu une récompense xxxxx $ . Oui, une somme à cinq chiffres ... Eh bien, commençons.
Avant sa publication, l'article a été vérifié par plusieurs parties, et j'ai dû obtenir une autorisation écrite pour cela, de sorte que certains noms et informations pouvaient être modifiés à la demande de Facebook et de ses partenaires.
Lorsque j'ai découvert la vulnérabilité dans la première partie de l'article, Facebook l'a corrigée le lendemain de la réception du rapport. Ensuite, j'ai commencé à étudier l'histoire
burp suite
pour comprendre comment tout cela fonctionne.
Comme vous pouvez le voir sur la capture d'écran (numéro 1 sur fond bleu), ASPXAUTH est utilisé comme cookie . Idéalement!
Voyez-vous où je veux en venir? ASPXAUTH a 80% de chances d'être vulnérable, mais cela nécessite les informations suivantes:
validationKey
(): , .decryptionMethod
(): ( «AES»).decryptionIV
(): ( — , ).decryptionKey
(): , .
Vous pouvez en savoir plus ici: Classe MachineKey .
Je n'ai aucune information sur aucun des points, alors pourquoi ai-je supposé qu'il y avait une vulnérabilité ici?
En fait, je ne sais pas cela, mais la plupart des applications ASPXAUTH dans les cookies cryptés avec des clés de cryptage n'utilisent généralement que le courrier électronique ou le temps d'expiration des utilisateurs et des cookies. J'ai utilisé cette méthode à plusieurs reprises dans les programmes de primes d'autres sites Web et cela a fonctionné.
J'avais besoin de trouver un moyen de contourner ce système, du moins pas une tentative de torture. Je suis allé sur Google et j'ai cherché d'autres sites Web qui utilisent la même application. J'étais censé avoir de la chance et trouver un site Web utilisant la même application et les mêmes clés de cryptage, et choisir simplement le nom d'utilisateur d'administrateur correct.
J'ai trouvé un autre site Web utilisant la même application, l'inscription était active, alors je me suis connecté avec le nom d'utilisateur de l'administrateur Facebook, j'ai intercepté la demande, j'ai pris ASPXAUTH et l' ai remplacé par un ASPXAUTH Facebook expiré . Devinez ce qui s'est passé?
J'ai déjà manqué ce panneau, mais j'y suis finalement revenu. Maintenant, parlons un peu de la surveillance ASP.net que la plupart des développeurs devraient prendre en compte lors de la création d'applications pour les protéger:
- ASPXAUTH doit être stocké dans la base de données et l'application doit le valider pour l'exactitude.
- À titre de vérification supplémentaire, ASPXAUTH doit parfois contenir plus que le nom d'utilisateur.
- Chaque site doit avoir des clés de chiffrement et de déchiffrement uniques (les clés par défaut doivent être modifiées).
Conclusion 1 : je pourrais me connecter à n'importe quel compte administrateur, ne connaissant que son nom d'utilisateur; Je considère que la complexité de cette vulnérabilité est très faible et son impact élevé . Si je signale seulement cette vulnérabilité, je ne toucherai que 7 500 $ , comme dans la première partie, mais j'en voulais plus.
Dans le panneau, j'ai remarqué quelque chose de curieux, à savoir la possibilité de créer des formulaires et une autre option - le déclencheur API. J'ai suspecté quelque chose, il y a probablement une possibilité de SSRF illimité (Server-Side Request Forgery). Par conséquent, j'ai écrit une lettre au service de sécurité de Facebook, disant qu'il y avait près de cent pour cent de la vulnérabilité SSRF critique dans l'application, demandant la permission de la tester. La réponse m'est venue:
À ce moment-là, je discutais encore du rapport de la première partie (détournement de compte) avec eux, car j'ai signalé ces vulnérabilités une semaine après la première. Comme vous pouvez le voir, le service de sécurité de Facebook a continué à croire que je réclamais un autre contournement d'authentification et SSRF, même après avoir expliqué les vulnérabilités avec des preuves. À en juger par cela, j'ai été autorisé à tester SSRF.
Au bout d'un moment, j'ai écrit un petit script et l'ai téléchargé dans leur éditeur. Le script m'a permis d'envoyer n'importe quelle requête avec n'importe quelle donnée (GET, POST, PUT, PATCH, HEAD, OPTIONS) à n'importe quelle URL, à la fois interne et externe.
Depuis le backend du script, je pourrais changer la méthode de requête et les données envoyées, etc.
À ce stade, je pourrais étendre cette vulnérabilité à RCE, peut-être à LFI (Inclusion de fichiers locaux, ajout de fichiers locaux), si j'allais un peu plus loin ( je n'en suis pas tout à fait sûr, plus tard j'ai demandé à Facebook l'autorisation de faire de l'ingénierie inverse la demande, mais ils ont refusé et ont dit qu’ils ne pensaient pas que je pourrais étendre l’attaque ).
Ensuite, j'ai essayé d'attaquer Facebook avec un script canari. Devinez ce qui s'est encore passé?
J'ai reçu mon jeton canari. Et après? J'ai besoin d'écrire un nouveau rapport avec tous les détails, y compris les scripts et PoC (preuve de concept), comme on m'a dit plus haut.
Conclusion 2: En écrivant un script pour envoyer des requêtes arbitraires, je pourrais obtenir le SSRF interne et donner accès au réseau Facebook interne. Je considère que la difficulté de cette attaque est faible et que l’impact est critique .
Impact SSRF:
SSRF- Facebook, , -, . SSRF .
SSRF-, , , , , .
Pour en savoir plus sur les vulnérabilités SSRF, consultez l'article portswigger .
Conclusion finale: j'ai enchaîné les deux vulnérabilités au point où j'ai eu accès à l' intranet Facebook ( SSRF ), en utilisant la prise de contrôle de compte pour accéder à mon script téléchargé dans l'application, en envoyant les requêtes arbitraires que je souhaitais.
Parlons de ce que je peux réaliser avec la chaîne de vulnérabilités que j'ai découverte:
- Je peux accéder au compte de n'importe quel employé Facebook dans le tableau de bord du service juridique.
- Il n'est pas nécessaire d'expliquer l'importance des informations qu'un attaquant peut obtenir après s'être connecté.
- Je pourrais utiliser SSRF pour accéder à l'intranet Facebook (intern.our.facebook.com).
- Je pense qu'avec un peu plus d'effort, je pourrais étendre cette vulnérabilité et l'utiliser pour scanner le réseau interne / les serveurs.
Nous savons tous à quel point le SSRF est critique , surtout s'il n'est pas limité en fréquence. Je peux facilement changer le type de contenu et les méthodes de demande. Selon les Facebook guides de paiement, cette vulnérabilité devrait être récompensée par 40 000 $ dans un $ 5000 de bonus si je peux changer le type de contenu de la demande et la méthode de demande.
Après une longue attente, j'ai reçu ce message de Facebook:
Reçu un prix de 40 000 $ de Facebook plus un bonus de 2 000 $ (contre 7 000 $ prévu ).
Je leur ai posé une question sur les raisons pour lesquelles je n'ai pas reçu le bonus de contrôle total ( 5000 $ ) et j'ai reçu cette réponse:
Au total, avec la première vulnérabilité, cela s'élevait à 54 800 dollars .
J'ai signalé cette vulnérabilité quelques jours après la première partie du rapport de vulnérabilité.
Chronologie des rapports:
- Mercredi 9 septembre 2020 - Rapport de vulnérabilité envoyé.
- Lundi 26 octobre 2020 - Facebook m'a demandé d'ouvrir un nouveau rapport. ~ Mesures correctives prises.
- Lundi 26 octobre 2020 - rapport révisé.
- Jeudi 25 février 2021 - Problème résolu et prime payée. Environ six mois, ouais .
- Vendredi 5 mars 2021 - Prime de 5300 $ payée.
Je veux donner de précieux conseils aux chasseurs d'insectes. Lorsque vous voyez ASPXAUTH, essayez d'obtenir des cookies d'un autre site Web en utilisant la même application et testez la même méthode que la mienne:
- Créez de nouveaux cookies ASPXAUTH à partir d'un autre site Web.
- Vérifiez si les cookies fonctionneront sur le site Web sous enquête.
J'ai aimé le processus, mais attendre six mois et clôturer les rapports pour des raisons irrationnelles était ennuyeux. Je suis reconnaissant, mais j'ai dû travailler dur et ce n'est pas le seul SSRF que j'ai trouvé. En fait, j'en ai trouvé plus curieux, mais Facebook a classé les rapports comme "informatifs" car la société a signé un accord avec le fournisseur qu'elle a conclu quelques semaines après avoir examiné les rapports. En fin de compte, ce n'est pas mon problème, donc cette expérience n'est pas agréable.
En fin de compte, je tiens à m'excuser si quelque chose n'était pas clair. Il a fallu un certain temps pour publier la deuxième partie - comme mentionné ci-dessus, j'attendais l'autorisation écrite et la révision du rapport. Par conséquent, de nombreux aspects ont été supprimés ou censurés pour préserver la confidentialité des tiers.