CVE-2025-1974 — IngressNightmare (ingress-nginx)

Einleitung

Dieses Dokument bietet eine Untersuchung der Schwachstelle CVE-2025-1974, die die Komponente ingress-nginx (Validating Admission Controller) für Kubernetes betrifft.
CVE-2025-1974 ist eine kritische Schwachstelle (CVSS 3.1 9.8), die eine nicht authentifizierte Remote Code Execution (RCE) im Kontext des ingress-nginx-Prozesses darstellt. Bei Ausführung des Angriffs kann ein Angreifer, der Zugriff auf das Pod-Netzwerk hat (oder eine AdmissionReview an den Validating Webhook senden kann), die Ausführung beliebigen Codes im Pod des Controllers erreichen, was potenziell zur Offenlegung von Secrets und zur Übernahme des Clusters führt.

Ingress-nginx ist einer der am weitesten verbreiteten Ingress-Controller in Kubernetes (Schätzungen gehen von einer Nutzung in Dutzenden von Prozent der Cluster aus), daher ist die praktische Auswirkung der Schwachstelle sehr hoch. Beschreibung, technische Analyse und offizielle Empfehlungen für Fixes wurden von Kubernetes, Forschern von Wiz und mehreren Vendor-Blogs veröffentlicht.

---

Ziel des Berichts

Schrittweise Analyse von CVE-2025-1974 und Erstellung der für einen Write-up erforderlichen Materialien:

1. Sammlung und Strukturierung von Materialien. Offizielle Advisories, Forschungs-Write-ups und Vendor-Analysen sammeln; wichtige technische Details und PoC-Richtungen hervorheben.
2. Verständnis des Wesens der Schwachstelle und ihrer Auswirkungen. Grundursache, Angriffskette und mögliche Folgen (RCE → Offenlegung von Secrets → Cluster-Übernahme) erklären.
3. Bestimmung von CPE und Konfigurationsbedingungen. Auflistung der Versionen/Pakete und Konfigurationen von Kubernetes/ingress-nginx, bei denen die Schwachstelle relevant ist.
4. Empfehlungen für sicheres Testen im Labor und Minimierung des Risikos bei Massenüberprüfungen.

---

⚠️ Haftungsausschluss

Diese Untersuchung dient ausschließlich Bildungs- und ethischen Zwecken und ist auf Test-/kontrollierte Umgebungen ausgerichtet.
Starte unter keinen Umständen Exploits/PoCs gegen fremde Cluster oder öffentlich zugängliche Instanzen ohne schriftliche Genehmigung des Eigentümers. Die Veröffentlichung eines voll funktionsfähigen, „weaponized“ PoC im offenen Raum erhöht das Risiko von Missbrauch erheblich – im öffentlichen Teil sind besser ein Safe-PoC und die Methodik anzugeben. (Offizielle Advisories und Anbieter betonen ebenfalls die Vorsicht bei der Verbreitung von Exploits.)

---

CPE und Konfigurationsbedingungen

• cpe:2.3:a:kubernetes:ingress-nginx_controller:<version> — anfällige Versionen von ingress-nginx (in den Advisories sind konkrete Versionen angegeben; aktualisieren Sie die Werte bei der endgültigen Veröffentlichung).
• Anbieter/Distributionen, die den anfälligen Controller enthalten:
  • RKE2 / Rancher-Distributionen mit ingress-nginx bis zu den genannten Patch-Versionen.
  • Harvester-Versionen, die anfälliges ingress-nginx verwenden (Vendor-KB enthält konkrete betroffene Builds).
  • Benutzerdefinierte Cluster, in denen ingress-nginx separat installiert ist (Helm-Chart/Manifest) – Versionen von Chart/Image prüfen.

Konfigurationsbedingungen, unter denen die Schwachstelle relevant ist:

