Cookie-basierter XSS-Betrieb | $ 2300 Bug Bounty Geschichte

Seit einiger Zeit bin ich auf der HackerOne-Plattform auf der Suche nach Schwachstellen und habe außerhalb der Hauptarbeit eine gewisse Zeit für die Überprüfung meiner Lieblings- und neuen Programme aufgewendet. Unzählige Male bin ich auf eine Cookie-basierte XSS-Sicherheitslücke gestoßen, die zur Hauptfigur dieses Artikels wird. Diese Art von Sicherheitsanfälligkeit tritt auf, wenn der Wert des Cookie-Parameters auf der Seite angezeigt wird. Standardmäßig gelten sie als Selbst-XSS, es sei denn, wir beweisen ihrerseits ihre Gefahr. Heute werde ich Ihnen erklären, wie Sie Cookie-basierte XSS-Schwachstellen ausnutzen können, und ich werde auch ein Beispiel aus dem Testen eines Unternehmens geben, von dem ich insgesamt 7300 US-Dollar für die Studie erhalten habe.

Um Javascript auf der Benutzerseite auszuführen, müssen Sie einen Weg finden, ein Cookie zu setzen und das Opfer gegebenenfalls auf eine Seite zu locken, auf der das Cookie wiederum eingebettet ist. Mögliche Möglichkeiten, diesen Fehler auszunutzen:

⠀ 1. CRLF-Injektion. Diese Sicherheitsanfälligkeit tritt auf, wenn Zeilenumbruchzeichen nicht ordnungsgemäß überprüft und blockiert werden. Wir können den Set-Cookie-Header als Antwort mit dem gewünschten Namen sowie dem Wert des Cookies implementieren und im Browser festlegen. Beispiel aus der Praxis: Rutschige CRLF-Injektion auf twitter.com in einer Weiterleitung - https://twitter.com/login?redirect_after_login=/jjjkkk 嘍 嘍 Set-Cookie: jjjjj = a; domain = twitter.com



Berichte über diese Art von Sicherheitsanfälligkeit können unter HackerOne hackerone.com/hacktivity?order_direction=DESC&order_field=popular&filter=type%3Apublic&querystring=crlf%20injection gelesen werden

2. XSS-Sicherheitsanfälligkeit in der Subdomain. XSS muss öffentlich zugänglich sein und sich auf dem Platzhalter * .vulnerabledomain.com befinden. Bei vielen Bug-Bounty-Programmen sind Subdomains außerhalb des Geltungsbereichs, dh in den meisten Fällen werden Bugs entweder überhaupt nicht akzeptiert oder mit der Markierung „Nicht für das Bounty berechtigt“ empfangen. In solchen Fällen sollten Sie nicht zurücktreten, aber um eine Verbindung mit XSS auf Cookie-Basis herzustellen, können Sie Ihre Zeit in die Suche nach XSS investieren, um eine Belohnung zu erhalten. Wenn XSS erkannt wird, können wir das Cookie mithilfe der Funktion document.cookie setzen oder entfernen.

Auswirkungsverbesserung: Oft vertraut das Opfer der Hauptdomäne von Vulabledabledomain.com mehr als beispielsweise jira.vulnerabledomain.com und sogar der URL /plugins/servlet/oauth/users/icon-uri?consumerUri=https://maliciousdomain.com . Es ist wahrscheinlicher, dass zur Hauptdomäne als zur Unterdomäne gewechselt wird, wenn diese Unterdomäne keinem persönlichen Konto oder keiner Autorisierung zugeordnet ist. Basierend auf dem Vorstehenden können wir die In-Site-Umleitungsfunktion verwenden, um für einen besseren Effekt zur Subdomain Vulnerabledomain.com/login?redirectUrl=https : //jira.vulnerabledomain.com/path umzuleiten.

Wenn das Opfer eine aktive Sitzung hat, erfolgt die Weiterleitung automatisch. Andernfalls ist eine Autorisierung erforderlich. Wenn der Benutzer auf einen solchen Link klickt, wird das Cookie auch von der Subdomain installiert, in der Reflected XSS vorhanden ist. Es kann weiter stromaufwärts gesendet werden - zu der Seite mit Cookie-basiertem XSS, auf der der Exploit funktionieren könnte, der wiederum den CSRF-Wert des Tokens erfasst und schließen Sie die Anforderung zum Ändern der E-Mail-Adresse ab. Daher kann eine Kombination aus zwei XSS-Schwachstellen zu einer Kontoübernahme führen, wenn keine damit verbundenen Probleme vorliegen, z. B. eine zusätzliche Bestätigung der Änderung des E-Mail-Kennworts oder des Codes aus dem alten Postfach.

3. Erkennung von Testdateien, mit denen Cookies gesetzt werden können. Es reicht aus, das Tool zur Inhaltserkennung (dirb, dirserach usw.) aufzudecken, mit dem Graben zu beginnen. Wenn die Entwickler vergessen haben, die Bereinigung durchzuführen, können Sie auf solche Dateien stoßen.

