Node.js RCE-Minderung: DevOps als letzte Verteidigungslinie

Dieses Projekt demonstriert eine kritische Remote-Code-Ausführungs-Sicherheitslücke (RCE) in einer Next.js-Anwendung (insbesondere über Server Actions) und wie Härtung der Infrastruktur den Angriff effektiv neutralisiert, selbst wenn die Code-Sicherheitslücke bestehen bleibt.

Es stellt eine standardmäßige "Unsicher"-Bereitstellung einer gehärteten "Sicher"-Bereitstellung gegenüber, die Distroless-Images und schreibgeschützte Dateisysteme nutzt.

🛡️ Das Konzept: "Verteidigung in der Tiefe"

Sicherheitslücken in der Software sind unvermeidlich. Wenn der Code versagt, muss Ihre Infrastruktur verhindern, dass der Angreifer seine Position ausbaut.

Die Sicherheitslücke

Eine kritische RCE (CVE-2025-55182, auch bekannt als React2Shell) existiert in der React Server Components (RSC)-Implementierung, die von Next.js verwendet wird.

• CVSS: 10.0 (Kritisch)
• Root Cause: Unsichere Deserialisierung des "Flight"-Protokolls ermöglicht es einem Angreifer, interne Objekte (über Prototyp-Verschmutzung oder ähnliche Mechanismen) während der Verarbeitung von Server-Aktionen zu manipulieren.
• Impact: Dies ermöglicht die Ausführung beliebigen Codes (wie spawnSync) ohne Authentifizierung.

Die Angriffsvektoren

1. Living off the Land (LotL): Nutzung von Werkzeugen, die bereits im Betriebssystem vorhanden sind (curl, wget, ls, cat), um Geheimnisse zu stehlen oder Malware herunterzuladen.
   • Mechanismus: Der Exploit verwendet child_process.spawnSync() von Node.js. Dieser führt Binärdateien direkt aus, ohne eine Shell (/bin/sh) zu benötigen.
2. Bring Your Own Land (BYOL): Wenn Standardwerkzeuge fehlen, lädt der Angreifer seine eigene Binärdatei hoch (z. B. eine kompilierte Go-Datei), macht sie ausführbar (chmod +x) und führt sie aus.

🏗️ Architekturvergleich

📝 Analyse der Anwendungsprotokolle

Die folgenden Protokolle zeigen, wie die Angriffsversuche aus Sicht der Anwendung aussehen. Dieser Kontrast verdeutlicht eindrucksvoll die Wirksamkeit der Sicherheitsmaßnahmen.

Protokolle der sicheren App (logs/server.safe.log)

Die Protokolle zeigen wiederholte Fehler (ENOENT).

• Warum? spawnSync versucht, ls, id, curl auszuführen. Das Distroless-Image hat diese Binärdateien einfach nicht. Es geht nicht nur um eine fehlende Shell; die Werkzeuge selbst sind weg.

[Instrumentation] Logging initialized. Writing to: /app/logs/server.safe.log
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"1. Write Initial Chunk to /tmp/hello_test","success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"2. Verify Binary was Written","verification":{...},"success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"4. Execute Binary","stdout":"","stderr":"","error_obj":{"message":"spawnSync /tmp/hello_test EACCES","code":"EACCES"},"success":true}`'

Protokolle der unsicheren App (logs/server.unsafe.log)

Die Protokolle bestätigen erfolgreiche Befehlsausführung und Dateisystemmanipulation.

[Instrumentation] Logging initialized. Writing to: /app/logs/server.unsafe.log
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"1. Write Initial Chunk to /tmp/hello_test","success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"4. Execute Binary","stdout":"Hello from Go binary!\\n","stderr":"","error_obj":null,"success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"command":"id","args":[],"stdout":"uid=0(root) gid=0(root) ...","stderr":"","status":0,"signal":null}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"command":"cat","args":["/app/.env"],"stdout":"","stderr":"cat: can\'t open \'/app/.env\': No such file or directory\n","status":1,"signal":null}`'

(Hinweis: In den unsicheren Protokollen schlägt cat /app/.env oben fehl, weil die Datei im Stammverzeichnis .env heißt, aber ls -la in den vollständigen Protokollen würde die Verzeichnisstruktur offenbaren.)

💥 POC-Ergebnisse

1. Standard RCE (Living off the Land)

Versuch, standardmäßige Shell-Befehle auszuführen.

• Unsafe: ✅ Erfolg. Angreifer kann id, ls, cat .env ausführen und auf sensible Daten zugreifen.
• Safe: ❌ Blockiert. spawnSync /bin/sh ENOENT. Es gibt keine Shell, um Befehle auszuführen.

2. Erweiterter Angriff (Bring Your Own Land)

Versuch, die "fehlenden Werkzeuge" durch Hochladen einer benutzerdefinierten Binärdatei zu umgehen.

