TL;DR
Das Schmuggeln von HTTP-Anfragen ist kein neues Problem.ein Whitepaper von Watchfire aus dem Jahr 2005bespricht es im Detail und es gibtandere Ressourcenzu. Was meiner Meinung nach fehlte, waren praktische, umsetzbare Anleitungen.
Dieser Beitrag behandelt meine Erkenntnisse und wirft hoffentlich etwas Licht auf die Feinheiten des HTTP-Request-Smugglings.
Einführung
Ich habe einige Nachforschungen angestellt, während ich eine Webanwendung getestet habe, die anfällig für HTTP Request Smuggling zu sein schien. Anstatt nur die Schwachstelle zu identifizieren und dem Kunden ihre Existenz zu beweisen, wollte ich sie auch in der Praxis demonstrieren.
Angriffsmethoden
Es gibt zahlreiche Angriffsmethoden, die HTTP Request Smuggling nutzen. Zum Beispiel; Cross-Site Scripting (XSS), bei dem der Angreifer einen beliebigen Benutzer der Anwendung ins Visier nimmt, anstatt einen Benutzer direkt ins Visier zu nehmen. Session-Hijacking (demonstriert im Abschnitt „Ausnutzung“ dieses Beitrags, etwa in der Mitte der Seite). Manchmal ist Server-Side Request Forgery (SSRF) möglich. Die Liste geht weiter und darüber hinaus glaube ich, dass es noch andere Angriffsmethoden gibt, die noch erforscht werden müssen.
Es gibt auch verschiedene Varianten des Request Smuggling, die durch die Abkürzungen bekannt sind, die die beim Angriff verwendeten Header symbolisieren. Dies sind: CL:CL CL:TE TE:TE und TE:CL. Der CL steht für den Header-Wert Content-Length und der TE-Wert für den Header Transfer-Encoding. Um die Komplexität zu reduzieren, werden nur Einzelheiten zu einer Methode des Anforderungsschmuggels bereitgestellt.
Die Methode des HTTP-Request-Smugglings, die ich in diesem Artikel demonstrieren werde, ist als CL:TE bekannt und mit dieser Methode werde ich Back-End Socket Poisoning durchführen.
Suche nach Anforderungsschmuggel
Beim Durchsuchen einer Webanwendung mit dem Burp Suite-Webproxy stellen Sie möglicherweise fest, dass HTTP Request Smuggling auf der Registerkarte „Dashboard“ markiert ist. Dies wird oft übersehen oder aufgrund mangelnden Verständnisses als falsch positiv gewertet.
Es ist wahr, dass es manchmal schwierig sein kann, diese Sicherheitslücke auszunutzen und zu demonstrieren, aber mit diesem Artikel hoffe ich, dass das Konzept klar wird.
Schauen wir uns zunächst an, wie HTTP Request Smuggling von Burp Suite gemeldet wird.
Burp kennzeichnet dies als HTTP Request Smuggling, wenn es Anfragen mit fehlerhaften Content-Length- und Transfer-Encoding-Headern sendet. Wenn bei einer dieser Antworten eine Zeitüberschreitung auftritt, markiert Burp dies als HTTP Request Smuggling.
Wie im Screenshot unten zu sehen ist, verfügt die Anfrage über keine Registerkarte „Antwort“, was darauf hinweist, dass die Anfrage abgelaufen ist und ein HTTP-Request-Smuggling vorliegt.
Der Beweis, dass es da ist
Sobald Burp den HTTP-Request-Smuggling gemeldet hat, müssen wir bestätigen, dass es tatsächlich vorhanden ist und es sich nicht um ein falsches Positiv handelt.
Der Vorgang zum Senden einer gültigen Anfrage ist im folgenden Diagramm dargestellt:
Wie oben zu sehen ist, wird eine gültige Anfrage gesendet. Das Front-End schreibt die Anfrage neu und fügt Header hinzu, die das Back-End erwartet. Das Backend verarbeitet diese Anfrage und gibt die erwartete Antwort zurück.
Um also festzustellen, dass wir HTTP Request Smuggling gefunden haben, müssen wir eine fehlerhafte Anfrage senden. Dazu fügen wir im folgenden Beispiel ein Leerzeichen zwischen dem Header „Transfer-Encoding“ und dem darauffolgenden Doppelpunkt ein. Das Frontend ignoriert „Transfer-Encoding: chunked“ und verwendet die „Content-Length“, um zu bestimmen, ob die Anfrage gültig ist. Das Front-End schreibt dann den Header neu und entfernt den Platz, wodurch dieser Transfer-Encoding-Header in der Anfrage an das Back-End gültig wird. In diesem Beispiel hat der Header „Transfer-Encoding“ Vorrang vor dem Header „Content-Length“, wenn er im Back-End ankommt.
Das folgende Diagramm veranschaulicht dies:
Theorie in die Praxis umsetzen!
Der folgende Screenshot zeigt eine böswillige Anfrage. Wir haben unseren fehlerhaften „Transfer-Encoding“-Header; Am Anfang des Anfragetextes steht die Null, um die Anfrage am Back-End zu beenden, und außerdem das „X“, das zum Vergiften des Back-End-Sockets verwendet wird.
Wenn wir dies in Intruder laden und in der Antwort nach einem „405“-Fehler suchen, ist dies ein Indikator dafür, dass wir den Back-End-Socket mit unserer ersten Anfrage erfolgreich vergiftet haben.
Wie oben zu sehen ist, wird die Antwort „405-Methode nicht zulässig“ angezeigt. Dies liegt daran, dass die nächste Anfrage als „XPOST / HTTP/1.1“ gestartet wurde und daher keine gültige Anfrage ist.
Dies ist die Bestätigung, dass wir einen Schmuggelantrag haben!
PoC und Ausbeutung
Ja! Der lustige Teil!
Nach dem, was ich gelesen habe, gibt es eine Vielzahl von Exploits, die beim Schmuggel von Anfragen genutzt werden können. Zu diesen Angriffen gehören:
- Reflektiertes XSS auf standortweites XSS!
- Session-Hijacking und Account-Übernahme!
- SSRF
- Cache-Vergiftung
- Offenlegung der Neuformulierung von Front-End-Anfragen
Die Ausnutzungsmethode, die ich in den folgenden Beispielen demonstriere, ist die Sitzungsentführung und Kontoübernahme.
Durch das Schmuggeln von Anfragen geht dies jedoch verloren und diese Cookies sind nicht mehr geschützt!
Diese Methode zeigt auch das Umschreiben der Front-End-Anfrage an.
Um den HTTP-Anforderungsschmuggel auszunutzen und eine Sitzung zu kapern, sind einige Voraussetzungen erforderlich:
- CL:TE Socket-Vergiftung.
- Ein Teil der Anfrage sollte sich in der Antwort widerspiegeln.
Wir müssen eine Anfrage finden, bei der sich ein Teil der Anfrage in der Antwort widerspiegelt. In diesem Beispiel habe ich den Parameter „maincontent_0%24firstname=“ verschoben und ihn durch den letzten Parameter in der Anfrage ersetzt.
Der spätere Abschnitt unserer POST-Anfragenutzlast mit „maincontent_0%24firstname=“ als letztem Parameter in der Anfrage:
Überprüfen Sie, ob die Antwort auf diese POST-Anfrage dazu führt, dass die X-Zeichenfolge in der Antwort gerendert wird. Wenn die Zeichenfolge gerendert wird, ist dies das Feld im Antworttext, in dem wir die Anfrage unseres ausgenutzten Benutzers finden.
Der Screenshot unten bestätigt, dass alles im letzten Parameterfeld unserer POST-Anfrage im Antworttext gerendert wird.
Nun das:
- Wir haben bestätigt, dass wir den Backend-Socket vergiften können
- Sie verfügen über eine gültige POST-Anfrageparametereingabe, die im Antworttext gerendert wird
Wir können diese Anfrage dann schmuggeln und sie bleibt übrig, um den Back-End-Socket zu vergiften. Die nächste Anfrage an den Server wird dann an unsere geschmuggelte Anfrage angehängt und im gleichen Antworttext wie oben gezeigt an uns zurückgesendet.
Schauen wir uns zunächst unsere Anfrage an, die unsere geschmuggelte Nutzlast unten enthalten wird (in blauer Schrift):
Wie oben zu sehen ist, ist die erste Anfrage in der Anfrage-Pipeline hier eine gültige Post-Anfrage. Das zweite, in Blau, ist unsere geschmuggelte Nutzlast.
Ich habe die Inhaltslänge in der geschmuggelten Nutzlast hervorgehoben, da wir mehr Inhaltslänge als im Anfragetext hinzufügen möchten. Dies liegt daran, dass wir der ausgenutzten Benutzeranfrage etwas Platz geben müssen, damit sie sich im Hauptteil der Antwort platzieren kann.
Ausbeutung
Wir laden unsere Anfrage mit Payload in Intruder. Während der Ausführung werden wir Antwortinhaltslängen sehen, die sich in der Größe unterscheiden. Bei einigen wird es sich um Intruder handeln, die unsere eigene Antwort zurücksenden, während wir aufeinanderfolgende Anfragen senden. Wenn jedoch ein ahnungsloser Benutzer die Anwendung nutzt, erfassen wir die von ihm gesendeten Anfragen. Diese von ihnen gesendeten Anfragen werden an das Ende unserer Nutzlast geschrieben und im Antworttext widergespiegelt, den wir erhalten.
Unten sehen Sie die Ausgabe von Intruder. Die unterschiedlichen Längen der zurückgegebenen Antworten weisen darauf hin, dass wir Benutzer erfolgreich ausgenutzt haben, sofern sie die Anwendung zur gleichen Zeit verwendet haben, als wir den Exploit in Intruder ausgeführt haben.
Wenn wir uns eine der Antworten ansehen, die wir in Intruder finden, können wir sehen, dass die Anfrage eines Benutzers an unsere Nutzlast angehängt wurde. Der folgende Screenshot zeigt eine GET-Anfrage eines Benutzers, bei der die Anfrage vollständig in unserem Antworttext gerendert wird.
Sofern also jemand die Anwendung nutzt, besteht keine Notwendigkeit, einen bestimmten Benutzer anzusprechen. Wenn die Nutzlast in Intruder ausgeführt wird und jemand eine Anfrage an den Server sendet, erfassen wir die Anfrage. Es wird unserer geschmuggelten Anfrage beigefügt, wo wir dann ihr Sitzungscookie stehlen und ihr Konto kapern können.
Abschluss
Wenn Sie dies also das nächste Mal in Burp sehen, werfen Sie einen genaueren Blick darauf und überlegen Sie, ob Sie es ausnutzen könnten. Auch das Schmuggeln von HTTP-Anfragen kann ein Bug-Bounty-Cashcow sein, da es wenig verstanden wird und kaum darüber berichtet wird.