Kürzlich habe ich eine HTML-Seite für Testservlets gefunden, auf der ein Cookie mit einem beliebigen Namen und Wert installiert werden konnte. Der Schutz für die POST-Anforderung war natürlich nicht vorhanden. Wenn das Opfer also den CSRF-Exploit besuchen würde (oder Sie den POST in GET ändern könnten), könnte ein Cookie in seinem Browser installiert werden.



Dieser Fehler wurde als unzureichende Alternative zur CRLF-Injektion qualifiziert, durch Entfernen von / examples / behoben und 150 US-Dollar für einen Fehler mit niedrigem Schweregrad gezahlt. Obwohl der h1-Triager ein Medium lieferte, waren die Entwickler immer noch geneigt zu glauben, dass dies ein geringer Schweregrad ist.



4. Mann im mittleren Angriff (MITM). Diese Methode kann nur angewendet werden, wenn das Cookie kein sicheres Flag enthält. Wenn Sie nicht wissen, um welche Art von Flagge es sich handelt, oder nur Ihr Gedächtnis auffrischen möchten, empfehlen wir Ihnen, die Präsentation zur Cookie-Sicherheit von OWASP London 2017 unter www.owasp.org/images/a/a0/OWASPLondon20171130_Cookie_Security_Myths_Misconceptions_David_Johansson.pdf anzusehen .

Für einen erfolgreichen Angriff ist es erforderlich, dass sich das Opfer im Netzwerk des Angreifers befindet oder dass die DNS-Auflösung beeinträchtigt wird. Um die Sicherheitsanfälligkeit zu überprüfen, ist Folgendes erforderlich:

1) Hosten Sie die Datei index.php mit folgendem Inhalt:

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

2) Fügen Sie Ihrer Datei / etc / hosts / die folgende Zeile hinzu: 127.0.0.1 non -exist-subdomain.vulnerabledomain.com

3) Besuchen Sie non-existed-subdomain.vulnerabledomain.com und öffnen Sie anschließend die Seite, auf der das Cookie angezeigt wird.

Ein wunderbares Beispiel für die MITM-Ausnutzung auf e.mail.ru ist https://hackerone.com/reports/312548. Wie Sie sehen, reichte MITM aus, um eine geringe Gefahr von Sicherheitslücken zu beweisen, aber die Auszeichnung entsprach nicht dem Level von Stored XSS, da sie nur angezeigt wurde "Lokale" Betriebsart, dh nicht "in the wild". Wenn der Forscher ein wenig Zeit damit verbracht hat, nach XSS- oder CRLF-Injektionen (die unzählig sind) auf * .mail.ru zu suchen, könnte die Belohnung leicht erhöht werden.

Aber nicht alle Hackerone-Programme akzeptieren Cookie-basiertes XSS über MITM. Wenn in den Bereichsausschlüssen "Self XSS" angegeben ist, kann diese Operation als Self XSS betrachtet und informativ oder n / a festgelegt werden, was nicht immer angenehm ist. Jetzt werde ich über einen ähnlichen Vorfall sprechen, der mir bei der nächsten Jagd auf dem Bahnsteig passiert ist.

Beim Testen der Site habe ich plötzlich festgestellt, dass sich der Wert redigierter Cookies in einem der Unterverzeichnisse der Site widerspiegelt. Als erstes habe ich die Anzeige der Zeichen "/ <> überprüft. Es stellte sich heraus, dass nur die Zeichen <> gefiltert wurden, und dies zeigt uns, dass wir nicht darüber hinausgehen können, aber es wird auch klar, dass die anderen Zeichen nicht gefiltert werden Ohne nachzudenken, implementieren wir '-alert (document.domain) -' und js wird ausgeführt.

Da die Entwickler dem Cookie nicht das sichere Flag gegeben haben, funktioniert in diesem Fall die MITM-Methode. Es wurde beschlossen, dem Programm einen Bericht mit folgenden Auswirkungen zu senden:



Die Mitarbeiter von HackerOne (Triager) haben deutlich gemacht, dass dies Self-XSS ist, und ich muss mich noch mehr anstrengen:



Danach begann ich auf der Website zu surfen und zu versuchen, eine CRLF-Injektion oder XSS zu finden, um die Gefahr zu beweisen.

⠀ Ich musste die Liste der Subdomains mithilfe eines großen Wörterbuchs erweitern, Subdomains mit SSL-Zertifikaten abkratzen und einige andere Tricks anwenden. Das Ergebnis ließ nicht lange auf sich warten, da die meisten Tools mit VPS ausgeführt werden. Von Zeit zu Zeit wurden auch andere Fehler auf dem Weg entdeckt, die ich gemeldet habe, und bei Bedarf den Bereich von außerhalb des Bereichs gemacht haben. Ich bin auf viele Open Redirects und sogar auf einen Fehler bei der unsachgemäßen Zugriffskontrolle für 5000 US-Dollar gestoßen, konnte aber die erforderlichen Sicherheitslücken für das Bundle immer noch nicht erkennen. Der oben erwähnte Fehler ist sehr interessant und gefährlich. Die gesamte Subdomain wurde unmittelbar nach dem Bericht offline geschaltet. Vielleicht werde ich den Bericht in Zukunft auf hackerone.com/w2w öffnen, wenn das Programm veröffentlicht wird.

