HTTP Response Smuggling / Desync
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Die Technik dieses Beitrags wurde aus dem Video entnommen: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
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/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. 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).
Ein weiterer interessanter Unterschied zu gängigem HTTP Request Smuggling ist, dass in einem gängigen Schmuggelangriff das Ziel darin besteht, den Anfang 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 in der Lage bist, Dutzende von Exploits leichter über legitime Benutzer zu verteilen, könnte dies auch verwendet werden, um einen DoS auf dem Server zu verursachen.
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.
Wie bei bekannten Payloads für HTTP Request Smuggling kannst du die Anfrage des Opfers stehlen mit einem wichtigen Unterschied: In diesem Fall musst du nur sicherstellen, dass der gesendete Inhalt in der Antwort reflektiert wird, 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.
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:
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.
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:
Dann, sobald die blaue an den Angreifer 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 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:
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, kannst du eine Anfrage wie die folgende senden, um XSS im Opfer zu verursachen, ohne dass die Seite anfällig für XSS ist:
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:
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 das "Opfer" der Angreifer ist, er jetzt Cache-Poisoning in beliebigen URLs durchführen kann, da er die URL, die im Cache gespeichert werden soll, mit der bösartigen Antwort kontrollieren kann.
Dieser Angriff ist ähnlich wie der vorherige, aber anstatt ein Payload im Cache zu injizieren, wird der Angreifer Informationen des Opfers im Cache speichern:
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):
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.
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
