HTTP-Request-Smuggling: Teil 1 (Konzepte) (2024)

in einfachen Worten: Für Pen-Tester

Dies ist ein zweiteiliger Blog zum HTTP-Request-Smuggling. Teil 1 konzentriert sich auf das Verständnis der Grundkonzepte undTeil 2konzentriert sich auf die Identifizierung und Ausnutzung des HTTP-Request-Smugglings. Lass uns anfangen.

Die Sicherheitslücke beim Schmuggeln von HTTP-Anforderungen, ein alter Hase, tauchte wieder auf, als James Kettle, ein Sicherheitsforscher, im Jahr 2019 interessante Möglichkeiten fand, die Sicherheitslücke auszunutzen. Als ich seinen Aufsatz zum ersten Mal las, empfand ich es persönlich als schwierig und beschloss, es Schritt für Schritt anzugehen. Nach einiger Recherche wurde mir klar, dass alles, was dazu erforderlich ist, ein Verständnis einiger HTTP-Konzepte ist. Dieser Blog ist ein Versuch, das HTTP-Request-Smuggling und seine Konzepte so weit wie möglich zu vereinfachen. Lass uns gehen.

Bevor wir uns eingehend mit Request Smuggling und seinen Konzepten befassen, schauen wir uns an, wie wir uns schon immer eine Client-Server-Architektur vorgestellt haben:

Es gibt einen Client und einen Server, zuerst wird eine TCP-Verbindung aufgebaut, dann eine TLS und dann sendet man eine HTTP-Anfrage und bekommt vom Server eine HTTP-Antwort zurück. Gibt es hier ein Problem, hat sich etwas geändert? Nun ja, nichts allzu anderes, außer dass die Architektur in Echtzeit mehrschichtig ist.

Es gibt zwei Server, Front-End und Back-End. Der Front-End-Server ist im Allgemeinen ein Reverse-Proxy oder ein Load Balancer. Außerdem wird eine neue TCP-TLS-Verbindung zwischen dem Front-End-Server und dem Back-End-Server hergestellt, um HTTP-Anfragen auszutauschen.

Finden Sie nun, dass die Back-End-Server beim Austausch von HTTP-Anfragen etwas verdächtig sind? Nun, denken Sie weiter, während wir uns mit dem Verständnis einiger HTTP-Konzepte befassen.

OSI-Schichten, TCP/IP, es ist schon eine Weile her, nicht wahr? Gehen wir nun einen Schritt zurück und vertiefen unsere Netzwerkgrundlagen. HTTP ist ein Protokoll der Anwendungsschicht und TCP ist ein Protokoll der Transportschicht. HTTP ist nicht zuverlässig, was bedeutet, dass es Datenverluste nicht beheben kann, wohingegen TCP zuverlässig ist. Wenn also eine zuverlässige HTTP-Verbindung hergestellt werden muss, verlässt sich HTTP auf TCP. Bedeutet das nun, dass Sie für jede gestellte HTTP-Anfrage eine separate TCP-Verbindung benötigen? Nun, so hat alles angefangen.

HTTP/1.0, öffnet standardmäßig eine TCP-Verbindung für jede HTTP-Anfrage, die gestellt wird.

Dieses Verhalten könnte manuell geändert werden, wenn Sie das hinzugefügt habenVerbindung: Keep-AliveIn der Anfrage bleibt die TCP-Verbindung geöffnet oder was Sie als persistent bezeichnen, und HTTP-Anfragen können nacheinander gesendet werden.

InHTTP/1.1,Standardmäßig bleibt eine TCP-Verbindung bestehen und mehrere HTTP-Anfragen können über dieselbe Verbindung gesendet werden.

Alternative,Verbindung: schließenDer Header kann verwendet werden, um die Verbindung zu schließen, nachdem eine vollständige Antwort empfangen wurde oder nach einer Zeitüberschreitung.

Okay, jetzt wissen wir, dass HTTP/1.1 mehrere HTTP-Anfragen unter einer einzigen TCP-Verbindung zulässt. Lassen Sie uns hier innehalten und uns noch einmal unsere mehrstufige Client-Server-Architektur ansehen, insbesondere das Backend.

