IngressNightterror (CVE-2025-1974)

Übersicht

Dieses Repository enthält meine Forschung zur IngressNightmare-Schwachstelle. Es enthält verwundbare Ingress-Deploy-Dateien, den Exploit selbst und ein Shared-Object-Payload.

CVE

Die Liste der CVE-Indizes:

• CVE-2025-1974 - Hauptschwachstelle
• CVE-2025-24514 - auth-url-Annotation-Injection
• CVE-2025-1097 - auth-tls-match-cn-Annotation-Injection
• CVE-2025-1098 - Missbrauch der Image-UID

Referenzen

Nur ein paar Referenzen:

• Originalbeitrag der WIZ Research
• Kubernetes GitHub Issue
• Kubernetes Blogbeitrag
• Amazon AWS Bulletin
• Google Cloud Bulletin

Grundursache

Der Kern dieser Schwachstelle liegt im Fehlen einer ordnungsgemäßen Eingabebereinigung. Wenn du eine AdmissionReview-Anfrage sendest, wird eine temporäre NGINX-Konfiguration erstellt, die anschließend mit dem Befehl nginx -t auf Gültigkeit geprüft wird. Siehe den Quellcode, in dem der Fehler behoben wurde.

Die Möglichkeit, den Inhalt der getesteten Konfiguration zu kontrollieren, erlaubt es uns, eine Vielzahl von Konfigurationsfeldern zu nutzen, um fehlerhafte Konfiguration einzuschleusen:

• auth-url - wird ohne ordnungsgemäße Bereinigung verarbeitet und erlaubt uns, ein # und \n einzufügen. Diesen Injektionspunkt werden wir nutzen.
• auth-tls-match-cn - erfordert lediglich, dass das Feld mit CN= beginnt und ein gültiger regulärer Ausdruck ist.
• ing.UID - die UID wird unverändert in die Konfiguration übernommen.

Die Tatsache, dass die NGINX-Konfiguration nur getestet wird, reduziert die Anzahl der verwendbaren Direktiven etwas. Eine der verbleibenden Direktiven ist ssl_engine, mit der wir gemeinsam genutzte Bibliotheken (Shared Libraries) laden können. Das ist ein guter Einstiegspunkt. Aber wie können wir unsere .so-Datei in das Dateisystem des Pods bringen?

Die klugen Köpfe von WIZ kamen auf die Idee, eine Anfrage mit unserem .so-Objekt als Body zu senden. Wenn es groß genug ist, speichert NGINX es als Datei in procfs! Wir können auch die Content-Length anpassen, sodass NGINX auf weitere Daten wartet und die Datei dadurch eine Zeit lang in procfs bleibt. Die tatsächliche PID- und FD-Nummer müssen erraten werden.

Weitere Informationen findest du im ursprünglichen Analyse-Artikel des WIZ-Forschungsteams.

Ausnutzung

Der Exploit-Code ist ziemlich selbsterklärend. Schau dir also den Quellcode an.

Einrichtung der Testumgebung

1. Klone das Repository:

   root@kitploit:~

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

2. Starte ein Docker-k3s-Image:

   root@kitploit:~

   cd stand
   docker compose up -d
   

3. Stelle den NGINX Ingress bereit:

   Falls du Linux/Mac verwendest, kannst du ihn mit einem Skript bereitstellen:

   root@kitploit:~

   ./k8s/setup.sh
   

   ---

   Wenn du Windows verwendest oder mehr Kontrolle über den Bereitstellungsprozess haben möchtest, führe die Schritte manuell aus:

   NGINX Ingress bereitstellen:

   root@kitploit:~

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

   Jetzt kannst du kubectl mit der in ./output bereitgestellten Konfiguration verwenden. Vergiss nicht, den Namespace ingress-nginx zu verwenden.

   Wichtiger Hinweis: Die ingress.yaml wurde aus dem verwundbaren NGINX Ingress erstellt.

Payload (Shared Object)

Der Payload ist ein einfacher Reverse-Proxy. Vergiss nicht, Port und IP-Adresse zu bearbeiten, bevor du ihn mit folgendem Befehl baust:

make all

Das Shared Object wird mithilfe des Docker-Containers gcc:latest erstellt.

Danksagungen

Großer Respekt an das WIZ-Forschungsteam, das die Schwachstelle ursprünglich entdeckt hat, und an die Maintainer von NGINX Ingress.

Produziert von I3r1h0n.