HTTP Response Smuggling / Desync
Die Technik dieses Beitrags stammt aus dem Video: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
Desynchronisation der HTTP-Anforderungs-Warteschlange
Zunächst missbraucht diese Technik eine Schwachstelle beim HTTP-Anforderungsschmuggel, daher müssen Sie wissen, was das ist:
Der Hauptunterschied zwischen dieser Technik und einem gewöhnlichen HTTP-Anforderungsschmuggel besteht darin, dass anstatt den Angriff auf die Anforderung des Opfers durch das Hinzufügen eines Präfixes zu starten, wir die Antwort, die das Opfer erhält, durchsickern lassen oder modifizieren. Dies wird erreicht, indem anstelle des Sendens von 1 Anforderung und einer halben, um den HTTP-Anforderungsschmuggel auszunutzen, 2 vollständige Anforderungen gesendet werden, um die Antworten der Proxys zu desynchronisieren.
Dies liegt daran, dass wir in der Lage sein werden, die Antwortwarteschlange zu desynchronisieren, sodass die Antwort der legitimen Anforderung des Opfers an den Angreifer gesendet wird oder indem Angreifer gesteuerte Inhalte in die Antwort an das Opfer injiziert werden.
Desynchronisation der HTTP-Pipeline
HTTP/1.1 ermöglicht es, verschiedene Ressourcen anzufordern, ohne auf vorherige warten zu müssen. Daher ist es, wenn sich ein Proxy dazwischen befindet, die Aufgabe des Proxys, eine synchronisierte Zuordnung der an den Backend gesendeten Anforderungen und der von dort kommenden Antworten aufrechtzuerhalten.
Es gibt jedoch ein Problem bei der Desynchronisierung der Antwortwarteschlange. Wenn ein Angreifer einen HTTP-Antwortenschmuggelangriff sendet und die Antworten auf die ursprüngliche Anforderung und die geschmuggelte sofort beantwortet werden, wird die geschmuggelte Antwort nicht in die Warteschlange der Antwort des Opfers eingefügt, sondern einfach als Fehler verworfen.
Daher ist es erforderlich, dass die geschmuggelte Anforderung mehr Zeit benötigt, um im Backend-Server verarbeitet zu werden. Dadurch wird die Kommunikation mit dem Angreifer beendet sein, wenn die geschmuggelte Anforderung verarbeitet wird.
Wenn in dieser speziellen Situation ein Opfer eine Anforderung gesendet hat und die geschmuggelte Anforderung vor der legitimen Anforderung beantwortet wird, wird die geschmuggelte Antwort an das Opfer gesendet. Daher wird der Angreifer die Anforderung "ausführen", die vom Opfer "ausgeführt" wird.
Darüber hinaus, wenn der Angreifer dann eine Anforderung ausführt und die legitime Antwort auf die Anforderung des Opfers vor der Anforderung des Angreifers beantwortet wird, wird die Antwort an das Opfer an den Angreifer gesendet, wodurch die Antwort an das Opfer gestohlen wird (die beispielsweise den Header Set-Cookie enthalten kann).
Mehrfach verschachtelte Injektionen
Ein weiterer interessanter Unterschied zum gewöhnlichen HTTP-Anforderungsschmuggel besteht darin, dass bei einem gewöhnlichen Schmuggelangriff das Ziel darin besteht, den Anfang der Anforderung des Opfers zu modifizieren, damit eine unerwartete Aktion ausgeführt wird. Bei einem HTTP-Antwortenschmuggelangriff, da Sie vollständige Anforderungen senden, können Sie in einem Payload Dutzende von Antworten injizieren, die Dutzende von Benutzern desynchronisieren, die die injizierten Antworten erhalten werden.
Abgesehen davon, dass Sie so einfacher Dutzende von Exploits auf legitime Benutzer verteilen können, könnte dies auch dazu verwendet werden, einen DoS im Server zu verursachen.
Exploit-Organisation
Wie bereits erklärt, ist es erforderlich, dass die erste geschmuggelte Nachricht in den Server viel Zeit benötigt, um verarbeitet zu werden, um diese Technik auszunutzen.
Diese zeitintensive Anforderung reicht aus, wenn Sie nur versuchen, die Antwort des Opfers zu stehlen. Wenn Sie jedoch einen komplexeren Exploit durchführen möchten, wird dies eine gängige Struktur für den Exploit sein.
Zunächst die Anfangsanforderung, die den HTTP-Anforderungsschmuggel missbraucht, dann die zeitintensive Anforderung und dann 1 oder mehr Payload-Anforderungen, deren Antworten an die Opfer gesendet werden.
Ausnutzung der Desynchronisation der HTTP-Antwortwarteschlange
Erfassen von Anforderungen anderer Benutzer
Wie bei bekannten Payloads für den HTTP-Anforderungsschmuggel können Sie die Anforderung des Opfers stehlen mit einem wichtigen Unterschied: In diesem Fall müssen Sie nur sicherstellen, dass der gesendete Inhalt in der Antwort reflektiert wird, kein dauerhafter Speicher erforderlich ist.
Zunächst sendet der Angreifer einen Payload, der eine endgültige POST-Anforderung mit dem reflektierten Parameter am Ende und einer großen Content-Length enthält
Dann, sobald die ursprüngliche Anforderung (blau) verarbeitet wurde und während die schläfrige Anforderung verarbeitet wird (gelb), wird die nächste Anforderung, die von einem Opfer eintrifft, direkt nach dem reflektierten Parameter in die Warteschlange eingefügt:
Dann wird das Opfer die Antwort auf die schläfrige Anforderung erhalten und wenn in der Zwischenzeit der Angreifer eine weitere Anforderung sendet, wird die Antwort auf die Anforderung mit dem reflektierten Inhalt an ihn gesendet.
Antwort-Desynchronisation
Bis zu diesem Punkt haben wir gelernt, wie man HTTP-Anforderungsschmuggelangriffe missbraucht, um die Anforderung zu steuern, deren Antwort ein Client erhalten wird, und wie Sie dann die Antwort stehlen können, die für das Opfer gedacht war.
Aber es ist immer noch möglich, die Antworten noch weiter zu desynchronisieren.
Es gibt interessante Anfragen wie HEAD-Anfragen, die spezifiziert sind, um keinen Inhalt im Antwortkörper zu haben und die (müssen) die Content-Length der Anforderung enthalten, als ob es eine GET-Anforderung wäre.
Daher, wenn ein Angreifer eine HEAD-Anforderung injiziert, wie in diesen Bildern:
Dann, nachdem die blaue Anforderung an den Angreifer beantwortet wurde, wird die nächste Anforderung des Opfers in die Warteschlange eingefügt:
Dann wird das Opfer die Antwort auf die HEAD-Anforderung erhalten, die eine Content-Length, aber überhaupt keinen Inhalt enthalten wird. Daher wird der Proxy diese Antwort nicht an das Opfer senden, sondern auf Inhalt warten, der tatsächlich die Antwort auf die gelbe Anforderung sein wird (ebenfalls vom Angreifer injiziert):
Inhaltsverwirrung
Nach dem vorherigen Beispiel, wissend, dass du den Body der Anfrage kontrollieren kannst, deren Antwort das Opfer erhalten wird und dass eine HEAD-Antwort normalerweise in ihren Headern den Content-Type und die Content-Length enthält, kannst du eine Anfrage wie die folgende senden, um XSS im Opfer zu verursachen, ohne dass die Seite anfällig für XSS ist:
Cache-Vergiftung
Durch Ausnutzen des zuvor kommentierten Antwort-Desynchronisierungsangriffs Content Confusion, wenn der Cache die Antwort auf die Anfrage speichert, die vom Opfer durchgeführt wurde und diese Antwort eine injizierte ist, die XSS verursacht, dann ist der Cache vergiftet.
Bösartige Anfrage, die das XSS-Payload enthält:
Bösartige Antwort an das Opfer, die den Header enthält, der dem Cache anzeigt, die Antwort zu speichern:
Beachte, dass in diesem Fall, wenn der "Angreifer" das Opfer ist, er jetzt Cache-Vergiftung in beliebigen URLs durchführen kann, da er die URL steuern kann, die mit der bösartigen Antwort zwischengespeichert wird.
Web-Cache-Täuschung
Dieser Angriff ähnelt dem vorherigen, aber anstatt ein Payload im Cache einzufügen, wird der Angreifer Opferinformationen im Cache zwischenspeichern:
Antwort-Splitting
Das Ziel dieses Angriffs ist es, erneut die Antwort-Desynchronisierung auszunutzen, um den Proxy dazu zu bringen, eine zu 100 % vom Angreifer generierte Antwort zu senden.
Um dies zu erreichen, muss der Angreifer einen Endpunkt der Webanwendung finden, der einige Werte in der Antwort reflektiert und die Content-Length der HEAD-Antwort kennen.
Er wird ein Exploit wie folgt senden:
Nachdem die erste Anfrage gelöst und an den Angreifer zurückgesendet wurde, wird die Anfrage des Opfers in die Warteschlange aufgenommen:
Das Opfer wird als Antwort die HEAD-Antwort + den Inhalt der Antwort der zweiten Anfrage (der einen Teil der reflektierten Daten enthält) erhalten:
Beachte jedoch, wie die reflektierten Daten eine Größe gemäß der Content-Length der HEAD-Antwort hatten, die eine gültige HTTP-Antwort in der Antwortwarteschlange generierte.
Daher wird die nächste Anfrage des zweiten Opfers als Antwort etwas erhalten, das vollständig vom Angreifer erstellt wurde. Da die Antwort vollständig vom Angreifer erstellt wurde, kann er auch den Proxy dazu bringen, die Antwort zu zwischenspeichern.
Last updated
