HTTP Response Smuggling / Desync

Reading time: 7 minutes

Die Technik dieses Beitrags stammt aus dem Video: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s

HTTP Request Queue Desynchronisation

Zunächst einmal missbraucht diese Technik eine HTTP Request Smuggling-Schwachstelle, daher müssen Sie wissen, was das ist:

Der Hauptunterschied zwischen dieser Technik und einem gängigen HTTP Request Smuggling besteht darin, dass wir statt die Anfrage des Opfers durch Hinzufügen eines Präfixes anzugreifen, die Antwort, die das Opfer erhält, leaken oder modifizieren werden. Dies geschieht, indem wir anstatt 1,5 Anfragen zu senden, um das HTTP Request Smuggling auszunutzen, 2 vollständige Anfragen senden, um die Antwortwarteschlange der Proxys zu desynchronisieren.

Das liegt daran, dass wir in der Lage sein werden, die Antwortwarteschlange zu desynchronisieren, sodass die Antwort der legitimen Anfrage des Opfers an den Angreifer gesendet wird, oder indem wir Inhalte, die vom Angreifer kontrolliert werden, in die Antwort an das Opfer injizieren.

HTTP Pipeline Desync

HTTP/1.1 erlaubt es, verschiedene Ressourcen anzufordern, ohne auf vorherige warten zu müssen. Daher ist es die Aufgabe des Proxys, eine synchronisierte Übereinstimmung von Anfragen, die an das Backend gesendet werden, und Antworten, die von ihm kommen, aufrechtzuerhalten.

Es gibt jedoch ein Problem bei der Desynchronisation der Antwortwarteschlange. Wenn ein Angreifer einen HTTP Response Smuggling-Angriff sendet und die Antworten auf die ursprüngliche Anfrage und die geschmuggelte sofort beantwortet werden, wird die geschmuggelte Antwort nicht in die Warteschlange der Opferantwort eingefügt, sondern wird einfach als Fehler verworfen.

Daher ist es notwendig, dass die geschmuggelte Anfrage länger benötigt, um verarbeitet zu werden. Wenn die geschmuggelte Anfrage verarbeitet wird, wird die Kommunikation mit dem Angreifer beendet sein.

Wenn in dieser speziellen Situation ein Opfer eine Anfrage gesendet hat und die geschmuggelte Anfrage vor der legitimen Anfrage beantwortet wird, wird die geschmuggelte Antwort an das Opfer gesendet. Daher wird der Angreifer die Anfrage "ausgeführt" vom Opfer kontrollieren.

Darüber hinaus, wenn der Angreifer dann eine Anfrage ausführt und die legitime Antwort auf die Anfrage des Opfers beantwortet wird, bevor die Anfrage des Angreifers. Die Antwort an das Opfer wird an den Angreifer gesendet, stiehlt die Antwort an das Opfer (die beispielsweise den Header Set-Cookie enthalten kann).

Multiple Nested Injections

Ein weiterer interessanter Unterschied zu gängigem HTTP Request Smuggling besteht darin, dass das Ziel bei einem gängigen Smuggling-Angriff darin besteht, den Beginn der Anfrage des Opfers zu modifizieren, sodass sie eine unerwartete Aktion ausführt. Bei einem HTTP Response Smuggling-Angriff, da Sie vollständige Anfragen senden, können Sie in einem Payload Dutzende von Antworten injizieren, die Dutzende von Benutzern desynchronisieren, die die injizierten Antworten erhalten.

Neben der Möglichkeit, Dutzende von Exploits leichter auf legitime Benutzer zu verteilen, könnte dies auch verwendet werden, um einen DoS auf dem Server zu verursachen.

Exploit Organisation

Wie zuvor erklärt, um diese Technik auszunutzen, ist es notwendig, dass die erste geschmuggelte Nachricht im Server viel Zeit benötigt, um verarbeitet zu werden.

Diese zeitaufwendige Anfrage ist ausreichend, wenn wir nur versuchen wollen, die Antwort des Opfers zu stehlen. Aber wenn Sie einen komplexeren Exploit durchführen möchten, wird dies eine gängige Struktur für den Exploit sein.

