Tools zur Erkennung von HTTP/1-Desync-Schwachstellen

Dieses Repository enthält defensive Sicherheitstools zur Erkennung von HTTP/1-Request-Smuggling-Desync-Schwachstellen, basierend auf bahnbrechender Forschung von James Kettle (PortSwigger).

Forschungsattribution

Diese Arbeit wurde direkt inspiriert von und implementiert Techniken aus:

• „HTTP/1 Must Die“ von James Kettle (PortSwigger Research)
  • Originalforschung: https://portswigger.net/research/http1-must-die
  • Forscher: James Kettle (@albinowax)
  • Unternehmen: PortSwigger Web Security

Die Angriffsmuster, Techniken und Erkennungsmethoden, die in diesen Tools implementiert sind, basieren auf James Kettles bahnbrechender Arbeit, die grundlegende Schwachstellen in der Implementierung des HTTP/1.1-Protokolls bei großen Web-Infrastrukturanbietern aufdeckte.

Auswirkungen der Forschung

James Kettles Forschung deckte Schwachstellen auf, die folgende Anbieter betrafen:

• Cloudflare, T-Mobile, GitLab, Netlify, Akamai
• Erzielte Prämien von über 350.000 US-Dollar durch Bug-Bounties
• Führte zu kritischen Infrastruktur-Fixes im gesamten Web

Überblick

Die mehrdeutigen Anfragegrenzen von HTTP/1.1 erzeugen das, was James Kettle als „extreme Mehrdeutigkeit“ bezeichnete, wo Anfragen beginnen und enden. Dies führt zu Parser-Diskrepanzen zwischen Front-End- und Back-End-Servern und ermöglicht ausgefeilte Request-Smuggling-Angriffe. Diese Tools helfen, solche Schwachstellen für defensive Sicherheitstests zu identifizieren.

Enthaltene Tools

1. Go-Testtool (http1-desync-test.go)

Ein umfassender HTTP/1-Desync-Schwachstellentester, der mehrere Angriffsmuster implementiert.

Funktionen

• V-H (Visible-Hidden) Desync: Testet auf sichtbare-versteckte Parser-Diskrepanzen
• 0.CL (Zero Content-Length) Desync: Nutzt Unterschiede in der Behandlung von Content-Length: 0 aus
• Expect-Header-Desync: Verwendet Expect: 100-continue für Request-Smuggling
• Double-Desync: Testet auf Schwachstellen bezüglich Response-Queue-Poisoning
• CL.TE-Desync: Testet auf Konflikte zwischen Content-Length und Transfer-Encoding

Installation

# Repository klonen
git clone https://github.com/nconsolo/echteeteepee.git
cd echteeteepee

# Abhängigkeiten installieren
go mod download

# Tool bauen
go build -o http1-desync-test http1-desync-test.go

Verwendung

# Alle Angriffsmuster testen
./http1-desync-test -target https://example.com

# Spezifisches Angriffsmuster testen
./http1-desync-test -target https://example.com -test vh

# Ausführliche Ausgabe aktivieren
./http1-desync-test -target https://example.com -verbose

# Benutzerdefiniertes Timeout setzen
./http1-desync-test -target https://example.com -timeout 10s

Befehlszeilenoptionen

• -target: Ziel-URL (erforderlich)
• -test: Testtyp: all, vh, 0cl, expect, double, clte (Standard: all)
• -timeout: Request-Timeout (Standard: 5s)
• -verbose: Ausführliche Ausgabe aktivieren, um rohe Anfragen/Antworten zu sehen

2. Nuclei-Template (nuclei-templates/http1-desync.yaml)

Automatisiertes Scan-Template für Nuclei zur Erkennung von HTTP/1-Desync-Schwachstellen im großen Maßstab.

Installation

# Nuclei installieren (falls nicht bereits geschehen)
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

# Template in das Nuclei-Templates-Verzeichnis kopieren
cp nuclei-templates/http1-desync.yaml ~/.nuclei-templates/

Verwendung

# Einzelnes Ziel scannen
nuclei -u https://example.com -t nuclei-templates/http1-desync.yaml

# Mehrere Ziele scannen
nuclei -l targets.txt -t nuclei-templates/http1-desync.yaml

# Mit Ratenbegrenzung scannen
nuclei -u https://example.com -t nuclei-templates/http1-desync.yaml -rl 10

Erläuterung der Angriffsmuster

Alle Angriffsmuster basieren auf James Kettles Forschungsergebnissen und nachgewiesenen Exploit-Techniken.

V-H (Visible-Hidden) Desync