• Unsafe: ✅ Erfolg.
  1. Angreifer zerlegt eine Binärdatei in Blöcke (um Payload-Grenzen zu umgehen).
  2. Schreibt sie nach /tmp/malware.
  3. Führt chmod +x aus.
  4. Führt die Binärdatei aus.
• Safe: ❌ Blockiert.
  • Schreiben fehlgeschlagen: EROFS: read-only file system.
  • Der Angreifer kann nirgendwo Dateien ablegen, was den BYOL-Angriff effektiv neutralisiert.

3. Analyse der "echten dateilosen" Ausführung

Kann ein Angreifer eine Binärdatei in eine Variable laden und direkt aus dem Speicher ausführen?

• Konzept: Blöcke einer Binärdatei zu einer globalen JavaScript-Variable (z. B. global.payload = "...") verketten und dann ausführen.
• Realität: Fehlgeschlagen.
  • Node.js child_process-Funktionen (spawn, exec) erfordern einen Dateipfad. Sie können keinen Puffer oder String direkt ausführen.
  • Um dies unter Linux zu umgehen, benötigt man memfd_create (einen Syscall zum Erstellen einer anonymen Datei im RAM).
  • Die Hürde: Node.js stellt memfd_create nicht nativ bereit. Der Zugriff darauf würde ein C++-Addon (wie ffi-napi) erfordern, das in node_modules vorinstalliert sein müsste.
  • Distroless-Auswirkung: Da dem Image Compiler (gcc, make) fehlen, kann ein Angreifer dieses Addon nicht spontan erstellen.

🔐 Demonstrierte Best Practices

1. Verwenden Sie Distroless-Images

"Distroless"-Images enthalten nur Ihre Anwendung und ihre Laufzeitabhängigkeiten. Sie enthalten keine Paketmanager, Shells oder standardmäßige UNIX-Werkzeuge.

• Warum? Wenn ein Angreifer RCE erlangt, kann er nicht herumschnüffeln (ls), Dateien herunterladen (curl) oder leicht Berechtigungen eskalieren.

2. Schreibgeschützte Dateisysteme

Konfigurieren Sie Ihre Container-Laufzeitumgebung so, dass das Stammdateisystem schreibgeschützt eingehängt wird.

• Warum? Es verhindert, dass Angreifer Ihre Anwendungscode herunterladen (BYOL) oder ändern (Persistenz).
• Wie? In docker-compose.yml:
  root@kitploit:~

  read_only: true
  tmpfs:
    - /tmp:noexec # KRITISCH: Ausführung explizit blockieren!
  

  Beobachtung: Mit dieser Einrichtung zeigt unser POC, dass der Angreifer die Binärdatei zwar nach /tmp schreiben kann (Schreiben erfolgreich), die Ausführung jedoch mit EACCES (Zugriff verweigert) aufgrund des noexec-Flags fehlschlägt. Dies bringt Funktionalität (beschreibbares tmp) mit Sicherheit in Einklang.

3. Native Umgebungsvariablen (Der "Export"-Raum)

Versenden Sie .env-Dateien nicht in Ihren Container-Images. Wenn ein Angreifer Dateien lesen kann (z. B. cat .env), sind Ihre Geheimnisse kompromittiert.

• Sicherer Ansatz: Injizieren Sie Variablen direkt zur Laufzeit in die Prozessumgebung (z. B. über Kubernetes Secrets, AWS Parameter Store oder den environment-Schlüssel von Docker).
• Warum? Es macht es für einen Angreifer viel schwieriger, alle Geheimnisse auf einmal auszulesen, als eine einzelne Datei zu lesen.

🚀 So führen Sie es aus

1. Starten Sie die Umgebung: Sowohl die sichere als auch die unsichere Anwendung sind in einer einzigen docker-compose.yml-Datei definiert.

   root@kitploit:~

   docker compose up --build -d
   

2. Führen Sie die Exploits aus: Sie können die Exploits gegen die spezifischen Ports ausführen, um den Unterschied zu sehen.

   • Ziel: Unsichere App (Port 3001):

     root@kitploit:~

     # 1. Standard RCE (LotL) - ERFOLGREICH
     python exploit/poc.py http://localhost:3001
     
     # 2. Erweiterter Angriff (BYOL) - ERFOLGREICH
     python exploit/poc_advanced.py http://localhost:3001
     

   • Ziel: Sichere App (Port 3000):

     root@kitploit:~

     # 1. Standard RCE (LotL) - FEHLGESCHLAGEN (ENOENT)
     python exploit/poc.py http://localhost:3000
     
     # 2. Erweiterter Angriff (BYOL) - FEHLGESCHLAGEN (EACCES/EROFS)
     python exploit/poc_advanced.py http://localhost:3000
     

3. Aufräumen:

   root@kitploit:~

   docker compose down