Race Condition
Last updated
Last updated
Verwenden Sie Trickest, um einfach Workflows zu erstellen und zu automatisieren, die von den fortschrittlichsten Community-Tools der Welt unterstützt werden. Zugang heute erhalten:
Um ein tiefes Verständnis dieser Technik zu erlangen, überprüfen Sie den Originalbericht unter https://portswigger.net/research/smashing-the-state-machine
Die größte Hürde bei der Ausnutzung von Race Conditions besteht darin, sicherzustellen, dass mehrere Anfragen gleichzeitig bearbeitet werden, mit sehr geringem Unterschied in ihren Verarbeitungszeiten – idealerweise weniger als 1 ms.
Hier finden Sie einige Techniken zur Synchronisierung von Anfragen:
HTTP/2: Unterstützt das Senden von zwei Anfragen über eine einzige TCP-Verbindung, wodurch die Auswirkungen von Netzwerk-Jitter verringert werden. Aufgrund serverseitiger Variationen können jedoch zwei Anfragen möglicherweise nicht ausreichen, um einen konsistenten Race Condition-Angriff durchzuführen.
HTTP/1.1 'Last-Byte-Sync': Ermöglicht das Vorab-Senden der meisten Teile von 20-30 Anfragen, wobei ein kleines Fragment zurückgehalten wird, das dann zusammen gesendet wird, um eine gleichzeitige Ankunft beim Server zu erreichen.
Die Vorbereitung für Last-Byte-Sync umfasst:
Senden von Headern und Bodendaten ohne das letzte Byte, ohne den Stream zu beenden.
Eine Pause von 100 ms nach dem ersten Senden.
Deaktivierung von TCP_NODELAY, um Nagles Algorithmus für das Batchen der letzten Frames zu nutzen.
Pingen, um die Verbindung aufzuwärmen.
Das anschließende Senden der zurückgehaltenen Frames sollte zu ihrer Ankunft in einem einzigen Paket führen, was über Wireshark überprüfbar ist. Diese Methode gilt nicht für statische Dateien, die typischerweise nicht in RC-Angriffen involviert sind.
Das Verständnis der Architektur des Ziels ist entscheidend. Front-End-Server könnten Anfragen unterschiedlich weiterleiten, was die Zeitmessung beeinflusst. Eine präventive serverseitige Verbindungserwärmung durch unbedeutende Anfragen könnte die Anfragetiming normalisieren.
Frameworks wie PHPs Sitzungs-Handler serialisieren Anfragen nach Sitzung, was potenziell Schwachstellen verschleiern kann. Die Verwendung unterschiedlicher Sitzungstoken für jede Anfrage kann dieses Problem umgehen.
Wenn die Verbindungserwärmung nicht effektiv ist, könnte das absichtliche Auslösen von Verzögerungen durch die Rate- oder Ressourcenlimits von Webservern durch eine Flut von Dummy-Anfragen den Single-Packet-Angriff erleichtern, indem eine serverseitige Verzögerung induziert wird, die für Race Conditions förderlich ist.
Tubo Intruder - HTTP2 Single-Packet-Angriff (1 Endpunkt): Sie können die Anfrage an Turbo Intruder senden (Extensions -> Turbo Intruder -> Send to Turbo Intruder), Sie können im Request den Wert ändern, den Sie für %s brute-forcen möchten, wie in csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s, und dann examples/race-single-packer-attack.py aus dem Dropdown auswählen:
Wenn Sie verschiedene Werte senden möchten, könnten Sie den Code mit diesem ändern, der eine Wortliste aus der Zwischenablage verwendet:
Wenn das Web kein HTTP2 unterstützt (nur HTTP1.1), verwenden Sie Engine.THREADED oder Engine.BURP anstelle von Engine.BURP2.
Tubo Intruder - HTTP2 Einzelpaketangriff (Mehrere Endpunkte): Falls Sie eine Anfrage an 1 Endpunkt senden müssen und dann mehrere an andere Endpunkte, um die RCE auszulösen, können Sie das Skript race-single-packet-attack.py mit etwas wie folgendem ändern:
Es ist auch in Repeater über die neue 'Send group in parallel' Option in Burp Suite verfügbar.
Für limit-overrun könnten Sie einfach die gleiche Anfrage 50 Mal in der Gruppe hinzufügen.
Für connection warming könnten Sie am Anfang der Gruppe einige Anfragen an einen nicht statischen Teil des Webservers hinzufügen.
Um den Prozess zwischen der Verarbeitung einer Anfrage und einer anderen in 2 Subzuständen zu verzögern, könnten Sie zusätzliche Anfragen zwischen beiden Anfragen hinzufügen.
Für eine multi-endpoint RC könnten Sie die Anfrage senden, die in den versteckten Zustand geht, und dann 50 Anfragen direkt danach, die den versteckten Zustand ausnutzen.
Automatisiertes Python-Skript: Das Ziel dieses Skripts ist es, die E-Mail eines Benutzers zu ändern, während es kontinuierlich überprüft, bis der Bestätigungstoken der neuen E-Mail an die letzte E-Mail ankommt (das liegt daran, dass im Code ein RC gesehen wurde, bei dem es möglich war, eine E-Mail zu ändern, aber die Bestätigung an die alte zu senden, weil die Variable, die die E-Mail angibt, bereits mit der ersten gefüllt war). Wenn das Wort "objetivo" in den empfangenen E-Mails gefunden wird, wissen wir, dass wir den Bestätigungstoken der geänderten E-Mail erhalten haben und beenden den Angriff.
In der ursprünglichen Forschung wird erklärt, dass dieser Angriff eine Grenze von 1.500 Bytes hat. In diesem Beitrag wurde jedoch erklärt, wie es möglich ist, die 1.500-Byte-Beschränkung des Single Packet Angriffs auf die 65.535 B Fensterbeschränkung von TCP durch Verwendung von IP-Schichtfragmentierung (Aufteilen eines einzelnen Pakets in mehrere IP-Pakete) zu erweitern und sie in unterschiedlicher Reihenfolge zu senden, was es ermöglichte, die Rekonstruktion des Pakets zu verhindern, bis alle Fragmente den Server erreicht hatten. Diese Technik ermöglichte es dem Forscher, 10.000 Anfragen in etwa 166 ms zu senden.
Beachten Sie, dass diese Verbesserung den Angriff in RC, der Hunderte/Tausende von Paketen erfordert, um gleichzeitig anzukommen, zuverlässiger macht, aber auch einige Softwarebeschränkungen haben könnte. Einige beliebte HTTP-Server wie Apache, Nginx und Go haben eine strenge Einstellung SETTINGS_MAX_CONCURRENT_STREAMS von 100, 128 und 250. Andere wie NodeJS und nghttp2 haben sie jedoch unbegrenzt.
Das bedeutet im Grunde, dass Apache nur 100 HTTP-Verbindungen von einer einzelnen TCP-Verbindung berücksichtigt (was diesen RC-Angriff einschränkt).
Sie finden einige Beispiele, die diese Technik verwenden, im Repo https://github.com/Ry0taK/first-sequence-sync/tree/main.
Vor der vorherigen Forschung wurden einige Payloads verwendet, die einfach versuchten, die Pakete so schnell wie möglich zu senden, um einen RC zu verursachen.
Repeater: Überprüfen Sie die Beispiele aus dem vorherigen Abschnitt.
Intruder: Senden Sie die Anfrage an Intruder, setzen Sie die Anzahl der Threads auf 30 im Optionsmenü und wählen Sie als Payload Null-Payloads und generieren Sie 30.
Turbo Intruder
Python - asyncio
Dies ist die grundlegendste Art von Race Condition, bei der Schwachstellen auftreten, die an Orten erscheinen, die die Anzahl der Male begrenzen, die Sie eine Aktion ausführen können. Wie die Verwendung desselben Rabattcodes in einem Webshop mehrere Male. Ein sehr einfaches Beispiel finden Sie in diesem Bericht oder in diesem Bug.
Es gibt viele Variationen dieser Art von Angriff, einschließlich:
Einlösen einer Geschenkkarte mehrere Male
Bewerten eines Produkts mehrere Male
Abheben oder Überweisen von Bargeld über Ihr Kontoguthaben hinaus
Wiederverwendung einer einzelnen CAPTCHA-Lösung
Umgehen einer Anti-Brute-Force-Ratebegrenzung
Das Ausnutzen komplexer Race Conditions beinhaltet oft, kurze Gelegenheiten zu nutzen, um mit verborgenen oder unbeabsichtigten Maschinen-Subzuständen zu interagieren. So gehen Sie vor:
Identifizieren Sie potenzielle verborgene Subzustände
Beginnen Sie mit der Identifizierung von Endpunkten, die kritische Daten ändern oder mit ihnen interagieren, wie z. B. Benutzerprofile oder Passwortzurücksetzprozesse. Konzentrieren Sie sich auf:
Speicherung: Bevorzugen Sie Endpunkte, die serverseitige persistente Daten manipulieren, gegenüber denen, die Daten clientseitig verarbeiten.
Aktion: Suchen Sie nach Operationen, die vorhandene Daten ändern, da diese eher ausnutzbare Bedingungen schaffen als solche, die neue Daten hinzufügen.
Schlüsselung: Erfolgreiche Angriffe beinhalten normalerweise Operationen, die auf demselben Identifikator basieren, z. B. Benutzername oder Rücksetz-Token.
Durchführen einer ersten Erkundung
Testen Sie die identifizierten Endpunkte mit Race Condition-Angriffen und beobachten Sie Abweichungen von den erwarteten Ergebnissen. Unerwartete Antworten oder Änderungen im Anwendungsverhalten können auf eine Schwachstelle hinweisen.
Demonstrieren Sie die Schwachstelle
Reduzieren Sie den Angriff auf die minimale Anzahl von Anfragen, die erforderlich sind, um die Schwachstelle auszunutzen, oft nur zwei. Dieser Schritt kann mehrere Versuche oder Automatisierung erfordern, aufgrund des präzisen Timings.
Präzision beim Timing von Anfragen kann Schwachstellen aufdecken, insbesondere wenn vorhersehbare Methoden wie Zeitstempel für Sicherheitstoken verwendet werden. Zum Beispiel könnte die Generierung von Passwortzurücksetz-Token basierend auf Zeitstempeln identische Token für gleichzeitige Anfragen ermöglichen.
Um auszunutzen:
Verwenden Sie präzises Timing, wie einen einzelnen Paketangriff, um gleichzeitige Passwortzurücksetz-Anfragen zu stellen. Identische Token weisen auf eine Schwachstelle hin.
Beispiel:
Fordern Sie zwei Passwortzurücksetz-Token gleichzeitig an und vergleichen Sie sie. Übereinstimmende Token deuten auf einen Fehler in der Token-Generierung hin.
Überprüfen Sie dies PortSwigger Lab um dies auszuprobieren.
Überprüfen Sie dieses PortSwigger Lab, um zu sehen, wie Sie im Geschäft bezahlen und einen zusätzlichen Artikel hinzufügen, für den Sie nicht bezahlen müssen.
Die Idee ist, eine E-Mail-Adresse zu verifizieren und sie gleichzeitig in eine andere zu ändern, um herauszufinden, ob die Plattform die neue geänderte Adresse überprüft.
Laut dieser Forschung war Gitlab auf diese Weise anfällig für einen Übernahmeangriff, da es das E-Mail-Bestätigungstoken einer E-Mail an die andere E-Mail senden könnte.
Überprüfen Sie dies PortSwigger Lab um dies auszuprobieren.
Wenn 2 verschiedene Schreibvorgänge verwendet werden, um Informationen in eine Datenbank hinzuzufügen, gibt es einen kurzen Zeitraum, in dem nur die ersten Daten in die Datenbank geschrieben wurden. Zum Beispiel, wenn ein Benutzer erstellt wird, könnten der Benutzername und das Passwort geschrieben werden und dann das Token, um das neu erstellte Konto zu bestätigen. Das bedeutet, dass für eine kurze Zeit das Token zur Bestätigung eines Kontos null ist.
Daher könnte die Registrierung eines Kontos und das Senden mehrerer Anfragen mit einem leeren Token (token= oder token[]= oder jede andere Variation), um das Konto sofort zu bestätigen, ermöglichen, ein Konto zu bestätigen, bei dem Sie die E-Mail nicht kontrollieren.
Überprüfen Sie dies PortSwigger Lab um dies auszuprobieren.
Der folgende Pseudocode ist anfällig für Race Conditions, da in einem sehr kurzen Zeitraum 2FA nicht durchgesetzt wird, während die Sitzung erstellt wird:
Es gibt mehrere OAuth-Anbieter. Diese Dienste ermöglichen es Ihnen, eine Anwendung zu erstellen und Benutzer zu authentifizieren, die der Anbieter registriert hat. Um dies zu tun, muss der Client Ihrer Anwendung erlauben, auf einige ihrer Daten innerhalb des OAuth-Anbieters zuzugreifen. Bis hierhin ist es nur ein gewöhnlicher Login mit Google/LinkedIn/GitHub..., bei dem Sie mit einer Seite konfrontiert werden, die sagt: "Anwendung <InsertCoolName> möchte auf Ihre Informationen zugreifen, möchten Sie das erlauben?"
authorization_codeDas Problem tritt auf, wenn Sie es akzeptieren und automatisch einen authorization_code an die bösartige Anwendung senden. Dann missbraucht diese Anwendung eine Race Condition im OAuth-Dienstanbieter, um mehr als ein AT/RT (Authentication Token/Refresh Token) aus dem authorization_code für Ihr Konto zu generieren. Grundsätzlich wird sie ausnutzen, dass Sie die Anwendung akzeptiert haben, um auf Ihre Daten zuzugreifen, um mehrere Konten zu erstellen. Wenn Sie dann aufhören, der Anwendung den Zugriff auf Ihre Daten zu erlauben, wird ein Paar von AT/RT gelöscht, aber die anderen bleiben weiterhin gültig.
Refresh TokenSobald Sie ein gültiges RT erhalten haben, könnten Sie versuchen, es auszunutzen, um mehrere AT/RT zu generieren, und selbst wenn der Benutzer die Berechtigungen für die bösartige Anwendung zum Zugriff auf seine Daten widerruft, werden mehrere RTs weiterhin gültig sein.
In WS_RaceCondition_PoC finden Sie einen PoC in Java, um Websocket-Nachrichten parallel zu senden, um Race Conditions auch in Web Sockets auszunutzen.
Verwenden Sie Trickest, um einfach Workflows zu erstellen und zu automatisieren, die von den fortschrittlichsten Community-Tools der Welt unterstützt werden. Erhalten Sie heute Zugang:
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
