Im März 2020 begann die Pandemie, so dass ich viel Freizeit hatte. Sie mussten mit Bedacht verwaltet werden, und ich entschied mich für die OSWE-Zertifizierung. Nachdem ich die Prüfung am 8. August bestanden hatte, nahm ich mir ein paar Wochen frei und sagte mir dann Mitte September: „Weißt du was? Mein Name erschien 2020 nicht in der Facebook Hall of Fame, obwohl er dort jährlich stattfindet. Es ist Zeit, dieses Problem zu lösen! “.
Ich habe noch nie eine Sicherheitslücke in einer der Facebook-Subdomains gefunden, daher habe ich die Artikel studiert und einen Beitrag über die Facebook-Subdomain gefunden, der meine Aufmerksamkeit auf sich gezogen hat. Dies ist ein großartiger Beitrag, ich empfehle ihn zu lesen: [Fehler bei der Konvertierung von HTML in PDF führt zu RCE auf dem Facebook-Server] .
Nachdem ich diesen Beitrag gelesen hatte, stellte ich fest, dass viele Schwachstellen in einer so großen Webanwendung zu finden sind.
Mein Hauptziel war
https://legal.tapprd.thefacebook.com
, RCE (Remote Code Execution) oder ähnliches zu implementieren.
Ich führte Fuzzing-Tools aus, um alle Endpunkte dieser Webanwendung herauszufinden, machte ein zweistündiges Nickerchen und schaute mir einen Film an. Dann ging ich zurück zu meinem Computer und fand gute Ergebnisse.
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/
Ich denke, dieses Ergebnis reicht völlig aus, um meine Theorie über die Größe dieser Anwendung zu bestätigen. Dann fing ich an, Dateien zu lesen, die Javascript ist, um zu verstehen, wie die Website, welche Methoden er verwendet usw.
Ich sah eine Möglichkeit, die Umleitung zum Anmelde-SSO zu umgehen,
https://legal.tapprd.thefacebook.com/tapprd/portal/authentication/login
und nach der Analyse der Anmeldeseite fand ich diesen Endpunkt:
/tapprd/auth/identity/user/forgotpassword
Nachher Als ich nach Endpunkt des Benutzers fuzzelte, identifizierte ich einen anderen Endpunkt, der
/savepassword
auf eine POST-Anfrage wartete. Nachdem ich die Javascript-Dateien untersucht hatte, fand ich heraus, wie die Seite funktioniert, dass das generierte Token und das xsrf-Token benötigt werden usw. Zuerst dachte ich, dass es sich lohnt, es zu versuchen Um zu überprüfen, können Sie sie mit der Hilfe manuell ändern
burp suite
, haben aber einen Fehler erhalten Ausfall der Operation .
Ich dachte, es könnte die falsche E-Mail-Adresse oder ähnliches sein. Versuchen wir, die E-Mail des Administrators abzurufen. Ich fing an, beliebige E-Mail-Adressen aufzuschreiben, eine Liste von Wörtern zu erstellen und dann mit Rülpsen zu testen, was passiert ist.
Als ich ein paar Stunden später zurückkam, sah ich dieselben Fehler und ein weiteres Ergebnis. Es war eine 302-Weiterleitung zur Anmeldeseite. Wow, verdammt, es hat funktioniert!
Lassen Sie mich erklären, was hier passiert ist: Ich habe zufällige Anfragen mit einem CSRF-Token unter Verwendung eines Crackers und zufälliger E-Mail-Adressen mit einem neuen Endpunktkennwort gesendet
/savepassword
, und eines der Ergebnisse war eine 302-Weiterleitung.
Weiterleiten
Jetzt konnte ich zur Anmeldeseite gehen, meine E-Mail-Adresse und ein neues Passwort eingeben - BOOM, die Anmeldung bei der Anwendung war erfolgreich und ich hatte Zugriff auf das Admin-Panel!
Ich habe den Bericht eines Hackers gelesen, der festgestellt hat, dass ein früherer RCE mit PDF implementiert wurde. Das Unternehmen hat ihm eine Belohnung von nur 1000 US-Dollar gegeben. Also entschied ich mich: Ok, du musst einen guten Eindruck hinterlassen und den perfekten Exploit schreiben, um eine hohe Wirkung zu erzielen.
Ich habe schnell ein einfaches Python-Skript geschrieben, um diese Sicherheitsanfälligkeit auszunutzen: Sie geben eine E-Mail-Adresse und ein neues Kennwort ein, und das Skript ändert das Kennwort.
Die Wirkung war hier so groß, weil sich Facebook-Mitarbeiter mit ihren Arbeitskonten angemeldet haben. Das heißt, sie haben ihre eigenen Zugriffstoken für Facebook-Konten verwendet. Wenn ein anderer Angreifer diesen Exploit verwenden möchte, erhält er wahrscheinlich Zugriff auf die Konten einiger Facebook-Mitarbeiter. Dann habe
ich die Sicherheitsanfälligkeit gemeldet und mein Bericht wurde überprüft .
Am 2. Oktober erhielt ich eine Auszeichnung in Höhe von 7.500 USD
Ich mochte den Exploit für diese Sicherheitsanfälligkeit so sehr und entschied, dass es nicht genug war, das Skript ist zu schwach! Es lohnt sich, weiter tiefer zu graben.
Also habe ich zwei weitere Schwachstellen gefunden, die ich im zweiten Teil des Artikels diskutieren werde.
Zweiter Teil
Im ersten Teil entdeckte ich die Möglichkeit, ein Konto mit einer unsicheren API zu entführen, wodurch ich das Kennwort eines Administratorkontos ohne Benutzereingriff ändern konnte. Die Facebook-Sicherheitsabteilung zahlte mir 7.500 US-Dollar . Im zweiten Teil habe ich einen Weg gefunden, ein Konto mithilfe der Cookie-Manipulation zu entführen. In Kombination mit der internen SSRF erhielt ich eine Belohnung von $ xxxxx . Ja, eine fünfstellige Summe ... Nun, fangen wir an.
Vor der Veröffentlichung wurde der Artikel von mehreren Parteien geprüft, und ich musste eine schriftliche Genehmigung einholen, damit einige der Namen und Informationen auf Anfrage von Facebook und seinen Partnern geändert werden konnten.
Als ich die Sicherheitsanfälligkeit im ersten Teil des Artikels entdeckte, wurde sie am Tag nach Erhalt des Berichts von Facebook behoben. Dann begann ich Geschichte
burp suite
zu studieren, um zu verstehen, wie das alles funktioniert.
Wie Sie auf dem Screenshot sehen können (Nummer 1 auf blauem Hintergrund), wird ASPXAUTH als Cookie verwendet . Im Idealfall!
Sehen Sie, worauf ich hinaus will? ASPXAUTH hat eine 80% ige Chance, anfällig zu sein, dies erfordert jedoch die folgenden Informationen:
validationKey
(): , .decryptionMethod
(): ( «AES»).decryptionIV
(): ( — , ).decryptionKey
(): , .
Mehr dazu lesen Sie hier: MachineKey Class .
Ich habe zu keinem der Punkte Informationen. Warum habe ich dann angenommen, dass hier eine Sicherheitslücke besteht?
Eigentlich weiß ich das nicht, aber die meisten ASPXAUTH- Anwendungen in verschlüsselten Cookies mit Verschlüsselungsschlüsseln verwenden normalerweise nur die Ablaufzeit von E-Mail oder Benutzern und Cookies. Ich habe diese Methode viele Male in den Kopfgeldprogrammen anderer Websites verwendet und sie hat funktioniert.
Ich musste einen Weg finden, um dieses System zu umgehen, zumindest keinen Folterversuch. Ich ging zu Google und suchte nach anderen Websites, die dieselbe Anwendung verwenden. Ich sollte Glück haben und eine Website mit derselben Anwendung und denselben Verschlüsselungsschlüsseln finden und einfach den richtigen Administrator-Benutzernamen auswählen.
Ich habe eine andere Website mit derselben App gefunden, die Registrierung war aktiv, also habe ich mich mit dem Benutzernamen des Facebook-Administrators angemeldet, die Anfrage abgefangen, ASPXAUTH genommen und durch ein abgelaufenes Facebook- ASPXAUTH ersetzt . Rate, was passiert ist?
Ich habe dieses Panel bereits verpasst, bin aber schließlich darauf zurückgekommen. Lassen Sie uns nun ein wenig über das ASP.net-Versehen sprechen, das die meisten Entwickler beim Erstellen von Anwendungen berücksichtigen sollten, um ihre Sicherheit zu gewährleisten:
- ASPXAUTH muss in der Datenbank gespeichert sein und von der Anwendung auf Richtigkeit überprüft werden.
- Als zusätzliche Prüfung sollte ASPXAUTH manchmal mehr als nur den Benutzernamen enthalten.
- Jeder Standort muss über eindeutige Verschlüsselungs- und Entschlüsselungsschlüssel verfügen (die Standardschlüssel müssen geändert werden).
Schlussfolgerung 1 : Ich konnte mich bei jedem Administratorkonto anmelden und nur dessen Benutzernamen kennen. Ich halte die Komplexität dieser Sicherheitsanfälligkeit für sehr gering und ihre Auswirkungen für hoch . Wenn ich diese Sicherheitsanfälligkeit nur melde, erhalte ich wie im ersten Teil nur 7.500 US-Dollar , aber ich wollte mehr.
Im Panel fiel mir etwas Merkwürdiges auf, nämlich die Option zum Erstellen von Formularen und eine weitere Option - der API-Trigger. Ich habe etwas vermutet, höchstwahrscheinlich besteht die Möglichkeit einer unbegrenzten SSRF (Server-Side Request Forgery). Aus diesem Grund schrieb ich einen Brief an die Facebook-Sicherheitsabteilung, in dem ich sagte, dass fast hundert Prozent der kritischen SSRF-Sicherheitslücke in der Anwendung vorhanden sind, und bat um Erlaubnis, sie testen zu dürfen. Die Antwort kam zu mir:
Zu diesem Zeitpunkt diskutierte ich noch mit ihnen über den Bericht aus dem ersten Teil (Kontoentführung), da ich diese Sicherheitslücken eine Woche nach dem ersten gemeldet habe. Wie Sie sehen können, glaubte die Sicherheitsabteilung von Facebook weiterhin, dass ich einen weiteren Authentifizierungsbypass und SSRF beanspruche, selbst nachdem ich die Sicherheitslücken mit Beweisen erklärt hatte. Demnach wurde mir die Erlaubnis gegeben, SSRF zu testen.
Nach einer Weile schrieb ich ein kleines Skript und lud es in ihren Editor hoch. Mit dem Skript konnte ich jede Anfrage mit beliebigen Daten (GET, POST, PUT, PATCH, HEAD, OPTIONS) an eine beliebige interne und externe URL senden.
Im Backend des Skripts konnte ich die Anforderungsmethode und die gesendeten Daten usw. ändern.
Zu diesem Zeitpunkt könnte ich diese Sicherheitsanfälligkeit auf RCE ausweiten, möglicherweise auf LFI (Local File Inclusion, Hinzufügen lokaler Dateien), wenn ich etwas weiter gehe (da bin ich mir nicht ganz sicher, habe ich später Facebook um Erlaubnis zum Reverse Engineering gebeten die Anwendung, aber sie lehnten ab und sagten, sie hätten nicht gedacht, dass ich den Angriff ausweiten könnte ).
Dann habe ich versucht, Facebook mit einem kanarischen Skript anzugreifen. Ratet mal, was wieder passiert ist?
Ich habe meinen Kanarienvogel erhalten. Was weiter? Ich muss einen neuen Bericht mit allen Details schreiben, einschließlich Skripten und PoC (Proof of Concept), wie mir oben gesagt wurde.
Schlussfolgerung 2: Durch das Schreiben eines Skripts zum Senden beliebiger Anfragen konnte ich die interne SSRF abrufen und den Zugriff auf das interne Facebook-Netzwerk ermöglichen. Ich halte die Schwierigkeit dieses Angriffs für gering und die Auswirkungen für kritisch .
Impact SSRF:
SSRF- Facebook, , -, . SSRF .
SSRF-, , , , , .
Weitere Informationen zu SSRF- Schwachstellen finden Sie im Artikel portswigger .
Letzter Hinweis: Ich habe beide Sicherheitslücken bis zu dem Punkt verkettet, an dem ich Zugriff auf das Facebook- Intranet ( SSRF ) hatte. Mithilfe der Kontoübernahme gelangte ich zu meinem hochgeladenen Skript in der Anwendung und sendete die gewünschten Anfragen.
Lassen Sie uns darüber sprechen, was ich mit der von mir entdeckten Schwachstellenkette erreichen kann:
- Ich kann auf jedes Konto eines Facebook-Mitarbeiters im Dashboard der Rechtsabteilung zugreifen.
- Es ist nicht erforderlich zu erklären, wie wichtige Informationen ein Angreifer nach dem Anmelden erhalten kann.
- Ich könnte SSRF verwenden, um auf das Facebook-Intranet (intern.our.facebook.com) zuzugreifen.
- Ich denke, dass ich mit etwas mehr Aufwand diese Sicherheitsanfälligkeit erweitern und zum Scannen des internen Netzwerks / der internen Server verwenden könnte.
Wir alle wissen, wie kritisch SSRF ist , insbesondere wenn es nicht frequenzbegrenzt ist. Ich kann den Inhaltstyp und die Anforderungsmethoden leicht ändern. Laut den Facebook- Zahlungsleitfäden sollte diese Sicherheitsanfälligkeit mit 40.000 US-Dollar in einem Bonus von 5.000 US-Dollar belohnt werden, wenn ich den Inhaltstyp und die Anforderungsmethode der Anfrage ändern kann.
Nach langem Warten erhielt ich folgende Nachricht von Facebook:
Erhielt eine Auszeichnung in Höhe von 40.000 USD von Facebook sowie einen Bonus in Höhe von 2.000 USD (gegenüber den erwarteten 7.000 USD ).
Ich stellte ihnen eine Frage, warum ich den Vollkontrollbonus ( 5.000 USD ) nicht erhalten habe , und erhielt folgende Antwort:
Insgesamt belief sich dies bei der ersten Sicherheitsanfälligkeit auf 54.800 US-Dollar .
Ich habe diese Sicherheitsanfälligkeit einige Tage nach dem ersten Teil des Sicherheitsanfälligkeitsberichts gemeldet.
Chronologie der Berichte:
- Mittwoch, 9. September 2020 - Sicherheitsanfälligkeitsbericht gesendet.
- Montag, 26. Oktober 2020 - Facebook hat mich gebeten, einen neuen Bericht zu eröffnen. ~ Korrekturmaßnahmen ergriffen.
- Montag, 26. Oktober 2020 - Bericht überprüft.
- Donnerstag, 25. Februar 2021 - Problem gelöst und Kopfgeld gezahlt. Ungefähr sechs Monate, ja .
- Freitag, 5. März 2021 - 5.300 $ Bonus ausgezahlt.
Ich möchte Insektenjägern wertvolle Ratschläge geben. Wenn Sie ASPXAUTH sehen, versuchen Sie, Cookies von derselben Website mit derselben Anwendung abzurufen , und testen Sie dieselbe Methode wie meine:
- Erstellen Sie neue ASPXAUTH- Cookies von einer anderen Website.
- Überprüfen Sie, ob Cookies auf der untersuchten Website funktionieren.
Ich mochte den Prozess, aber sechs Monate zu warten und Berichte aus irrationalen Gründen zu schließen, war ärgerlich. Ich bin dankbar, musste aber hart arbeiten und dies ist nicht die einzige SSRF, die ich gefunden habe. Tatsächlich fand ich neugierigere, aber Facebook schloss die Berichte als "informativ", weil das Unternehmen eine Vereinbarung mit dem Lieferanten unterzeichnete, die es einige Wochen nach Überprüfung der Berichte getroffen hatte. Letztendlich ist dies nicht mein Problem, daher ist diese Erfahrung nicht angenehm.
Am Ende möchte ich mich entschuldigen, wenn etwas nicht klar war. Die Veröffentlichung des zweiten Teils dauerte einige Zeit - wie oben erwähnt, wartete ich auf die schriftliche Genehmigung und Überarbeitung des Berichts. Daher wurden viele Aspekte entfernt oder zensiert, um die Vertraulichkeit Dritter zu wahren.