Nether-Portal-Desynchronisation (HUUP)

„Ich reise nicht auf befahrenen Straßen, sondern springe frei durch die Leere. Packe mich falsch ein, und ich werde ein Geheimnis an die falsche Tür liefern.“

Beschreibung

Die Challenge besteht aus einer HTTP/3 (QUIC) Anwendung, die über UDP geschichtet ist. Da UDP zustandslos ist und der Proxy keine strengen HTTP-Anfragegrenzen wie TCP durchsetzt, ist es möglich, den Proxy und den Backend-Server zu desynchronisieren. Ein Angreifer kann eine versteckte HTTP-Anfrage innerhalb einer anderen Anfrage einschmuggeln.

Hinweise – maximale Nachrichtenlänge beträgt 1024 Bytes, nur GET-Anfragen funktionieren wirklich, und Nachrichten werden nach 10 Sekunden verworfen

Ziel: byuctf.xyz:40011

Schwachstellenanalyse

• Schwachstelle: HTTP-Request-Smuggling (über UDP/QUIC)
• Ursache: Inkonsistentes Parsen von HTTP-Payload-Grenzen zwischen dem Frontend-Proxy und der Backend-Anwendung bei unzuverlässigen Protokollen.

Bei dieser speziellen Implementierung hört eine Python-Middleware (udp_server.py) auf Port 40000 auf eingehenden Text. Dieser Server leitet Anfragen weiter, sobald ein \r\n\r\n gefunden wird, an den eigentlichen Webserver. Da es sich um UDP handelt, besteht eine hohe Wahrscheinlichkeit von Paketverlusten, was zu Desynchronisation führt, wenn mehrere Anfragen schnell gesendet werden oder die Paketgrenzen manipuliert werden.

Writeup

Um diese Challenge zu lösen, müssen Sie die unzuverlässige Natur von UDP und die spezifische Art berücksichtigen, wie die Middleware Anfragegrenzen behandelt.

1. Aufklärung: Der Zugriff auf den Root-Endpunkt / gibt einen Hinweis auf die Nether-Verbindungsinstabilität.
2. Endpunkt-Erkennung: Navigieren Sie zu /endpoints.txt, um eine Liste von 200 möglichen versteckten Endpunkten zu finden.
3. Brute-Force: Einer dieser Endpunkte enthält die Flagge, während drei andere falsche positive Ergebnisse liefern.
4. Protokollbeherrschung: Aufgrund der UDP-Middleware kann eine Standard-Browseranfrage den vollständigen Antworttext nicht empfangen (möglicherweise werden nur die Header zurückgegeben, bevor die Verbindung geschlossen wird oder die Zeit abläuft).
5. Automatisierung: Schreiben Sie ein Skript (siehe solve.py), das rohe HTTP-Anfragen über UDP an das Ziel sendet. Das Skript muss durch die Endpunkte iterieren und jeden wiederholt anfragen, bis eine vollständige Antwort (mit einem Body) empfangen wird.

Gegenmaßnahmen

• Stellen Sie sicher, dass sowohl Frontend als auch Backend exakt die gleiche Logik zum Parsen von Anfragegrenzen verwenden.
• Lehnen Sie alle Anfragen mit mehrdeutigen Längen-Headern oder illegalen Zeichen im Header-Stream ab.
• Verwenden Sie etablierte HTTP/3-Bibliotheken anstelle einer benutzerdefinierten UDP-zu-TCP-Weiterleitungslogik.

Hinweise

• Haben Sie herausgefunden, wie der Front-Proxy mit dem Back-Proxy kommuniziert?
• Überprüfen Sie das verwendete Protokoll – UDP garantiert keine Zustellung!

Flagge

CH4KR4X2{P0D5_bl0ckch41n_br34ch}

Hosting

Diese Challenge startet einen Flask-Server auf Port 1337 und udp_server.py auf Port 40000.

Build:

sudo docker build -t huup .
sudo docker network create -d bridge huup

Run:

sudo docker run -p 40011:40000/udp --detach --name huup --network huup huup:latest