IngressNightterror (CVE-2025-1974)

Panoramica

Questo repository contiene la mia ricerca sulla vulnerabilità IngressNightmare. Include file di deploy Ingress vulnerabili, l'exploit stesso e un payload di oggetto condiviso.

CVE

Elenco degli indici CVE:

• CVE-2025-1974 - Vulnerabilità principale
• CVE-2025-24514 - Iniezione annotazione auth-url
• CVE-2025-1097 - Iniezione annotazione auth-tls-match-cn
• CVE-2025-1098 - Abuso dell'UID dell'immagine

Riferimenti

Solo alcuni riferimenti:

• Post originale della ricerca WIZ
• Problema su GitHub di Kubernetes
• Post del blog di Kubernetes
• Bollettino di Amazon AWS
• Bollettino di Google Cloud

Causa principale

La radice di questa vulnerabilità risiede nella mancanza di una corretta sanitizzazione dell'input. Quando invii una richiesta AdmissionReview, viene creata una configurazione NGINX temporanea che viene successivamente testata per la validità utilizzando il comando nginx -t. Vedi il codice sorgente con il bug mitigato.

La capacità di controllare il contenuto della configurazione testata ci permette di utilizzare una vasta gamma di campi di configurazione per iniettare configurazioni malformate:

• auth-url - viene passata senza una corretta sanitizzazione, permettendoci di aggiungere un # e un \n. Useremo questo punto di iniezione.
• auth-tls-match-cn - richiede solo che il campo inizi con CN= e sia un regex valido.
• ing.UID - l'UID viene inserito nella configurazione così com'è.

Il fatto che la configurazione NGINX venga solo testata riduce leggermente il numero di direttive che possiamo utilizzare. Una delle direttive rimaste è ssl_engine, che ci permette di caricare librerie condivise. Questo è un buon punto di ingresso. Ma come possiamo mettere il nostro file .so nel filesystem del pod?

Le persone intelligenti di WIZ hanno avuto l'idea di inviare una richiesta con il nostro oggetto .so come corpo, e se è abbastanza grande, NGINX lo salva in un file in procfs! Possiamo anche regolare il Content-Length, facendo sì che NGINX attenda più dati, causando la conservazione del file in procfs per un po' di tempo. Il PID e FD effettivi verranno indovinati.

Per maggiori informazioni, leggi l'articolo di analisi originale article del team di ricerca WIZ.

Sfruttamento

Il codice dell'exploit è abbastanza autoesplicativo. Quindi vai a guardare il sorgente.

Configurazione dello Stand

1. Clona il repository:

   root@kitploit:~

   git clone https://github.com/I3r1h0n/IngressNightterror
   cd IngressNightterror
   

2. Avvia un'immagine docker k3s:

   root@kitploit:~

   cd stand
   docker compose up -d
   

3. Distribuisci NGINX Ingress:

   Nel caso tu stia usando Linux/Mac, puoi distribuirlo usando lo script:

   root@kitploit:~

   ./k8s/setup.sh
   

   ---

   Se sei su Windows, o vuoi più controllo sul processo di distribuzione, fallo manualmente:

   Distribuisci NGINX Ingress:

   root@kitploit:~

   kubectl --kubeconfig=./output/kubeconfig.yaml apply -f ./k8s/ingress.yaml
   

   Ora puoi usare kubectl con la configurazione fornita in ./output. Non dimenticare di usare il namespace ingress-nginx.

   Nota importante: il file ingress.yaml è creato dalla versione vulnerabile di NGINX Ingress

Payload oggetto condiviso

Il payload è un semplice proxy inverso. Non dimenticare di modificare la porta e l'indirizzo IP prima di compilarlo con:

make all

Costruirà l'oggetto condiviso usando il container docker gcc:latest.

Crediti

Grande rispetto al Team di Ricerca WIZ che ha originariamente scoperto la vulnerabilità e ai manutentori di NGINX Ingress.

prodotto da I3r1h0n.