Se han detectado cuatro vulnerabilidades críticas en el controlador de ingreso ingress-nginx del proyecto Kubernetes en desarrollo, que permiten ejecutar código en los servidores de sistemas en la nube que utilizan la plataforma Kubernetes y obtener acceso completo y privilegiado al clúster de Kubernetes. Estas vulnerabilidades tienen un nivel de gravedad crítico (9.8 de 10). Los investigadores que identificaron los problemas han asignado el nombre en código IngressNightmare a estas vulnerabilidades y han señalado que afectan aproximadamente al 43% de los entornos en la nube. Las vulnerabilidades se han corregido en las versiones ingress-nginx 1.11.5 y 1.12.1.
El controlador de ingreso actúa como una puerta de enlace y se utiliza en Kubernetes para organizar el acceso desde la red externa a los servicios dentro del clúster. El controlador ingress-nginx es el más popular y utiliza servidor NGINX para redirigir las solicitudes al clúster, enrutando las peticiones externas y equilibrando la carga. El proyecto Kubernetes proporciona controladores de ingreso básicos para AWS, GCE y nginx, este último no está relacionado con el controlador kubernetes-ingress, cuya gestión está a cargo de la empresa F5/NGINX (las vulnerabilidades mencionadas no afectan a los proyectos desarrollados por los desarrolladores de NGINX; la mención de nginx en el nombre ingress-nginx está relacionada únicamente con el uso de nginx como proxy).
Las vulnerabilidades permiten a un atacante no autenticado ejecutar su código en el contexto del controlador ingress-nginx, teniendo la posibilidad de enviar una solicitud al manejador web Admission. Durante el escaneo de la red se han identificado más de 6500 clústers de Kubernetes vulnerables que utilizan controladores públicos con un manejador de Admission expuesto a solicitudes externas.
En la configuración predeterminada, el código ejecutado por el atacante puede acceder a la configuración del objeto Ingress, donde, entre otras cosas, se almacenan las credenciales para acceder a los servidores de Kubernetes, lo que permite obtener acceso privilegiado a todo el clúster. Como medida de protección, se recomienda desactivar en ingress-nginx la función 'Validating Admission Controller'.
El controlador Admission se ejecuta en un pod separado y realiza la verificación de los objetos ingress entrantes antes de su implementación. Por defecto, el manejador web Admission acepta solicitudes sin autenticación desde la red pública. Al realizar la verificación, el controlador Admission crea una configuración para el servidor http nginx basada en el contenido del objeto ingress recibido y verifica su validez.
Las vulnerabilidades identificadas permiten la inyección de configuraciones en nginx mediante el envío de un objeto ingress especialmente diseñado directamente al controlador Admission. Los investigadores descubrieron que algunas propiedades de las solicitudes de verificación, establecidas en el campo “.request.object.annotations”, se inyectan directamente en la configuración de nginx. La configuración generada no se aplica, sino que se prueba ejecutando el archivo ejecutable “nginx” con la opción “-t”.
En particular, la inyección de datos externos en la configuración se lleva a cabo para los parámetros “mirror-target”, “mirror-host” (CVE-2025-1098), “auth-tls-match-cn” (CVE-2025-1097) y “auth-url” (CVE-2025-24514). Por ejemplo, en la línea de configuración “set $target {{ $externalAuth.URL }};” en lugar de “{{ $externalAuth.URL }}” se inyecta la URL especificada en el parámetro “auth-url”. No se verifica la validez de la URL. En consecuencia, un atacante puede pasar como URL un valor como “http://example.com/#; configuraciones” e inyectar sus propias configuraciones en el archivo de configuración.
Para ejecutar código arbitrario durante la verificación de la configuración con el comando “nginx -t”, los investigadores se aprovecharon de que, además de verificar la sintaxis, nginx carga bibliotecas con módulos y abre archivos mencionados en la configuración para evaluar su disponibilidad. Entre otras cosas, al procesar la directiva ssl_engine se carga la biblioteca compartida especificada en la directiva para SSL-el motor.
Para cargar su propia biblioteca en el servidor de Kubernetes, los investigadores se aprovecharon (CVE-2025-1974) de que, al procesar solicitudes grandes, nginx guarda el cuerpo de la solicitud en un archivo temporal que se elimina inmediatamente, pero en el sistema de archivos “/proc” queda un descriptor de archivo abierto para este archivo. Así, se pueden enviar solicitudes simultáneamente para guardar el archivo temporal e iniciar la verificación de configuración, en la que en la directiva “ssl_engine” se especifica la ruta al descriptor en el sistema de archivos “/proc”.
Para que el descriptor de archivo permanezca accesible durante un tiempo prolongado, se puede especificar un valor de "Content-Length" en la solicitud que sea deliberadamente mayor que los datos realmente enviados (el servidor esperará la recepción de los datos restantes). Una dificultad adicional es la necesidad de adivinar el PID del proceso y el número del descriptor de archivo asociado con la biblioteca compartida cargada, pero dado que en el contenedor generalmente hay un número mínimo de procesos en ejecución, los valores necesarios se adivinan mediante prueba y error en varios intentos. En caso de éxito y carga de la biblioteca compartida reemplazada, el atacante puede acceder a los parámetros almacenados dentro del entorno del pod, lo suficiente para controlar todo el clúster.
Para verificar el uso de ingress-nginx vulnerable, se puede ejecutar el comando: kubectl get pods —all-namespaces —selector app.kubernetes.io/name=ingress-nginx
Fuente: opennet.ru
