Comandos de Ejemplo

Notas Importantes

• ⚠️ Los errores de timeout son ESPERADOS - indican que la RCE se ejecutó correctamente
• El servidor se cuelga después de ejecutar el comando, lo que provoca el timeout HTTP
• Los comandos se ejecutan como el usuario nextjs (UID 1001) dentro del contenedor
• Los archivos se crean dentro del sistema de archivos del contenedor, no en el host

Configuración Docker

Este repositorio incluye una configuración Docker completa para probar la vulnerabilidad:

• docker-compose.yml - Configuración de Docker Compose
• test-server/ - Aplicación Next.js vulnerable
• test-server/Dockerfile - Dockerfile de producción
• test-server/Dockerfile.dev - Dockerfile de desarrollo (opcional)

El servidor vulnerable ejecuta Next.js 16.0.6 con una Server Action simple que puede ser explotada.

Archivos

• poc.py - Script de prueba de concepto en Python (original de msanft, con correcciones de escape de comillas)
• exploit-docker.sh - Script de exploit automatizado para entorno Docker
• DOCKER_SETUP.md - Documentación completa de configuración Docker

Limpieza

Análisis Original de la Vulnerabilidad

A continuación se proporciona el análisis detallado de la vulnerabilidad, la cadena de explotación y la información del parche de la investigación original.

Investigación Original por msanft

Esta vulnerabilidad permite RCE en React Server Functions, por ejemplo, las ofrecidas por Next.js a través de referencias inseguras al prototipo.

No soy un experto en React o Next.js, así que toma toda la información aquí con cautela. Además, todavía estoy en el proceso de análisis, por lo que lo que describo a continuación como "la vulnerabilidad" podría ser solo una pequeña parte de la cadena completa.

Antecedentes

React ofrece Server Functions¹, que pueden verse como una especie de RPC sobre HTTP. Pueden usarse para obtener datos de pares adyacentes para asegurar baja latencia, o realizar solicitudes autenticadas para las que el cliente carece de credenciales.

React utiliza algo llamado React Flight Protocol² para la serialización de valores pasados a Server Functions.

El cliente pasa "chunks" al servidor, por ejemplo, mediante datos de formulario:

Como se muestra, estos pueden tener referencias entre sí. El payload anterior se deserializa en el servidor de la siguiente manera:

El formato en sí es un poco más complejo y permite una serialización y deserialización más complejas, pero esto proporciona una comprensión básica para la vulnerabilidad real.

Vulnerabilidad

Hasta este commit³, al recorrer chunks en la resolución de referencias, como obtener fruitName del chunk 2 en el ejemplo anterior, React no verificaba si la clave solicitada estaba realmente establecida en el objeto. Esto permitía obtener el prototipo del objeto⁴.

Esto se puede demostrar con un payload como este:

Que se deserializa en el constructor de la función⁵:

Cuando el chunk con ID 0 no es un array sino un objeto, podemos establecer la clave then en el constructor de la función. Luego, decodeReplyFromBusboy devuelve el objeto y Next.js lo espera (await):

Cuando esto devuelve un thenable, el await en la llamada lo ejecutará. Esto es lo que sucede con este payload:

Lo que lleva a este error:

El error se ve así porque V8 llama a una función awaited con las funciones internas resolve y reject, que al convertirlas a toString se serializan en algo como esto:

Explotación

Como podemos recuperar trivialmente el constructor Function, la forma directa es encontrar un gadget de llamada que invoque el constructor con un valor controlado por el usuario (es decir, el código de la función como cadena) y luego llame a la función devuelta.

Hay varios lugares que pueden llamar al constructor de la función, por ejemplo resolveServerReference, donde id es un objeto controlado, y lastIndexOf puede sobrescribirse para devolver una cadena controlada por el usuario (por ejemplo, a través de Array.prototype.join) y slice puede sobrescribirse con el constructor de la función. Sin embargo, este lugar no funciona porque la segunda invocación de .slice() proporciona un número como primer argumento, que, según mi conocimiento, nunca puede ser manejado por el constructor de la función.

Aquí viene una idea brillante de maple3142⁶. Cuando getChunk toma el chunk en el ID 0 como referencia raíz para comenzar a resolver la cadena de referencias, este mismo chunk puede resolverse a un "fake chunk" manipulado.

Podemos referenciar el chunk manipulado 0 en el chunk 1 usando la sintaxis $@, que devuelve el chunk "crudo", no su valor resuelto:

Combinando esto con nuestra sobrescritura de then de arriba, podemos construir algo como esto:

Aquí, el chunk 0 sobrescribe su propio .then() con el .then() de su propia representación cruda de chunk. En pocas palabras, sobrescribimos nuestro propio .then() con Chunk.prototype.then, que existe, ya que los Chunks son thenables:

Con el payload anterior, Chunk.prototype.then se llama eventualmente con el chunk manipulado con ID 0.

Como se muestra arriba, cuando .status en nuestro chunk fake es resolved_model:

Entramos en initializeModelChunk. Aquí, .value se analiza como JSON y luego se resuelven referencias en el objeto devuelto, usando el contexto "externo" de nuestros chunks con IDs 0 y 1:

Dentro de esto, ahora tenemos una segunda pasada de evaluación con algunos valores adicionales a los que tenemos acceso debido a que el contexto externo ya está resuelto.

Hay un gadget de llamada en el manejo de datos blob con el prefijo $B en el protocolo flight:

Usando el campo especial _response, controlamos la propiedad response del chunk manipulado:

Con esto, podemos construir un objeto con propiedades ._formData y ._prefix falsas:

Es necesario agregar .reason para evitar fallar en la invocación de toString en initializeModelChunk:

Al apuntar ._formData al constructor de la función y ._prefix a nuestro código, obtenemos un gadget de invocación para el constructor de la función en la deserialización de blob:

Nuestra función manipulada se devuelve entonces como el método .then() del chunk manipulado, que también se espera, ya que todo esto ocurre en una sola cadena de resolución de promesas. Por lo tanto, al devolver un thenable, nuestra función manipulada se ejecuta. Esto constituye el gadget de llamada requerido mencionado anteriormente.

Poniendo todo esto junto con un payload RCE real, obtenemos algo como esto:

Parche

El uso de referencias a chunks para recuperar propiedades del prototipo se soluciona con esta verificación:

Preguntas pendientes

• ¿Por qué el aviso de React⁷ menciona que esta vulnerabilidad podría activarse incluso sin declarar activamente server functions? ¿Hay otras cosas que se convierten en server functions bajo el capó?