mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-29 08:01:00 +00:00
159 lines
12 KiB
Markdown
159 lines
12 KiB
Markdown
# HTTP Response Smuggling / Desync
|
|
|
|
{% hint style="success" %}
|
|
Lerne & übe AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Lerne & übe GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Support HackTricks</summary>
|
|
|
|
* Überprüfe die [**Abonnementpläne**](https://github.com/sponsors/carlospolop)!
|
|
* **Tritt der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folge** uns auf **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Teile Hacking-Tricks, indem du PRs zu den** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repos einreichst.
|
|
|
|
</details>
|
|
{% endhint %}
|
|
|
|
**Die Technik dieses Beitrags wurde aus dem Video entnommen:** [**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 musst du wissen, was das ist:
|
|
|
|
Der **Hauptunterschied** zwischen dieser Technik und einem gängigen HTTP Request Smuggling ist, dass wir **anstatt** die **Anfrage** des **Opfers** **zu attackieren**, indem wir ein Präfix hinzufügen, **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**. Daher wird, während die geschmuggelte Anfrage verarbeitet 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 **Opferanfrage** **bevor** die Anfrage des Angreifers **beantwortet wird**. 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>)
|
|
|
|
### Mehrfache geschachtelte Injektionen
|
|
|
|
Ein weiterer **interessanter Unterschied** zu gängigem **HTTP Request Smuggling** ist, dass in einem gängigen Schmuggelangriff das **Ziel** darin besteht, den **Beginn der Anfrage des Opfers zu modifizieren**, sodass sie eine unerwartete Aktion ausführt. In einem **HTTP Response Smuggling-Angriff**, da du **vollständige Anfragen sendest**, kannst du **in einem Payload Dutzende von Antworten injizieren**, die **Dutzende von Benutzern desynchronisieren**, die die **injizierten** **Antworten** **erhalten**.
|
|
|
|
Abgesehen davon, dass du **viel einfacher Dutzende von Exploits** über legitime Benutzer verteilen kannst, könnte dies auch verwendet werden, um einen **DoS** auf dem Server zu verursachen.
|
|
|
|
### Exploit-Organisation
|
|
|
|
Wie zuvor erklärt, 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 du einen komplexeren Exploit durchführen möchtest, wird dies eine gängige Struktur für den Exploit sein.
|
|
|
|
Zunächst die **anfängliche** 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 kannst du **die Anfrage des Opfers stehlen** mit einem wichtigen Unterschied: In diesem Fall musst du nur den **gesendeten Inhalt reflektiert in der Antwort haben**, **kein persistenter Speicher** 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 **anfängliche Anfrage** (blau) **verarbeitet** wurde und **während** die **schlafende** (gelb) verarbeitet wird, 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**.
|
|
|
|
## Antwortdesynchronisation
|
|
|
|
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 du dann die **Antwort stehlen kannst, 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 **HEAD**-Anfragen, die spezifiziert sind, um **keinen Inhalt im Antwortkörper** zu haben und die **den Content-Length** der Anfrage enthalten sollten, als ob es eine GET-Anfrage wäre.
|
|
|
|
Daher, wenn ein Angreifer eine **HEAD**-Anfrage **injiziert**, wie in diesen Bildern:
|
|
|
|
.png>)
|
|
|
|
Dann, **sobald die blaue an den Angreifer 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 enthalten wird, aber keinen Inhalt**. Daher wird der Proxy **diese Antwort nicht an das Opfer senden**, sondern wird **auf etwas** **Inhalt** warten, der tatsächlich die **Antwort auf die gelbe Anfrage** (auch vom Angreifer injiziert) sein wird:
|
|
|
|
.png>)
|
|
|
|
### Inhaltsverwirrung
|
|
|
|
Folgendes Beispiel zeigt, dass du **den Körper** der Anfrage kontrollieren kannst, deren Antwort das Opfer erhalten wird, und dass eine **HEAD**-**Antwort** normalerweise in ihren Headern den **Content-Type und den Content-Length** enthält. Du kannst **eine Anfrage wie die folgende senden**, um XSS im Opfer zu verursachen, ohne dass die Seite anfällig für XSS ist:
|
|
|
|
.png>)
|
|
|
|
### Cache-Vergiftung
|
|
|
|
Wenn du den zuvor kommentierten Angriff der Antwortdesynchronisation mit Inhaltsverwirrung missbrauchst, **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>)
|
|
|
|
{% hint style="warning" %}
|
|
Beachte, dass in diesem Fall, wenn das **"Opfer" der Angreifer ist**, er jetzt **Cache-Vergiftungen in beliebigen URLs** durchführen kann, da er **die URL, die im Cache gespeichert werden soll, mit der bösartigen Antwort kontrollieren kann**.
|
|
{% endhint %}
|
|
|
|
### Web-Cache-Täuschung
|
|
|
|
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>)
|
|
|
|
### Antwortsplitting
|
|
|
|
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>)
|
|
|
|
Beachte 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**.
|
|
|
|
{% hint style="success" %}
|
|
Lerne & übe AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Lerne & übe GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Support HackTricks</summary>
|
|
|
|
* Überprüfe die [**Abonnementpläne**](https://github.com/sponsors/carlospolop)!
|
|
* **Tritt der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folge** uns auf **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Teile Hacking-Tricks, indem du PRs zu den** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repos einreichst.
|
|
|
|
</details>
|
|
{% endhint %}
|