hacktricks/pentesting-web/http-response-smuggling-desync.md

HTTP Response Smuggling / Desync

Lernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

• Wenn Sie Ihr Unternehmen in HackTricks bewerben möchten oder HackTricks als PDF herunterladen möchten, überprüfen Sie die ABONNEMENTPLÄNE!
• Holen Sie sich das offizielle PEASS & HackTricks-Merchandise
• Entdecken Sie The PEASS Family, unsere Sammlung exklusiver NFTs
• Treten Sie der 💬 Discord-Gruppe oder der Telegramm-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @carlospolopm.
• Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud Github-Repositories senden.

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

Desynchronisation der HTTP-Anforderungs-Warteschlange

Zunächst einmal 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 wir anstatt den Angriff auf die Anforderung des Opfers durch das Hinzufügen eines Präfixes durchführen, die Antwort, die das Opfer erhält, durchsickern lassen oder modifizieren. Dies geschieht, indem wir anstelle von 1,5 Anfragen, um den HTTP-Anforderungsschmuggel auszunutzen, 2 vollständige Anfragen senden, um die Warteschlange der Proxy-Antworten 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 der Antwort an das Opfer vom Angreifer kontrollierter Inhalt eingefügt wird.

Desynchronisation der HTTP-Pipeline

HTTP/1.1 ermöglicht es, verschiedene Ressourcen anzufordern, ohne auf vorherige Ressourcen warten zu müssen. Wenn sich also ein Proxy dazwischen befindet, ist es die Aufgabe des Proxys, eine synchronisierte Übereinstimmung der Anfragen, die an das Backend gesendet werden, und der Antworten, die von dort kommen, aufrechtzuerhalten.

Es gibt jedoch ein Problem bei der Desynchronisierung der Antwortwarteschlange. Wenn ein Angreifer einen HTTP-Antwortschmuggelangriff sendet und die Antworten auf die ursprüngliche Anforderung und die geschmuggelte Anforderung sofort beantwortet werden, wird die geschmuggelte Antwort nicht in die Warteschlange der Opferantwort 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. Wenn die geschmuggelte Anforderung in dieser speziellen Situation beantwortet wird, bevor das legitime Opfer die Anforderung gesendet hat, wird die geschmuggelte Antwort an das Opfer gesendet. Der Angreifer wird daher die Anforderung "ausführen", die das Opfer durchführt.

Darüber hinaus, wenn der Angreifer dann eine Anforderung ausführt und die legitime Antwort auf die Anforderung des Opfers vor dem 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).

Mehrfache 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 es eine unerwartete Aktion ausführt. Bei einem HTTP-Antwortschmuggelangriff können Sie jedoch vollständige Anfragen senden, sodass Sie in einem Payload mehrere Antworten injizieren können, die mehrere Benutzer desynchronisieren, die die injizierten Antworten empfangen.

Neben der Möglichkeit, mehrere Exploits leichter auf legitime Benutzer zu verteilen, könnte dies auch dazu verwendet werden, einen DoS-Angriff auf den Server auszuführen.

Exploit-Organisation

Wie bereits erklärt, ist es für den Missbrauch dieser Technik erforderlich, dass die erste geschmuggelte Nachricht in den Server viel Zeit benötigt, um verarbeitet zu werden.

Diese zeitintensive Anforderung reicht aus, wenn wir nur die Antwort des Opfers stehlen möchten. Wenn Sie jedoch einen komplexeren Exploit durchführen möchten, wird dies eine gängige Struktur für den Exploit sein.

Zunächst die anfängliche Anforderung, die den HTTP-Anforderungsschmuggel ausnutzt, dann die zeitintensive Anforderung und dann 1 oder mehrere Payload-Anforderungen, deren Antworten an die Opfer gesendet werden.

Missbrauch der Desynchronisation der HTTP-Antwortwarteschlange

Erfassen von Anforderungen anderer Benutzer

Wie bei bekannten Payloads für den HTTP-Anforderungsschmuggel können Sie die Anforderungen des Opfers stehlen, jedoch mit einem wichtigen Unterschied: In diesem Fall benötigen Sie nur den gesendeten Inhalt, der in der Antwort reflektiert wird, es ist kein persistenter Speicher erforderlich.

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

Dann, sobald die anfängliche Anforderung (blau) verarbeitet wurde und während die schläfrige Anforderung (gelb) verarbeitet wird, 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.

Desynchronisation der Antwort

Bis zu diesem Punkt haben wir gelernt, wie man den HTTP-Anforderungsschmuggelangriff missbraucht, um die Anforderung zu kontrollieren, deren Antwort ein Client erhalten wird, und wie man dann die Antwort stiehlt, 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, bei denen angegeben ist, dass kein Inhalt im Antwortkörper enthalten ist und dass sie (müssen) **die Content-Length

Verwirrung des Inhalts

Nach dem vorherigen Beispiel, wissend dass du den Inhalt des Anfragekörpers kontrollieren kannst, dessen Antwort der 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 Angriffs auf die Desynchronisation der Antwort "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 mit dem XSS-Payload:

Bösartige Antwort an das Opfer, die den Header enthält, der dem Cache anzeigt, die Antwort zu speichern:

{% hint style="warning" %} Beachte, dass in diesem Fall, wenn das "Opfer" der Angreifer ist, er jetzt Cache-Vergiftung in beliebigen URLs durchführen kann, da er die URL kontrollieren kann, die mit der bösartigen Antwort zwischengespeichert wird. {% endhint %}

Web-Cache-Täuschung

Dieser Angriff ist ähnlich wie der vorherige, aber statt einen Payload in den Cache einzufügen, wird der Angreifer Opferinformationen im Cache zwischenspeichern:

Antwort-Splitting

Das Ziel dieses Angriffs ist es erneut, die Desynchronisation der Antwort auszunutzen, um einen 100%ig vom Angreifer generierten Antwort an den Proxy zu senden.

Um dies zu erreichen, muss der Angreifer einen Endpunkt der Webanwendung finden, der einige Werte in der Antwort reflektiert und die Länge des Inhalts 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 aufgenommen:

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

Beachte jedoch, wie die reflektierten Daten eine Größe entsprechend der 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 zwischenspeichern.

Lerne AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

• Wenn du dein Unternehmen in HackTricks bewerben möchtest oder HackTricks als PDF herunterladen möchtest, sieh dir die ABONNEMENTPLÄNE an!
• Hol dir das offizielle PEASS & HackTricks-Merchandise
• Entdecke The PEASS Family, unsere Sammlung exklusiver NFTs
• Trete der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folge uns auf Twitter 🐦 @carlospolopm.
• Teile deine Hacking-Tricks, indem du PRs an die HackTricks und HackTricks Cloud GitHub-Repos sendest.