Mitigación de RCE en Node.js: DevOps como la última línea de defensa

Este proyecto demuestra una vulnerabilidad crítica de ejecución remota de código (RCE) en una aplicación Next.js (específicamente mediante Server Actions) y cómo el endurecimiento de la infraestructura neutraliza eficazmente el ataque incluso cuando la vulnerabilidad de código permanece.

Compara un despliegue estándar "Inseguro" con un despliegue endurecido "Seguro" que utiliza imágenes Distroless y sistemas de archivos de solo lectura.

🛡️ El concepto: "Defensa en profundidad"

Las vulnerabilidades de software son inevitables. Cuando el código falla, tu infraestructura debe impedir que el atacante amplíe su punto de apoyo.

La vulnerabilidad

Existe una RCE crítica (CVE-2025-55182, también conocida como React2Shell) en la implementación de React Server Components (RSC) utilizada por Next.js.

• CVSS: 10.0 (Crítico)
• Causa raíz: La deserialización insegura del protocolo "Flight" permite a un atacante manipular objetos internos (mediante contaminación de prototipos o mecanismos similares) durante el procesamiento de Server Actions.
• Impacto: Esto permite la ejecución arbitraria de código (como spawnSync) sin autenticación.

Los vectores de ataque

1. Living off the Land (LotL): Usar herramientas ya presentes en el sistema operativo (curl, wget, ls, cat) para robar secretos o descargar malware.
   • Mecanismo: El exploit utiliza child_process.spawnSync() de Node.js. Esto ejecuta binarios directamente, sin necesidad de un shell (/bin/sh).
2. Bring Your Own Land (BYOL): Si faltan las herramientas estándar, el atacante sube su propio binario (por ejemplo, un ejecutable de Go compilado), lo marca como ejecutable (chmod +x) y lo ejecuta.

🏗️ Comparación de arquitecturas

📝 Análisis de los registros de la aplicación

Los siguientes registros demuestran cómo se ven los intentos de ataque desde la perspectiva de la aplicación. Este contraste pone de relieve de forma vívida la eficacia de las medidas de seguridad.

Registros de la aplicación segura (logs/server.safe.log)

Los registros muestran fallos repetidos (ENOENT).

• ¿Por qué? spawnSync intenta ejecutar ls, id, curl. La imagen Distroless simplemente no tiene estos binarios. No se trata solo de la falta de un shell; las herramientas en sí han desaparecido.

[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}`'

Registros de la aplicación insegura (logs/server.unsafe.log)

Los registros confirman la ejecución exitosa de comandos y la manipulación del sistema de archivos.

[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}`'

(Nota: En los registros inseguros, cat /app/.env falla arriba porque el archivo se llama .env en la raíz, pero ls -la en los registros completos revelaría la estructura de directorios.)

💥 Resultados del POC

1. RCE estándar (Living off the Land)

Intentando ejecutar comandos shell estándar.

• Inseguro: ✅ Éxito. El atacante puede ejecutar id, ls, cat .env y acceder a datos sensibles.
• Seguro: ❌ Bloqueado. spawnSync /bin/sh ENOENT. No hay shell para ejecutar comandos.

2. Ataque avanzado (Bring Your Own Land)

Intentando omitir la "falta de herramientas" subiendo un binario personalizado.

• Inseguro: ✅ Éxito.
  1. El atacante fragmenta un binario (para evadir los límites de la carga útil).
  2. Lo escribe en /tmp/malware.
  3. Ejecuta chmod +x.
  4. Ejecuta el binario.
• Seguro: ❌ Bloqueado.
  • Escritura fallida: EROFS: read-only file system.
  • El atacante no puede dejar archivos en ningún lugar, lo que neutraliza eficazmente el ataque BYOL.

3. Análisis de la ejecución "realmente sin archivos"

¿Puede un atacante cargar un binario en una variable y ejecutarlo directamente desde la memoria?

• Concepto: Concatenar fragmentos de un binario en una variable global de JavaScript (p. ej., global.payload = "...") y luego ejecutarlo.
• Realidad: Fallido.
  • Las funciones child_process de Node.js (spawn, exec) requieren una ruta de archivo. No pueden ejecutar directamente un búfer o una cadena.
  • Para evitar esto en Linux, se necesita memfd_create (una syscall para crear un archivo anónimo en la RAM).
  • La barrera: Node.js no expone memfd_create de forma nativa. Acceder a ella requeriría un complemento de C++ (como ffi-napi) preinstalado en node_modules.
  • Impacto de Distroless: Dado que la imagen carece de compiladores (gcc, make), un atacante no puede construir este complemento sobre la marcha.

🔐 Buenas prácticas demostradas

1. Usar imágenes Distroless

Las imágenes "Distroless" contienen solo tu aplicación y sus dependencias de ejecución. No contienen gestores de paquetes, shells ni herramientas UNIX estándar.

• ¿Por qué? Si un atacante consigue una RCE, no puede explorar el entorno (ls), descargar archivos (curl) ni escalar privilegios fácilmente.

2. Sistemas de archivos de solo lectura

Configura el runtime de tus contenedores para montar el sistema de archivos raíz como solo lectura.

• ¿Por qué? Impide que los atacantes descarguen (BYOL) o modifiquen el código de tu aplicación (persistencia).
• ¿Cómo? En docker-compose.yml:
  root@kitploit:~

  read_only: true
  tmpfs:
    - /tmp:noexec # CRITICAL: explicitly block execution!
  

  Observación: Con esta configuración, nuestro POC demuestra que el atacante puede escribir el binario en /tmp (escritura exitosa), pero la ejecución falla con EACCES (Permiso denegado) debido al flag noexec. Esto equilibra la funcionalidad (tmp escribible) con la seguridad.

3. Variables de entorno nativas (el espacio "Export")

No incluyas archivos .env en tus imágenes de contenedor. Si un atacante puede leer archivos (p. ej., cat .env), tus secretos están comprometidos.

• Enfoque seguro: Inyecta variables directamente en el entorno del proceso en tiempo de ejecución (p. ej., mediante Kubernetes Secrets, AWS Parameter Store o la clave environment de Docker).
• ¿Por qué? Dificulta mucho más que un atacante vuelque todos los secretos a la vez en comparación con leer un solo archivo.

🚀 Cómo ejecutar

1. Inicia el entorno: Tanto la aplicación segura como la insegura están definidas en un único archivo docker-compose.yml.

   root@kitploit:~

   docker compose up --build -d
   

2. Ejecuta los exploits: Puedes ejecutar los exploits contra los puertos específicos para ver la diferencia.

   • Apuntando a la aplicación insegura (Puerto 3001):

     root@kitploit:~

     # 1. Standard RCE (LotL) - SUCCEEDS
     python exploit/poc.py http://localhost:3001
     
     # 2. Advanced Attack (BYOL) - SUCCEEDS
     python exploit/poc_advanced.py http://localhost:3001
     

   • Apuntando a la aplicación segura (Puerto 3000):

     root@kitploit:~

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

3. Limpieza:

   root@kitploit:~

   docker compose down