Quelle: James Kettles Forschung „HTTP/1 Must Die“
Nutzt Diskrepanzen aus, bei denen der Front-End-Proxy eine Anfragegrenze sieht, während der Back-End-Server eine andere sieht. Die Angriffsnutzlast bettet eine versteckte Anfrage in das ein, was für den Front-End-Header-Daten zu sein scheint, aber vom Back-End als separate Anfrage interpretiert wird.

Beispiel aus der Forschung: Wurde verwendet, um Parser-Unterschiede bei großen CDN-Anbietern zu demonstrieren.

0.CL (Zero Content-Length) Desync

Quelle: James Kettles Erkenntnisse zu Schwachstellen bei IIS und T-Mobile
Nutzt unterschiedliche Interpretationen von Content-Length: 0-Headern zwischen Servern aus. Manche Server ignorieren den Body bei CL=0, während andere ihn trotzdem verarbeiten, was zu Verwirrung bei den Anfragegrenzen führt.

Auswirkungen in der Praxis: Erfolgreich gegen IIS-Server und die Infrastruktur von T-Mobile ausgenutzt.

Expect-Header-Desync

Quelle: James Kettles Forschung zu T-Mobile und LastPass
Nutzt den Expect: 100-continue-Mechanismus aus, bei dem Front-End und Back-End die Fortsetzung unterschiedlich handhaben. Dies schafft Möglichkeiten, Anfragen zu schmuggeln, während der Front-End auf eine 100-continue-Antwort wartet.

Forschungskontext: Gegen Authentifizierungssysteme von T-Mobile und LastPass demonstriert.

Double-Desync (Response Queue Poisoning)

Quelle: James Kettles fortgeschrittene Desync-Methodik
Verkettet mehrere Desync-Angriffe, um die Antwortwarteschlange zu vergiften, sodass Angreifer kontrollieren können, welche Antworten andere Benutzer erhalten. Dies stellt einen der ausgefeiltesten Angriffe in der Forschung dar.

Kritisches Ergebnis: Ermöglicht die vollständige Übernahme einer Website durch die Auslieferung bösartiger Antworten an legitime Benutzer.

CL.TE / TE.CL-Konflikte

Quelle: Kernforschung zur HTTP/1.1-Mehrdeutigkeit von James Kettle
Nutzt Konflikte zwischen Content-Length- und Transfer-Encoding: chunked-Headern aus. Verschiedene Server priorisieren diese Header unterschiedlich, was zu Parser-Diskrepanzen führt, die Request-Smuggling ermöglichen.

Grundlage: Diese Konflikte stellen den grundlegenden Fehler dar, den James Kettle in der HTTP/1.1-Spezifikation identifizierte.

Erkennungsindikatoren

Basierend auf James Kettles Forschungsmethodik suchen die Tools nach:

Primäre Indikatoren (aus der Originalforschung)

• Unerwartete 404/403/401-Antworten: Zeigen geschmuggelte Anfragen an, die nicht autorisierte Endpunkte erreichen
• Antworten mit Administrator-/eingeschränkten Pfaden: Deuten auf erfolgreiches Request-Smuggling in geschützte Bereiche hin
• Mehrere HTTP-Antworten in einer einzigen Verbindung: Zeichen für Response-Queue-Poisoning
• Parser-Fehlerantworten (400 Bad Request): Können auf erfolgreiche Desync-Verwirrung hindeuten

Fortgeschrittene Erkennungsmethoden

• Anomalien bei Antwortzeiten: Verzögerungen, die auf Verwirrung bei der serverseitigen Verarbeitung hindeuten
• Inkonsistenzen bei Content-Length: Antworten mit falscher Body-Länge
• Artefakte von Header-Injection: Hinweise auf geschmuggelte Header in Antworten
• Cache-Poisoning-Indikatoren: Unerwartete zwischengespeicherte Antworten, die andere Benutzer betreffen

Bewertung des Schwergrads der Schwachstelle

In Anlehnung an James Kettles Klassifizierung der Auswirkungen:

• Kritisch: Response-Queue-Poisoning, das Benutzerimitation ermöglicht
• Hoch: Request-Smuggling zu Administrator-Endpunkten
• Mittel: Parser-Diskrepanzen ohne Exploit-Nachweis
• Niedrig: Harmloses Desync-Verhalten ohne Sicherheitsauswirkung

Verantwortungsvoller Einsatz

Diese Tools sind konzipiert für:

• Defensive Sicherheitstests auf autorisierten Systemen
• Schwachstellenbewertung mit entsprechenden Berechtigungen
• Sicherheitsforschung in kontrollierten Umgebungen