IngressNightmare: Vulnerabilidad de ejecución remota de código CVE-2025-1974 y medidas correctivas

En mayo de 2025 se hizo pública una vulnerabilidad de seguridad crítica, CVE-2025-1974, conocida como «IngressNightmare», que afecta al controlador ingress-nginx de Kubernetes, ampliamente implantado en infraestructuras nativas de la nube. Esta vulnerabilidad permite a atacantes no autenticados inyectar configuraciones arbitrarias en NGINX, lo que podría dar lugar a la ejecución remota de código (RCE) no autorizada y al compromiso total del clúster.

En el marco del programa OPSWAT , nuestros becarios llevaron a cabo un análisis técnico exhaustivo para comprender mejor la causa raíz, la vía de explotación y las estrategias de mitigación relacionadas con este problema de alta gravedad.

1. Cada configuración se analiza y se pasa a `generateTemplate ` para que se formatee según las plantillas predefinidas de NGINX.
2. A continuación, testTemplate comprueba que la configuración generada sea compatible con el binario de NGINX subyacente.

Todas las configuraciones de NGINX se basan en plantillas predefinidas que se encuentran en el archivo nginx.tmpl, dentro del código fuente de ingress-nginx:

Dentro de la función `generateTemplate `, la configuración se procesa tal y como se muestra en el siguiente fragmento de código:

Sin embargo, la validación y la sanitización de las entradas son insuficientes. Concretamente, el campo «uid» de un objeto Ingress se inserta directamente en la plantilla de configuración de NGINX, lo que crea un punto de inyección. Un atacante puede aprovechar esto enviando entradas manipuladas, como «uid="1234#;\n\n}\n}\n}\n injection_value"».

Esta entrada maliciosa permite la inyección de variables de ámbito global en la plantilla de NGINX, lo que permite a los atacantes activar directivas arbitrarias de NGINX y, potencialmente, lograr la ejecución remota de código (RCE).

Para aprovechar la vulnerabilidad, un atacante debe identificar una directiva capaz de ejecutar código malicioso. En un primer momento, nuestros compañeros identificaron la directiva `load_module` como potencialmente útil, ya que esta directiva permite a NGINX cargar complementos externos. Sin embargo, esta directiva solo está permitida en la fase inicial del análisis de la configuración, lo que no se ajusta a nuestro punto de inyección.

Para resolver este problema, continuamos investigando, lo que nos llevó a la directiva ssl_engine, descrita como «OpenSSL puede cargar el módulo de forma dinámica durante las pruebas de configuración». Esto despertó nuestra curiosidad debido a su capacidad para cargar módulos de forma dinámica, lo que requería un análisis más detallado.

Al iniciarse, NGINX carga su estado inicial y, a continuación, analiza los archivos de configuración línea por línea. Cada directiva se gestiona mediante la estructura `nginx_command_t`, y la directiva `ssl_engine` invoca directamente a `ngx_openssl_commands`.

Al analizar la función ngx_openssl_commands, nuestros compañeros descubrieron que depende de la compatibilidad con OpenSSL, concretamente de la función ENGINE_by_id, que se utiliza para los módulos SSL con aceleración por hardware.

Al analizar la función ENGINE_by_id, determinamos que permite la carga dinámica de bibliotecas compartidas. Además, si la biblioteca se compila con la extensión __attribute__((constructor)), la función asociada puede ejecutarse inmediatamente tras la carga. Esto indica que, al aprovechar la directiva ssl_engine, un atacante podría cargar bibliotecas compartidas arbitrarias en el host, lo que podría dar lugar a una ejecución remota de código (RCE).

De forma predeterminada, cuando una solicitud entrante supera los 8 KB, NGINX escribe el cuerpo de la solicitud en un archivo temporal ubicado en /tmp/nginx/client-body, utilizando un nombre de archivo con el formato cfg-{valor_aleatorio}. Estos archivos temporales se conservan durante un máximo de 60 segundos entre los fragmentos recibidos correctamente de un mensaje.

Tras escribir una parte del cuerpo de la solicitud en un archivo temporal, NGINX pospone su eliminación hasta que se haya recibido el cuerpo completo. Si la solicitud sigue sin completarse y no se reciben datos durante un máximo de 60 segundos, el archivo acaba siendo eliminado. Sin embargo, al retener intencionadamente el fragmento final de datos, un atacante puede mantener el archivo temporal en uso, lo que lo hace vulnerable a un ataque.

Aunque es posible controlar el contenido del archivo subido, resulta difícil localizarlo en el sistema de archivos debido a que el nombre del archivo es aleatorio. La ruta de almacenamiento se puede configurar mediante client_body_temp_path, pero el nombre del archivo se genera aleatoriamente en tiempo de ejecución, lo que lo hace impredecible. Esta aleatoriedad dificulta considerablemente el acceso selectivo, incluso mediante ataques de fuerza bruta. Para superar esto, el equipo aprovechó comportamientos inherentes al sistema operativo Linux. Consideremos el siguiente ejemplo:

This code opens a file and keeps it in an active state, closely mimicking the behavior of NGINX's client body buffer mechanism. Using /proc/{pid}/fd directory, attackers can find symbolic links created by the Linux kernel that map open file descriptors to their corresponding file paths. This route allows attackers to reduce the brute-force space to only two variables: the process ID (pid) and the file descriptor (fd).

Tras la compilación, el tamaño de la biblioteca compartida resultante superó holgadamente los 8 KB, lo que permitió que NGINX la almacenara en el búfer sin necesidad de rellenarla con datos adicionales.

A continuación, nuestros compañeros elaboraron una solicitud con un valor de «Content-Length» inflado (por ejemplo, 1 MB) para provocar una discrepancia de tamaño. Esto hizo que NGINX almacenara en el búfer todo el cuerpo del mensaje en lugar de procesarlo inmediatamente, lo que garantizaba que el objeto compartido se escribiera en una ubicación predecible.

Para que el RCE tenga éxito, es necesario que la directiva `ssl_engine` haga referencia a la ruta correcta del archivo almacenado en el búfer. Esto se puede lograr mediante un script automatizado de fuerza bruta que recorra sistemáticamente las posibles combinaciones de ID de proceso y descriptores de archivo para identificar el enlace simbólico válido que apunta al objeto compartido almacenado en el búfer.

A continuación se muestra un ejemplo de la plantilla de NGINX generada que activó el exploit.

Si la explotación se llevaba a cabo con éxito, el atacante podía obtener acceso a la shell en el contexto del pod «ingress-nginx», que, por defecto, tenía acceso a secretos confidenciales del clúster de Kubernetes.