Eine Woche später wurden die Ergebnisse des Skripts zum Erkennen von Inhalten überprüft, wobei der Endpunkt / die Verifikation gefunden wurde, auf die ich zunächst keine besondere Bedeutung legte, aber dennoch das Skript darauf setzte - das Unterverzeichnis / verification / login wurde gefunden. Nach dem Übergang wurde die Seite /verification/login/?redirect_uri=https://vulnerabledomain.com angezeigt, die nach der Anmeldung auf den Wert redirect_uri umgeleitet oder bei einer Sitzung sofort umgeleitet wurde. Nach dem Flug zum Eindringling wurde ein offener Umleitungsschutz-Bypass entdeckt - Vulnerabledomain.com@anotherdomain.com. Es wurde versucht, den Fehler in XSS zu beheben - die Nutzdaten für Javascript: alert (1) sind fehlgeschlagen, Javascript: alert (1) // ebenfalls. Aber die Javascript-Nutzdaten: // https: //vulnerablesite.com/%250A1? Alert (1): 0 Schuss, weil der Parameter aufgrund des Vorhandenseins von Vulnerablesite.com die White-List-Validierung bestanden hat.



Nachdem ich die Maus hektisch durch das Benachrichtigungsfenster gefahren hatte (was ich immer tue), machte ich mich sofort an die Arbeit an meinem Cookie-basierten XSS. Verwenden von Javascript: https: //vulnerabledomain.com/%0A1? Dokument% 2ecookie% 20% 3d% 20% 27SID% 3d137gf6g67f76fg6766123% 5c% 27-alert% 28document% 2edomain% 29-% 5c% 27% 3b% 20expires% 3dFri% 2c% 203% 20Aug% 202019% 2020% 3a47% 3a11% 20UTC% 3b% 20path% 3d% 2f% 3b% 20domain% 3d% 2evulnerabledomain% 2ecom% 3b% 27% 3a0 Der Cookie wurde erfolgreich auf * .vulnerabledomain.com gespeichert . Nachdem Sie mit dem Cookie auf die Seite gegangen waren, wurde der geschätzte Alarm ausgelöst! Double XSS, Prost! :) Ich habe den Bericht ergänzt und auf eine Antwort gewartet.



Am selben Tag flog "Nice catch" vom Triaden ein (wenn man es so nennen kann), und das Kopfgeld wurde ausgezahlt. Gott segne die Unternehmen, die für Triage bezahlen!

Für DOM-basiertes XSS, mit dem ich das Cookie installiert habe, ist auch Bounty angekommen.

Testergebnisse

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

Dieses Programm funktioniert seit mehr als einem Jahr, aber in weniger als einem Monat konnte ich den ersten Platz einnehmen und einiges mit dem Testen anfangen. Ich habe versucht, die meisten Endpunkte in Phasen zu bringen, ihre Reaktion zu bewerten, die Funktionsweise der Site zu verstehen und sogar die Desktop-Anwendung zu testen. Dieses Bug-Bounty-Programm ist zu einem der beliebtesten auf HackerOne geworden. Ich hoffe auch Sie finden eines Tages das gleiche! :) :)



Es war auch dieses Programm, das mir einen neuen Schub gab (mail.ru - das erste), - mit dem ich 2500 Reputation (Hallo Hoodie) erreichte und in 90 Tagen den 36. Platz in der Rangliste für Reputation erreichte, was neue Chancen geben sollte . Obwohl es den Anschein hat, dass Transplantate unabhängig von der Präsenz in der Rangliste eintreffen, storniere ich oft alte Transplantate und warte auf neue in der Schlange.

Kurzer Brief

• Cookie-basiertes XSS kann vollständig ausgenutzt werden. Wenn Sie versuchen, etwas tiefer zu graben, können Sie ein Kopfgeld anstelle von n / a erhalten, wodurch das Signal und der Ruf von -5 zerstört werden.
• Wenn das Programm alt ist, bedeutet dies nicht, dass es keine Schwachstellen enthält. Wenn die Früchte längere Zeit am Baum hängen, werden die niedrig hängenden Früchte sofort gepflückt und entnommen (Übernahmen in Subdomänen usw.). Andere Früchte hängen weiter, aber höher. Um sie zu bekommen, müssen Sie einige Anstrengungen unternehmen.
• Manchmal ist es besser, sich lange auf ein Programm zu konzentrieren, so viele Schwachstellen wie möglich zu finden und es zu überwachen. Es ist besser, das Programm zu finden, das Sie bevorzugen, und es zu brechen.
• Beharrlichkeit und der Wunsch zu verstehen, wie eine Webanwendung funktioniert, sowie bestimmte Funktionen und deren Interaktion untereinander sind der Schlüssel für die erfolgreiche Suche nach Schwachstellen in einer Bug Bounty.

Wenn Sie über meine neuesten Artikel und Neuigkeiten auf dem Laufenden bleiben möchten, empfehle ich Ihnen, den Telegrammkanal / Twitter zu abonnieren, auf den Sie unten verweisen können.