Nel progetto in sviluppo del controller ingress di Kubernetes ingress-nginx sono state identificate quattro vulnerabilità che consentono l'esecuzione di codice malevolo sui server dei sistemi cloud che utilizzano la piattaforma Kubernetes, ottenendo così accesso privilegiato completo al cluster Kubernetes. Questi problemi sono stati classificati con un livello di pericolo critico (9.8 su 10). I ricercatori che hanno scoperto le vulnerabilità hanno assegnato loro il nome in codice IngressNightmare e hanno notato che le vulnerabilità interessano circa il 43% degli ambienti cloud. Le vulnerabilità sono state corrette nelle versioni ingress-nginx 1.11.5 e 1.12.1.
Il controller ingress funge da gateway ed è utilizzato in Kubernetes per organizzare l'accesso dalla rete esterna ai servizi all'interno del cluster. Il controller ingress-nginx è il più popolare e applica server NGINX per il forwarding delle richieste al cluster, la gestione delle richieste esterne e il bilanciamento del carico. Il progetto Kubernetes fornisce controller ingress di base per AWS, GCE e nginx, quest'ultimo non è in alcun modo collegato al controller kubernetes-ingress, il cui supporto è gestito dall'azienda F5/NGINX (le vulnerabilità discusse non riguardano i progetti sviluppati dagli sviluppatori di NGINX, il riferimento a nginx nel nome ingress-nginx è legato solo all'uso di nginx come proxy).
Le vulnerabilità consentono a un attaccante non autenticato di eseguire codice nel contesto del controller ingress-nginx, avendo la possibilità di inviare una richiesta al processore web Admission. Durante la scansione della rete sono stati identificati oltre 6500 cluster Kubernetes vulnerabili che utilizzano controller vulnerabili pubblicamente accessibili con un processor Admission aperto alle richieste esterne.
Nella configurazione predefinita, il codice eseguito dall'attaccante può accedere alle impostazioni dell'oggetto Ingress, in cui, tra l'altro, sono memorizzate anche le credenziali per contattare i server Kubernetes, consentendo di ottenere accesso privilegiato all'intero cluster. Come misura di protezione, si consiglia di disabilitare nel ingress-nginx la funzione di "Validating Admission Controller".
Il controller Admission viene eseguito in un ambiente pod separato e verifica gli oggetti ingress in entrata prima della loro distribuzione. Per impostazione predefinita, il processore web Admission accetta richieste senza autenticazione dalla rete pubblica. Durante la verifica, il controller Admission crea una configurazione per il server http nginx basata sul contenuto dell'oggetto ingress ricevuto e ne controlla la correttezza.
Le vulnerabilità individuate consentono di sostituire le proprie impostazioni in nginx inviando un oggetto ingress formattato in modo specifico direttamente al controller di Admission. I ricercatori hanno scoperto che alcune proprietà delle richieste di convalida, impostate nel campo ".request.object.annotations", vengono direttamente sostituite nella configurazione di nginx. La configurazione generata non viene applicata, ma solo testata eseguendo il file eseguibile "nginx" con l'opzione "-t".
In particolare, la sostituzione di dati esterni nella configurazione avviene per i parametri "mirror-target", "mirror-host" (CVE-2025-1098), "auth-tls-match-cn" (CVE-2025-1097) e "auth-url" (CVE-2025-24514). Ad esempio, nella riga di configurazione "set $target {{ $externalAuth.URL }};" al posto di "{{ $externalAuth.URL }}" viene sostituito l'URL indicato nel parametro "auth-url". Inoltre, la correttezza dell'URL non viene verificata. Di conseguenza, l'attaccante può inviare come URL un valore come "http://example.com/#; n impostazioni" e sostituire le proprie impostazioni nel file di configurazione.
Per eseguire codice arbitrario durante il controllo della configurazione con il comando "nginx -t", i ricercatori hanno approfittato del fatto che oltre a controllare la sintassi, nginx carica le librerie con i moduli e apre i file menzionati nella configurazione per valutarne la disponibilità. Tra l'altro, durante l'elaborazione della direttiva ssl_engine, viene caricata la libreria condivisa specificata nella direttiva. SSL-il motore.
Per caricare la propria libreria sul server Kubernetes, i ricercatori hanno sfruttato (CVE-2025-1974) il fatto che durante l'elaborazione di grandi richieste, nginx salva il corpo della richiesta in un file temporaneo, che viene subito eliminato, ma nel file system "/proc" rimane un descrittore di file aperto per quel file. In questo modo, è possibile inviare contemporaneamente richieste per salvare il file temporaneo e avviare la verifica della configurazione, in cui nella direttiva "ssl_engine" è specificato il percorso al descrittore nel file system "/proc".
Per garantire che il descrittore di file rimanga accessibile a lungo, il valore "Content-Length" nella richiesta può essere impostato su un valore notevolmente superiore a quello dei dati effettivamente trasmessi (il server attenderà la ricezione dei dati rimanenti). Un'ulteriore difficoltà è la necessità di indovinare il PID del processo e il numero del descrittore di file associato alla libreria condivisa caricata, ma poiché di solito nel contenitore viene utilizzato un numero minimo di processi in esecuzione, i valori richiesti vengono indovinati tramite tentativi successivi. In caso di successo e di caricamento della libreria condivisa sostituita, l'attaccante può accedere ai parametri memorizzati all'interno dell'ambiente pod, sufficienti per gestire l'intero cluster.
Per verificare l'uso dell'ingress-nginx vulnerabile, è possibile eseguire il comando: kubectl get pods —all-namespaces —selector app.kubernetes.io/name=ingress-nginx
Fonte: opennet.ru
