IngressNightterror (CVE-2025-1974)

Descripción general

Este repositorio es mi investigación sobre la vulnerabilidad IngressNightmare. Incluye archivos de despliegue de Ingress vulnerables, el exploit en sí y el payload de objeto compartido.

CVE

La lista de índices CVE:

• CVE-2025-1974 - Vulnerabilidad raíz
• CVE-2025-24514 - Inyección de anotación auth-url
• CVE-2025-1097 - Inyección de anotación auth-tls-match-cn
• CVE-2025-1098 - Abuso de UID de imagen

Referencias

Solo algunas referencias:

• Artículo original de WIZ Research
• Issue de Kubernetes en GitHub
• Artículo del blog de Kubernetes
• Boletín de Amazon AWS
• Boletín de Google Cloud

Causa raíz

La raíz de esta vulnerabilidad reside en la falta de una desinfección adecuada de las entradas. Cuando envías una solicitud AdmissionReview, se crea una configuración NGINX temporal que luego se prueba para verificar su validez usando el comando nginx -t. Consulta el código fuente con el error mitigado.

La capacidad de controlar el contenido de la configuración que se está probando nos permite utilizar una amplia gama de campos de configuración para inyectar configuraciones malformadas:

• auth-url - pasa sin una desinfección adecuada, permitiéndonos añadir un # y \n. Usaremos este punto de inyección.
• auth-tls-match-cn - solo requiere que el campo comience con CN= y sea una expresión regular válida.
• ing.UID - el UID va a la configuración tal cual.

El hecho de que la configuración de NGINX solo se pruebe reduce ligeramente el número de directivas que podemos usar. Una de las directivas que queda es ssl_engine, que nos permite cargar bibliotecas compartidas. Este es un buen punto de entrada. Pero, ¿cómo podemos poner nuestro archivo .so en el sistema de archivos del pod?

Los inteligentes investigadores de WIZ idearon la idea de enviar una solicitud con nuestro objeto .so como cuerpo, y si es lo suficientemente grande, ¡NGINX lo guarda en un archivo en procfs! También podemos ajustar el Content-Length, haciendo que NGINX espere más datos, lo que hace que mantenga el archivo en procfs por algún tiempo. El PID real y el número de FD se adivinarán.

Para más información, lee el artículo de análisis original del equipo de investigación de WIZ.

Explotación

El código del exploit es bastante autoexplicativo. Así que ve a ver el código fuente.

Configuración del entorno

1. Clona el repositorio:

   root@kitploit:~

   git clone https://github.com/I3r1h0n/IngressNightterror
   cd IngressNightterror
   

2. Inicia una imagen Docker de k3s:

   root@kitploit:~

   cd stand
   docker compose up -d
   

3. Despliega el NGINX Ingress:

   En caso de que uses Linux/Mac, puedes desplegarlo usando el script:

   root@kitploit:~

   ./k8s/setup.sh
   

   ---

   Si estás en Windows, o quieres más control sobre el proceso de despliegue, hazlo manualmente:

   Despliega NGINX Ingress:

   root@kitploit:~

   kubectl --kubeconfig=./output/kubeconfig.yaml apply -f ./k8s/ingress.yaml
   

   Ahora puedes usar kubectl con la configuración proporcionada en ./output. No olvides usar el namespace ingress-nginx.

   Nota importante: el ingress.yaml está creado a partir del NGINX Ingress vulnerable

Objeto compartido del payload

El payload es un proxy inverso simple. No olvides editar el puerto y la dirección IP antes de compilarlo con:

make all

Compilará el objeto compartido usando el contenedor Docker gcc:latest.

Créditos

Gran respeto al equipo de investigación de WIZ que descubrió originalmente la vulnerabilidad, y a los mantenedores de NGINX Ingress.

prod. por I3r1h0n.