Es scheint auf HTTP 1.1 zu basieren, warum? Mehrere HTTP-Anfragen werden über dieselbe TCP-Verbindung gesendet, Bingo! Kommen wir zur nächsten neugierigen Frage: Wie unterscheidet der Backend-Server diese HTTP-Anfragen voneinander? Es war definitiv einfacher, wenn man für jede Anfrage eine separate TCP-Verbindung hatte, oder?

Beginnen wir mit GET-Anfragen.

ERHALTEN Sie https://abcdefsecurity.com/api/searchHTTP/1.1
Gastgeber: abcdefsecurity.com
Akzeptieren-Kodierung: gzip, entleeren
Akzeptieren-Sprache: en-GB,en-US;q=0,9,en;q=0,8

GET hat URL und Header. Die URL hat eine HTTP-/Versionsnummer, die das Ende angibt. Der Standard-Header und die Standardwerte werden vom Server verstanden und diejenigen, die der Server nicht versteht, werden einfach abgelehnt, sodass das Ende der Header das Ende einer GET-Anfrage markiert. GET-Anfragen scheinen kein großes Problem zu sein, nicht wahr?

Wie wäre es mit POST-Anfragen? Der POST-Körper kann von Anwendung zu Anwendung, von Framework zu Framework variieren. Nun, hier kommen die folgenden HTTP-Header zum Einsatz.

• Inhaltslänge
• Übertragungskodierung: Chunked

Hinweis – Die oben genannten Header gelten für HTTP/1.1 und teilweise für HTTP/1.0, jedoch nicht für HTTP/2.

Dieser Header berechnet die Inhaltslänge des POST BODY einschließlich der CRLF-Zeichen (\r\n). Im folgenden Beispiel entspricht die Gesamtzahl der Zeichen des POST BODY „search=http“ dem Wert von Content-Length, der 11 beträgt.

Betrachten Sie das folgende Beispiel, in dem der POST-KÖRPER eine zusätzliche Leerzeile unter seinem Körper hat. In diesem Fall werden die neuen Zeilenzeichen „\r\n“ als zwei zusätzliche Zeichen berechnet, daher beträgt die Inhaltslänge 13.

Alternativ wird der Transfer-Encoding-Header beim Hochladen von Dateien verwendet, wenn Sie Datenblöcke hochladen möchten. Neben dem Header wird auch erwartet, dass der Textkörper ein bestimmtes Format hat.

„Upload testen“ ist der Blockinhalt, seine Länge beträgt 14. E ist der HEX-Wert von 14 und nach „0“ gibt es eine Zeile, die das Ende der Nachricht markiert. Es kann mehrere solcher Chunks geben.

Hinweis – Mit HTTP 1.1 können Sie sowohl Content-Length- als auch Transfer-Encoding-Header in derselben Anfrage senden. Wenn jedoch beide gesendet werden, hat Transfer-Encoding Vorrang.

Fassen wir das alles in ein Bild: Wir haben in HTTP/1.1 gelernt, dass eine einzelne TCP-Verbindung bestehen bleibt und mehrere HTTP-Anfragen unter derselben Verbindung gesendet werden können. Der Backend-Server kann diese Anfragen anhand der Header Content-Length (CL) und Transfer-Encoding (TE) unterscheiden. Jetzt können Sie sehen, dass jeder Server über eine Möglichkeit verfügt, das Ende von Anforderungen zu identifizieren.

Es ist perfekt, beide Server verwenden entweder Content-Length oder Transfer-Encoding, um das Ende einer Anfrage zu markieren. Moment, wir sind Penetrationstester und wir wollen Unvollkommenheit und wir sind neugierig. Was passiert also, wenn es zu einer Verwechslung kommt, wenn ein Server CL und ein anderer TE akzeptiert oder umgekehrt:

Nun, das ist genau das Angriffsszenario des HTTP-Request-Smugglings. Machen Sie nun eine Pause und überlegen Sie, was Sie getan hätten, wenn es ein solches Szenario gegeben hätte.

PAUSE.

Als Penetrationstester möchte man nun beide Header zusammen in der Anfrage senden und sehen, wie die Server sie verarbeiten. Schauen Sie sich alle möglichen Kombinationen an:

