IngressNightmare: vulnerabilità e rimedio all'esecuzione di codice remoto CVE-2025-1974

Il maggio 2025 ha segnato la divulgazione pubblica di una vulnerabilità di sicurezza critica, CVE-2025-1974, soprannominata IngressNightmare, che colpisce il controller ingress-nginx di Kubernetes, ampiamente distribuito nelle infrastrutture cloud native. Questa vulnerabilità consente agli aggressori non autenticati di iniettare configurazioni arbitrarie in NGINX, portando potenzialmente a RCE (esecuzione di codice remoto) non autorizzati e alla compromissione completa del cluster.

Nell'ambito del programma OPSWAT Fellowship, i nostri borsisti hanno condotto un'analisi tecnica approfondita per comprendere meglio le cause, il percorso di sfruttamento e le strategie di mitigazione di questo problema ad alta gravità.

1. Ogni configurazione viene analizzata e passata a generateTemplate per essere formattata secondo i modelli NGINX predefiniti.
2. Successivamente, testTemplate convalida la configurazione generata con il binario NGINX sottostante.

Tutte le configurazioni di NGINX si basano su modelli predefiniti che si trovano nel file nginx.tmpl all'interno del codice sorgente di ingress-nginx:

All'interno della funzione generateTemplate, la configurazione viene elaborata come mostrato nel seguente frammento di codice:

Tuttavia, la validazione e la sanitizzazione dell'input sono insufficienti. In particolare, il campo uid di un oggetto Ingress viene inserito direttamente nel modello di configurazione di NGINX, creando un punto di iniezione. Un utente malintenzionato può sfruttare questa situazione fornendo un input di tipo artigianale, come uid="1234#;\n}\n}}n}n injection_value".

Questo input dannoso consente l'iniezione dell'ambito globale nel modello NGINX, consentendo agli aggressori di attivare direttive NGINX arbitrarie e di ottenere potenzialmente un RCE.

Per sfruttare la vulnerabilità, un aggressore deve identificare una direttiva in grado di eseguire codice dannoso. Inizialmente, i nostri collaboratori hanno identificato la direttiva load_module come potenzialmente utile, poiché questa direttiva consente a NGINX di caricare plugin esterni. Tuttavia, questa direttiva è consentita solo nella fase iniziale dell'analisi della configurazione, il che non corrisponde al nostro punto di iniezione.

Per risolvere questa sfida, abbiamo proseguito le ricerche, che hanno portato alla direttiva ssl_engine, descritta come "Il modulo può essere caricato dinamicamente da OpenSSL durante i test di configurazione". Questo ha suscitato curiosità per la sua capacità di caricare dinamicamente i moduli, rendendo necessario un esame più approfondito.

All'avvio, NGINX carica il suo stato iniziale, quindi analizza i file di configurazione riga per riga. Ogni direttiva è gestita dalla struttura nginx_command_t, con la direttiva ssl_engine che invoca direttamente i ngx_openssl_commands.

Analizzando la funzione ngx_openssl_commands, i nostri collaboratori hanno scoperto che si basa sul supporto di OpenSSL, in particolare sulla funzione ENGINE_by_id, utilizzata per i moduli SSL con accelerazione hardware.

Analizzando la funzione ENGINE_by_id, abbiamo scoperto che consente il caricamento dinamico delle librerie condivise. Inoltre, se la libreria è compilata con l'estensione __attribute__((constructor)), la funzione associata può essere eseguita immediatamente dopo il caricamento. Ciò indica che sfruttando la direttiva ssl_engine, un aggressore potrebbe caricare librerie condivise arbitrarie sull'host, portando potenzialmente a un RCE.

Per impostazione predefinita, quando una richiesta in arrivo supera gli 8KB, NGINX scrive il corpo della richiesta in un file temporaneo situato in /tmp/nginx/client-body, utilizzando un nome di file nel formato cfg-{random_value}. Questi file temporanei vengono conservati per un massimo di 60 secondi tra le parti di un messaggio ricevuto.

Dopo aver scritto un corpo parziale della richiesta in un file temporaneo, NGINX rinvia la cancellazione fino a quando non viene ricevuto l'intero corpo. Se la richiesta rimane incompleta e non vengono ricevuti dati per un massimo di 60 secondi, il file viene infine eliminato. Tuttavia, trattenendo intenzionalmente l'ultimo pezzo di dati, un aggressore può mantenere il file temporaneo in uso, rendendolo sfruttabile.

Sebbene il contenuto del file caricato possa essere controllato, la sua localizzazione nel file system è difficile a causa del nome del file randomizzato. Il percorso di memorizzazione può essere configurato utilizzando client_body_temp_path, ma il nome del file viene generato casualmente in fase di esecuzione, rendendolo imprevedibile. Questa casualità ostacola in modo significativo l'accesso mirato anche attraverso la forza bruta. Per ovviare a questo problema, il team ha sfruttato i comportamenti intrinseci al sistema operativo Linux. Si consideri il seguente esempio:

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).

Dopo la compilazione, la dimensione della libreria condivisa risultante superava comodamente gli 8KB, consentendo il buffering da parte di NGINX senza richiedere un padding aggiuntivo.

I nostri colleghi hanno quindi creato una richiesta con un valore di Content-Length gonfiato (ad esempio, 1MB) per introdurre un disallineamento delle dimensioni. Questo ha fatto sì che NGINX bufferizzasse l'intero corpo anziché elaborarlo immediatamente, assicurando che l'oggetto condiviso venisse scritto in una posizione prevedibile.

Il successo dell'RCE richiede che la direttiva ssl_engine faccia riferimento al percorso corretto del file bufferizzato. Questo può essere ottenuto tramite uno script automatico di forza bruta che itera sistematicamente le possibili combinazioni di ID di processo e descrittori di file per identificare il collegamento simbolico valido che punta all'oggetto condiviso bufferizzato.

Di seguito è riportato un esempio del modello NGINX generato che ha innescato l'exploit.

Una volta sfruttato con successo, l'attaccante potrebbe ottenere l'accesso alla shell nel contesto del pod ingress-nginx, che per impostazione predefinita ha accesso a segreti sensibili del cluster Kubernetes.