Anforderungen

• Docker mit Compose-Unterstützung.
• Linux/386-Container-Unterstützung.
• Für den vollständigen RCE-Validator mit bekannter Adresse verwenden Sie einen nativen x86-Linux-Docker-Host, auf dem /proc/<pid>/maps das tatsächliche 32-Bit-Adresslayout des nginx-Workers offenlegt. Docker Desktop auf Nicht-x86-Hosts kann das Ziel unter qemu-i386 ausführen; dies reicht aus, um den OOB-Absturz zu validieren, aber nicht die RCE-Mathematik mit bekannter Adresse.
• Python 3 auf dem Host für die Exploit-Skripte.

Schnellstart

Erstellen und starten Sie das verwundbare 32-Bit-nginx-Labor:

Lösen Sie den kontrollierten OOB-Schreibvorgang aus:

Führen Sie den deterministischen Docker-only RCE-Validator aus:

Führen Sie den Brute-Force-Treiber ohne Introspection aus:

host.docker.internal wird als Callback-Host verwendet, sodass der im nginx-Worker eingebettete Befehl die id-Ausgabe zurück an den vom Exploit-Skript gestarteten Listener POSTen kann. Die Compose-Datei ordnet diesen Namen für Linux-Docker-Engines zu.

Exploitation Walkthrough

1. Das Labor erstellen und starten

Das Compose-Ziel erstellt nginx 1.30.0 als 32-Bit-Binärdatei im Release-Stil und startet es auf 127.0.0.1:19331. Ein einfacher GET / gibt ok zurück, was beweist, dass das Ziel vor Beginn der Exploitation erreichbar ist.

2. Den OOB-Schreibvorgang auslösen

Der Auslöser sendet ein erfasstes URI-Segment, das aus +-Bytes besteht, über den verwundbaren rewrite- plus set $myvar $1-Pfad. + wird von NGX_ESCAPE_ARGS escaped, sodass der Kopierdurchgang für jede Eingabe von einem Byte drei Bytes schreibt. Das Skript gibt die erwartete Überlaufgröße aus, bevor es die Anfrage sendet.

3. RCE mit Laborunterstützung validieren

Der Validator mit bekannter Adresse ist absichtlich unterstützt. Er liest die Live-Heap- und libc-Mappings des Workers aus dem Docker-Container, berechnet die Adresse des gefälschten Cleanup-Handlers, sendet die gleiche Exploit-Sequenz auf Drahtebene und wartet auf den Callback. Die Ausgabe uid=65534(nobody) ist der nginx-Worker, der id ausführt. Dieser Screenshot stammt von einem nativen x86-Docker-Lauf; bei Nicht-x86-Docker-Desktop-Einrichtungen kann das Skript stattdessen mit einer qemu-i386-Anforderung an den nativen Host anhalten.

4. Den rein entfernten Brute-Force-Pfad ausführen

Das entfernte Brute-Force-Skript entfernt die laborinternen Adress-Lesevorgänge. Es zählt SAFE-Heap-Seiten-Kandidaten und libc-Seiten-Kandidaten auf und verwendet nur den Callback als Erfolgsorakel. Das Erschöpfen eines Durchlaufs ohne Callback widerlegt die Primitive nicht; normalerweise bedeutet es, dass das aktuelle nginx-Master-Layout für dieses Payload-Alphabet nicht günstig ist oder der Durchlauf einen Master-Neustart/-Neuladung benötigt, um ASLR neu zu rollen.

Wie die RCE-Sequenz funktioniert

Der Exploit verwendet drei gleichzeitige Anforderungsrollen:

1. /spray hält eine Anforderungskörper-Allokation am Leben und platziert einen gefälschten ngx_pool_cleanup_t-Datensatz sowie den Callback-Befehl im Heap-Speicher des nginx-Workers.
2. /api/<payload> erreicht das verwundbare Rewrite-Skript und verzögert den endgültigen Anfrage-Terminator, bis die Opferanfrage vorhanden ist.
3. / erstellt den angrenzenden Anforderungspool, dessen cleanup-Zeiger Ziel der kontrollierten OOB-Schreiboperation ist.

Wenn der beschädigte Anforderungspool zerstört wird, folgt nginx dem überschriebenen Cleanup-Zeiger. Im Labor-RCE-Pfad zeigt der gefälschte Cleanup-Handler auf system() und sein Datenzeiger auf:

Der Exploit-Listener behandelt diesen POST als einziges RCE-Erfolgssignal.

Bereinigung

Sicherheitshinweise

Dieses Labor ist für autorisierte Sicherheitsvalidierung und -bildung gedacht. Halten Sie es isoliert, setzen Sie den Labor-Port keinen unsicheren Netzwerken aus und führen Sie den Exploit nicht gegen Systeme aus, die Sie nicht besitzen oder für die Sie keine ausdrückliche Genehmigung zum Testen haben.