Nel progetto in fase di sviluppo del controller ingress Kubernetes ingress-nginx sono state identificate quattro vulnerabilità che consentono di eseguire codice malevolo sui server delle piattaforme cloud che utilizzano Kubernetes, ottenendo accesso privilegiato completo al cluster Kubernetes. Questi problemi sono stati classificati con un livello critico di gravità (9.8 su 10). I ricercatori che hanno scoperto le vulnerabilità hanno assegnato il nome in codice IngressNightmare e hanno notato che riguardano 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 gestire l'accesso dalla rete esterna ai servizi all'interno del cluster. Il controller ingress-nginx è il più popolare e viene applicato un 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 è collegato al controller kubernetes-ingress, il cui supporto è gestito da F5/NGINX (le vulnerabilità considerate non interessano i progetti sviluppati dagli sviluppatori di NGINX, la menzione di nginx nel nome ingress-nginx è legata solo all'utilizzo di nginx come proxy).
Le vulnerabilità consentono a un attaccante non autenticato di eseguire codice nel contesto del controller ingress-nginx, nel caso in cui possa inviare una richiesta al gestore web Admission. Durante la scansione della rete sono stati identificati oltre 6500 cluster Kubernetes vulnerabili, che utilizzano controller vulnerabili pubblicamente con gestori Admission aperti a richieste esterne.
Nella configurazione predefinita, il codice eseguito da un attaccante può accedere alle impostazioni dell'oggetto Ingress, che contengono, tra l'altro, le credenziali per accedere ai server Kubernetes, consentendo di ottenere privilegi su tutto il cluster. Si raccomanda di disabilitare la funzione "Validating Admission Controller" in ingress-nginx come misura di protezione alternativa.
Il controllore Admission viene eseguito in un ambiente pod separato e svolge l'operazione di verifica degli oggetti ingress in arrivo prima della loro distribuzione. Per impostazione predefinita, il web-handler Admission accetta richieste senza autenticazione dalla rete pubblica. Durante la verifica, il controllore Admission crea una configurazione per il server http nginx basata sui contenuti dell'oggetto ingress ricevuto e ne verifica la correttezza.
Le vulnerabilità rilevate consentono di iniettare le proprie configurazioni in nginx inviando un oggetto ingress appositamente formattato direttamente al controller di Admission. I ricercatori hanno scoperto che alcune proprietà delle richieste di verifica, impostate nel campo «.request.object.annotations», vengono direttamente trasferite nella configurazione di nginx. Tuttavia, la configurazione generata non viene applicata, ma solo testata eseguendo il file eseguibile «nginx» con l'opzione «-t».
In particolare, l'inserimento 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 }};» invece di «{{ $externalAuth.URL }}» viene inserito l'URL specificato nel parametro «auth-url». La correttezza dell'URL non viene verificata. Di conseguenza, un attaccante può inviare come URL un valore del tipo «http://example.com/#;\nconfigurazioni» e inserire le proprie impostazioni nel file di configurazione.
Per eseguire codice arbitrario durante il controllo della configurazione con il comando «nginx -t», i ricercatori hanno sfruttato il fatto che, oltre al controllo della sintassi, nginx carica librerie con i moduli e apre file menzionati nella configurazione per verificarne l'accessibilità. Tra l'altro, durante l'elaborazione della direttiva ssl_engine viene caricata la libreria condivisa specificata nella direttiva per SSL-il motore.
Per caricare la propria libreria nel server Kubernetes, i ricercatori hanno sfruttato (CVE-2025-1974) il fatto che, durante l'elaborazione di richieste di grandi dimensioni, nginx salva il corpo della richiesta in un file temporaneo, che viene subito eliminato, ma nel filesystem «/proc» rimane un descrittore di file aperto per questo file. Così, è possibile inviare contemporaneamente richieste per salvare il file temporaneo e avviare il controllo della configurazione, in cui nella direttiva «ssl_engine» è specificato il percorso al descrittore nel filesystem «/proc».
Per garantire che il descrittore di file rimanga disponibile per un lungo periodo, si può specificare un valore "Content-Length" nella richiesta che è consapevolmente maggiore rispetto ai dati effettivamente trasmessi (il server attenderà la ricezione dei dati rimanenti). Ulteriore complessità è 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 necessari vengono indovinati attraverso tentativi. In caso di successo e di caricamento della libreria condivisa inserita, l'attaccante può accedere ai parametri memorizzati all'interno dell'ambiente pod, sufficienti per gestire l'intero cluster.
Per verificare l'utilizzo di ingress-nginx vulnerabile, è possibile eseguire il comando: kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
Fonte: opennet.ru