• Wenn beide Header gesendet werden, lehnt der Front-End-Server die Anfrage ab (erwartetes Verhalten und sicher).
• Wenn beide Header gesendet werden, hat TE Vorrang, wo es sein muss, und der andere Server lehnt es ab (sicher)

Welche unsicheren Optionen könnten uns einfallen?

• (CL, TE)– Der Front-End-Server ignoriert TE und verarbeitet es als CL, die Anfrage geht an das Back-End und wird als TE verarbeitet
• (TE, CL) -Der Front-End-Server ignoriert CL und verarbeitet es als TE, die Anfrage geht an das Back-End und wird als CL verarbeitet
• (DIE ... DIE) -Sowohl der Front-End-Server als auch der Back-End-Server akzeptieren TE, aber einer der Server kann es nicht verarbeiten

Damit die oben genannten Szenarien funktionieren, funktioniert die Standardmethode zum Senden beider Header jedoch nicht, denn wenn wir beide Header senden, hätte entweder TE Vorrang oder die Anfrage würde abgelehnt, da die meisten Systeme dafür ausgelegt sind. Wir müssen beide Header senden, aber in einer Weise, dass einer dieser Header nicht vom Front-End-Server gelesen werden kann, klingt das interessant, oder? Hier hat James Kettle seine Nachforschungen angestellt und mehrere Payloads für den Transfer-Encoding-Header gefunden, die beim Senden dazu führten, dass der Front-End-Server den Header nicht verarbeiten konnte.

NUTZLASTÜbertragungskodierung: ChunkedÜbertragungskodierung: xchunkedÜbertragungskodierung: ChunkedÜbertragungskodierung: Chunked
Übertragungskodierung: xund viele mehr

Die Unterschiede in jeder dieser Nutzlasten sind winzig und subtil. Nehmen wir zum Beispiel die erste, da ist nur ein Leerzeichen vor dem Header, großartig, oder?)

Nun die Millionen-Dollar-Frage: Was machen wir damit und was ist HTTP-Request-Smuggling?

Nehmen wir zum besseren Verständnis die einfachere Option. Denken Sie daran, wie wir bei Transfer-Encoding mehrere Datenblöcke in derselben Anfrage senden könnten. Was wäre, wenn wir tatsächlich eine andere HTTP-Anfrage als Block senden würden, wie unten, aber den Block nicht wie erwartet schließen würden:

Was würde nun mit der Warteschlange passieren, wenn wir diese Anfrage senden?

• Inmitten der Anfrage von Benutzer Blau und Grün sendet Benutzer Rot eine böswillige Anfrage wie oben im Bild – „Schmuggel-Nutzlast anfordern“. Die Anfrage enthält am Ende eine zusätzliche /404.html-Anfrage. Beachten Sie jedoch, dass der Block nicht ordnungsgemäß mit einer 0 und einer neuen Zeile geschlossen wird.
• Der Front-End-Server berechnet die Content-Length und ignoriert aufgrund des „Leerraums“ den Transfer-Encoding-Header. Laut Front-End-Server handelt es sich also um eine Anfrage, aber eigentlich sind es zwei/404.html-Anfrage wird hier in die Warteschlange geschmuggelt :)
• Der Back-End-Server holt nun den Transfer-Encoding-Header ab, verarbeitet den ersten Block, und wenn er zum nächsten Block übergeht, liest er den Block, aber da er keine „0“ und keine neue Zeile danach hat, bleibt der Block unverarbeitet und wird an die nächste eingehende Anfrage angehängt.

Random-Header maskiert den Pfad der neuen Anfrage. Jetzt erhält Benutzer Green /404.html, wenn der Benutzer tatsächlich /account angefordert hat.

Da dadurch auch die Warteschlange desynchronisiert wurde, in der die Antworten idealerweise in der Reihenfolge ihres Eingangs bereitgestellt wurden, und dies nun nicht mehr der Fall ist, wird dies auch als HTTP-De-Sync-Angriff bezeichnet.

Sie können jetzt lesenTeil 2meines Blogs, um HTTP-Request-Smuggling zu identifizieren und auszunutzen!

Ich hoffe, es hat Ihnen Spaß gemacht, den Blog zu lesen :) Senden Sie CLAPss, wenn es Ihnen gefallen hat. Guten Tag !

Verweise:

• https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn
• https://portswigger.net/web-security/request-smuggling