1. Anfällige Version von ingress-nginx (vor dem in den Advisories genannten Release/Patch). Genaue Versionsnummern siehe NVD und Anbieter-Advisories.
2. Validating Admission Webhook ist außerhalb des Pod-Netzwerks erreichbar – wenn der Webhook von außen zugänglich ist (z. B. öffentlicher Endpunkt, Anbieter hat den Dienst versehentlich weitergeleitet), kann der Exploit remote ausgeführt werden. Wiz und andere Forscher haben zahlreiche Fälle öffentlicher Exposition dokumentiert.
3. Fehlen von NetworkPolicy / Isolierung des Pod-Netzwerks: Wenn ein Angreifer Anfragen von einem beliebigen Pod im Cluster-Netzwerk senden kann (kompromittierter Pod), reicht das für die Ausnutzung aus.
4. Fehlen zusätzlicher Validierungen/ACLs vor dem Admission Controller: zusätzliche Filter/Ingress-Proxy-Authentifizierung können das Risiko verringern.
5. Vorhandensein eines ServiceAccounts mit weitreichenden Rechten und Zugriff auf Secrets im Container von ingress-nginx – standardmäßig montiert der Controller oft einen ServiceAccount mit weitreichenden Rechten; dies erhöht die Auswirkungen bei erfolgreicher Ausnutzung.

---

Details der Schwachstelle

Kurzfassung.
Die Schwachstelle wurde in der Komponente Validating Admission Controller des Controllers Ingress-NGINX entdeckt und hängt damit zusammen, wie diese Komponente temporäre NGINX-Konfigurationen basierend auf eingehenden Ingress / AdmissionReview erstellt und überprüft. Während der Verarbeitung generiert der Controller nginx.conf und führt eine Konfigurationsprüfung (nginx -t) durch. Bei unzureichender Bereinigung der Felder von Ingress/AdmissionReview kann ein Angreifer speziell präparierte Fragmente einfügen, die in die generierte Konfiguration gelangen und letztlich zur Ausführung von Befehlen im Controller-Prozess führen – also zu Remote Code Execution (RCE) im Pod von ingress-nginx.

Wichtigste technische Punkte

• Einstiegspunkt. Eingehende AdmissionReview/Ingress-Objekte, die vom Validating Webhook des Controllers akzeptiert werden, dienen als Ausgangsdaten für die Generierung der NGINX-Konfiguration (einschließlich Annotationsfelder, Backend-Einstellungen usw.).
• Ausnutzungsmechanismus. Ein erstellter bösartiger Ingress oder eine direkte AdmissionReview kann kontrollierte Zeichenfolgen in Vorlagen/Konfigurationsfragmente einschleusen. Bei der Überprüfung/Ladung einer solchen nginx.conf kann der Prüfprozess (nginx -t) und nachfolgende Operationen mit der Konfigurationsdatei zur Ausführung beliebigen Codes, zum Schreiben/Starten von Dateien oder zur Ausführung von Befehlen im Kontext des Controllers führen.
• Erforderliche Bedingungen. Für eine erfolgreiche Ausnutzung sind erforderlich: eine anfällige Version von ingress-nginx; die Möglichkeit, eine AdmissionReview an den Validating Webhook zu senden (Zugriff aus dem Pod-Netzwerk oder direkter Netzwerkzugriff); Fehlen von Ausgleichsmaßnahmen – NetworkPolicy, RBAC-Einschränkungen oder zusätzliche Webhook-Authentifizierung. In einigen Szenarien kann die Einschränkung der Create/Update-Berechtigungen umgangen werden, indem eine manipulierte AdmissionReview direkt an den Webhook gesendet wird.

Warum dies gefährlich ist – Folgen der Ausnutzung

Eine erfolgreiche Ausnutzung ermöglicht die Codeausführung im Container von ingress-nginx, was in der Regel Folgendes erlaubt:

• Abrufen des ServiceAccount-Tokens des Controllers und Zugriff auf die Kubernetes-API;
• Lesen von Secrets und anderen vertraulichen Informationen in zugänglichen Namespaces;
• Erstellen/Ändern von Cluster-Ressourcen und Ausweitung des Zugriffs (Privilegieneskalation, Lateral Movement);
• in einigen Fällen – vollständige Cluster-Übernahme.