Im entwickelten Kubernetes-Ingress-Controller ingress-nginx wurden vier Sicherheitsanfälligkeiten entdeckt, die es ermöglichen, eigenen Code auf den Servern von Cloud-Systemen, die die Kubernetes-Plattform verwenden, auszuführen und vollständigen privilegierten Zugriff auf den Kubernetes-Cluster zu erhalten. Den Problemen wurde ein kritisches Gefahrenlevel (9,8 von 10) zugewiesen. Die Entdecker der Probleme haben den Schwachstellen den Codenamen IngressNightmare zugewiesen und festgestellt, dass etwa 43 % der Cloud-Umgebungen betroffen sind. Die Sicherheitsanfälligkeiten wurden in den Versionen ingress-nginx 1.11.5 und 1.12.1 behoben.
Der Ingress-Controller fungiert als Gateway und wird in Kubernetes verwendet, um den Zugriff aus dem externen Netzwerk auf die Dienste innerhalb des Clusters zu organisieren. Der Controller ingress-nginx ist der am weitesten verbreitete und verwendet Server NGINX, um Anfragen an den Cluster weiterzuleiten, externe Anfragen zu routen und die Last zu verteilen. Das Kubernetes-Projekt bietet grundlegende Ingress-Controller für AWS, GCE und nginx, letzterer hat keinen Bezug zum kubernetes-ingress-Controller, dessen Pflege das Unternehmen F5/NGINX übernimmt (die angeführten Sicherheitsanfälligkeiten betreffen nicht die Projekte, die von den Entwicklern von NGINX weiterentwickelt werden; die Nennung von nginx im Namen ingress-nginx bezieht sich lediglich auf den Einsatz von nginx als Proxy).
Die Sicherheitsanfälligkeiten ermöglichen es einem nicht authentifizierten Angreifer, eigenen Code im Kontext des Controllers ingress-nginx auszuführen, wenn die Möglichkeit besteht, eine Anfrage an den Admission-Web-Handler zu senden. Bei einer Netzwerküberprüfung wurden über 6500 anfällige Kubernetes-Cluster erkannt, die öffentlich zugängliche anfällige Controller mit einem für externe Anfragen offenen Admission-Handler verwenden.
In der Standardkonfiguration kann der vom Angreifer gestartete Code auf die Einstellungen des Ingress-Objekts zugreifen, in denen unter anderem auch die Anmeldedaten für den Zugriff auf die Kubernetes-Server gespeichert sind, was es ermöglicht, privilegierten Zugriff auf den gesamten Cluster zu erhalten. Als Schutzalternative wird empfohlen, die Funktion „Validating Admission Controller“ in ingress-nginx zu deaktivieren.
Der Admission-Controller wird in einer separaten Pod-Umgebung gestartet und führt eine Prüfung der eingehenden Ingress-Objekte vor deren Bereitstellung durch. Standardmäßig akzeptiert der Admission-Web-Handler Anfragen ohne Authentifizierung aus dem öffentlichen Netzwerk. Bei der Durchführung der Prüfung erstellt der Admission-Controller eine Konfiguration für den HTTP-Server Nginx basierend auf dem Inhalt des erhaltenen Ingress-Objekts und überprüft deren Richtigkeit.
Die identifizierten Schwachstellen ermöglichen es, eigene Einstellungen in Nginx zu injizieren, indem ein speziell gestaltetes Ingress-Objekt direkt an den Admission-Controller gesendet wird. Forscher haben entdeckt, dass einige Eigenschaften der Prüfungsanfragen, die im Feld „.request.object.annotations“ festgelegt sind, direkt in die Nginx-Konfiguration übernommen werden. Dabei wird die generierte Konfiguration nicht angewendet, sondern lediglich getestet, indem die ausführbare Datei „nginx“ mit der Option „-t“ gestartet wird.
Insbesondere erfolgt die Injektion externer Daten in die Konfiguration für die Parameter „mirror-target“, „mirror-host“ (CVE-2025-1098), „auth-tls-match-cn“ (CVE-2025-1097) und „auth-url“ (CVE-2025-24514). Beispielsweise wird in der Konfigurationszeile „set $target {{ $externalAuth.URL }};“ anstelle von „{{ $externalAuth.URL }}“ die im Parameter „auth-url“ angegebene URL eingesetzt. Dabei wird die Richtigkeit der URL nicht überprüft. Dementsprechend kann ein Angreifer als URL einen Wert wie „http://example.com/#; Einstellungen“ übermitteln und seine eigenen Einstellungen in die Konfigurationsdatei einfügen.
Um beliebigen Code im Rahmen der Konfigurationsüberprüfung mit dem Befehl „nginx -t“ auszuführen, nutzten die Forscher aus, dass Nginx neben der Überprüfung der Syntax auch Bibliotheken mit Modulen lädt und Dateien öffnet, die in der Konfiguration erwähnt werden, um deren Verfügbarkeit zu überprüfen. Unter anderem wird bei der Verarbeitung der Direktive ssl_engine die in der Direktive angegebene gemeinsame Bibliothek geladen für SSL-den Engine.
Um ihre Bibliothek auf den Kubernetes-Server zu laden, verwendeten die Forscher (CVE-2025-1974), dass Nginx bei der Verarbeitung großer Anfragen den Anfrageinhalt in einer temporären Datei speichert, die sofort gelöscht wird; jedoch bleibt im Dateisystem „/proc“ ein offener Dateideskriptor für diese Datei. So können gleichzeitig Anfragen gesendet werden, um die temporäre Datei zu speichern und die Konfigurationsprüfung zu initiieren, in der der Pfad zum Deskriptor im Dateisystem „/proc“ in der Direktive „ssl_engine“ angegeben ist.
Damit der Dateideskriptor längere Zeit zugänglich bleibt, kann der Wert für „Content-Length“ in der Anfrage absichtlich größer angegeben werden als die tatsächlich übermittelten Daten (der Server wird auf den Empfang der verbleibenden Daten warten). Eine zusätzliche Schwierigkeit besteht darin, die PID des Prozesses und die Nummer des Dateideskriptors, der mit der geladenen Shared Library verbunden ist, zu erraten. Da jedoch im Container normalerweise eine minimale Anzahl von Prozessen ausgeführt wird, können die benötigten Werte durch Ausprobieren in mehreren Versuchen erraten werden. Im Erfolgsfall und bei der Laden der eingesetzten Shared Library kann der Angreifer auf die innerhalb der Pod-Umgebung gespeicherten Parameter zugreifen, die ausreichen, um den gesamten Cluster zu steuern.
Um die Nutzung der verwundbaren ingress-nginx zu überprüfen, kann der Befehl ausgeführt werden: kubectl get pods —all-namespaces —selector app.kubernetes.io/name=ingress-nginx
Quelle: opennet.ru