Zunächst die initiale Anfrage, die HTTP Request Smuggling missbraucht, dann die zeitaufwendige Anfrage und dann 1 oder mehr Payload-Anfragen, deren Antworten an die Opfer gesendet werden.

Missbrauch der HTTP Response Queue Desynchronisation

Abfangen von Anfragen anderer Benutzer

Wie bei bekannten Payloads von HTTP Request Smuggling können Sie die Anfrage des Opfers stehlen mit einem wichtigen Unterschied: In diesem Fall müssen Sie nur den gesendeten Inhalt reflektiert in der Antwort haben, keine persistente Speicherung ist erforderlich.

Zunächst sendet der Angreifer ein Payload, das eine abschließende POST-Anfrage mit dem reflektierten Parameter am Ende und einer großen Content-Length enthält.

Dann, sobald die initiale Anfrage (blau) verarbeitet wurde und während die schlafende verarbeitet wird (gelb), wird die nächste Anfrage, die von einem Opfer eintrifft, in die Warteschlange direkt nach dem reflektierten Parameter angehängt:

Dann wird das Opfer die Antwort auf die schlafende Anfrage erhalten und wenn in der Zwischenzeit der Angreifer eine weitere Anfrage gesendet hat, wird die Antwort von der reflektierten Inhaltsanfrage an ihn gesendet.

Antwort Desynchronisation

Bis zu diesem Punkt haben wir gelernt, wie man HTTP Request Smuggling-Angriffe missbraucht, um die Anfrage zu kontrollieren, deren Antwort ein Client erhalten wird und wie Sie dann die Antwort stehlen können, die für das Opfer bestimmt war.

Aber es ist immer noch möglich, die Antworten noch weiter zu desynchronisieren.

Es gibt interessante Anfragen wie die HEAD-Anfrage, die spezifiziert, dass sie keinen Inhalt im Antwortkörper haben sollte und die den Content-Length der Anfrage wie bei einer GET-Anfrage enthalten muss.

Wenn ein Angreifer also eine HEAD-Anfrage injiziert, wie in diesen Bildern:

Dann, sobald die blaue beantwortet wird, wird die nächste Anfrage des Opfers in die Warteschlange eingeführt:

Dann wird das Opfer die Antwort von der HEAD-Anfrage erhalten, die einen Content-Length, aber keinen Inhalt enthält. Daher wird der Proxy diese Antwort nicht an das Opfer senden, sondern **auf etwas Inhalt warten, der tatsächlich die Antwort auf die gelbe Anfrage (die ebenfalls vom Angreifer injiziert wurde) sein wird:

Content Confusion

Folgendes Beispiel zeigt, dass Sie den Körper der Anfrage, deren Antwort das Opfer erhalten wird, kontrollieren können und dass eine HEAD-Antwort normalerweise in ihren Headern den Content-Type und den Content-Length enthält. Sie können eine Anfrage wie die folgende senden, um XSS im Opfer zu verursachen, ohne dass die Seite anfällig für XSS ist:

Cache Poisoning

Wenn Sie den zuvor kommentierten Angriff zur Desynchronisation der Antwort Content Confusion missbrauchen, wenn der Cache die Antwort auf die vom Opfer ausgeführte Anfrage speichert und diese Antwort eine injizierte ist, die ein 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:

Web Cache Deception

Dieser Angriff ist ähnlich wie der vorherige, aber anstatt ein Payload im Cache zu injizieren, wird der Angreifer Informationen des Opfers im Cache speichern:

Response Splitting

Das Ziel dieses Angriffs ist es, erneut die Antwort desynchronisation auszunutzen, um den Proxy dazu zu bringen, eine 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 einen 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 eingefügt:

Das Opfer erhält als Antwort die HEAD-Antwort + den Inhalt der Antwort der zweiten Anfrage (die einen Teil der reflektierten Daten enthält):

Beachten Sie jedoch, wie die reflektierten Daten eine Größe gemäß dem Content-Length der HEAD-Antwort hatten, die eine gültige HTTP-Antwort in der Antwortwarteschlange erzeugte.

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 cachen.