mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
133 lines
9.3 KiB
Markdown
133 lines
9.3 KiB
Markdown
# HTTP Response Smuggling / Desync
|
|
|
|
{{#include ../banners/hacktricks-training.md}}
|
|
|
|
**Die Technik dieses Beitrags stammt aus dem Video:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](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**.
|
|
|
|
.png>)
|
|
|
|
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).
|
|
|
|
.png>)
|
|
|
|
.png>)
|
|
|
|
### 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 <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
|
|
|
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.
|
|
|
|
.png>)
|
|
|
|
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**:
|
|
|
|
.png>)
|
|
|
|
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:
|
|
|
|
.png>)
|
|
|
|
Dann, **sobald die blaue beantwortet wird**, wird die nächste Anfrage des Opfers in die Warteschlange eingeführt:
|
|
|
|
.png>)
|
|
|
|
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:
|
|
|
|
.png>)
|
|
|
|
### 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:
|
|
|
|
.png>)
|
|
|
|
### 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:
|
|
|
|
.png>)
|
|
|
|
Bösartige Antwort an das Opfer, die den Header enthält, der dem Cache anzeigt, die Antwort zu speichern:
|
|
|
|
.png>)
|
|
|
|
> [!WARNING]
|
|
> Beachten Sie, dass in diesem Fall, wenn das **"Opfer" der Angreifer ist**, er jetzt **Cache Poisoning in beliebigen URLs** durchführen kann, da er **die URL, die mit der bösartigen Antwort zwischengespeichert werden soll, kontrollieren kann**.
|
|
|
|
### 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:**
|
|
|
|
.png>)
|
|
|
|
### 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:
|
|
|
|
.png>)
|
|
|
|
Nachdem die erste Anfrage gelöst und an den Angreifer zurückgesendet wurde, wird die **Anfrage des Opfers in die Warteschlange eingefügt**:
|
|
|
|
.png>)
|
|
|
|
Das Opfer erhält als Antwort die **HEAD-Antwort + den Inhalt der Antwort der zweiten Anfrage (die einen Teil der reflektierten Daten enthält):**
|
|
|
|
.png>)
|
|
|
|
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**.
|
|
|
|
{{#include ../banners/hacktricks-training.md}}
|