Im sich entwickelnden Kubernetes-Ingress-Controller ingress-nginx wurden vier Schwachstellen entdeckt, die es ermöglichen, eigenen Code auf den Servern von Cloud-Systemen, die die Kubernetes-Plattform verwenden, auszuführen und vollen privilegierten Zugriff auf das Kubernetes-Cluster zu erhalten. Den Problemen wurde ein kritisches Gefahrenlevel (9,8 von 10) zugewiesen. Die entdeckenden Forscher gaben den Schwachstellen den Code-Namen IngressNightmare und bemerkten, dass etwa 43 % der Cloud-Umgebungen betroffen sind. Die Schwachstellen 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 ingress-nginx-Controller ist der beliebteste und setzt der Server NGINX wird verwendet, um Anfragen an das Cluster weiterzuleiten, externe Anfragen zu routen und die Last zu balancieren. Das Kubernetes-Projekt stellt grundlegende Ingress-Controller für AWS, GCE und nginx zur Verfügung, wobei letzterer nicht mit dem kubernetes-ingress-Controller verbunden ist, dessen Wartung von der Firma F5/NGINX durchgeführt wird (die besprochenen Schwachstellen betreffen nicht die von den Entwicklern von NGINX entwickelten Projekte; die Erwähnung von nginx im Namen ingress-nginx steht lediglich im Zusammenhang mit der Verwendung von nginx als Proxy).
Sicherheitsanfälligkeiten ermöglichen es einem nicht authentifizierten Angreifer, seinen Code im Kontext des ingress-nginx-Controllers auszuführen und dabei eine Anfrage an den Admission-Web-Handler zu senden. Während der Netzwerkscans wurden über 6500 anfällige Kubernetes-Cluster identifiziert, die öffentliche, verwundbare 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 Kubernetes-Server gespeichert sind, was privilegierten Zugriff auf das gesamte Cluster ermöglicht. Als Umgehung des Schutzes wird empfohlen, die Funktion „Validating Admission Controller“ im ingress-nginx zu deaktivieren.
Der Admission-Controller wird in einer separaten Pod-Umgebung ausgeführt und führt die Überprü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 Überprü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 entdeckten Schwachstellen ermöglichen es, eigene Einstellungen in nginx einzufügen, indem ein speziell gestaltetes Ingress-Objekt direkt an den Admission-Controller gesendet wird. Forscher haben festgestellt, dass einige Eigenschaften der Überprüfungsanfragen, die im Feld „.request.object.annotations“ angegeben sind, direkt in die nginx-Konfiguration eingefügt werden. Dabei wird die generierte Konfiguration nicht angewendet, sondern nur durch Ausführen der ausführbaren Datei „nginx“ mit der Option „-t“ getestet.
Insbesondere erfolgt die Einfügung 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). Zum Beispiel wird in der Konfigurationszeile „set $target {{ $externalAuth.URL }};“ anstelle von „{{ $externalAuth.URL }}“ die im Parameter „auth-url“ angegebene URL eingesetzt. Dabei wird die Gültigkeit der URL nicht überprüft. Dementsprechend kann ein Angreifer einen Wert wie „http://example.com/#;\nEinstellungen“ als URL übergeben und seine eigenen Einstellungen in die Konfigurationsdatei einfügen.
Um beliebigen Code während der Überprüfung der Konfiguration mit dem Befehl „nginx -t“ auszuführen, haben die Forscher ausgenutzt, dass nginx neben der Syntaxprüfung auch Bibliotheken mit Modulen lädt und die in der Konfiguration genannten Dateien öffnet, um deren Verfügbarkeit zu überprüfen. Unter anderem wird beim Verarbeiten der Direktive ssl_engine die angegebene gemeinsame Bibliothek geladen für SSL-den Engine.
Um ihre Bibliothek auf dem Kubernetes-Server zu laden, haben die Forscher (CVE-2025-1974) ausgenutzt, dass nginx bei der Verarbeitung großer Anfragen den Körper der Anfrage in einer temporären Datei speichert, die sofort gelöscht wird, aber im Dateisystem „/proc“ für diese Datei bleibt ein offener Dateideskriptor erhalten. Auf diese Weise können gleichzeitig Anfragen gesendet werden, um die temporäre Datei zu speichern und die Konfigurationsprüfung zu initiieren, in der die Direktive „ssl_engine“ auf den Deskriptor im Dateisystem „/proc“ verweist.
Um sicherzustellen, dass der Dateideskriptor über einen längeren Zeitraum verfügbar bleibt, kann der Wert "Content-Length" in der Anfrage bewusst höher angegeben werden als die tatsächlich übertragenen Daten (der Server wartet auf den Empfang der verbleibenden Daten). Eine zusätzliche Komplexität besteht darin, die PID des Prozesses und die Nummer des Dateideskriptors, der mit der geladenen gemeinsamen Bibliothek verbunden ist, zu erraten. Da jedoch im Container in der Regel nur eine geringe Anzahl von Prozessen läuft, können die erforderlichen Werte durch Ausprobieren in mehreren Versuchen erraten werden. Im Erfolgsfall und bei der Lade der angegebenen gemeinsamen Bibliothek kann der Angreifer auf die im Pod-Umfeld gespeicherten Parameter zugreifen, die ausreichen, um den gesamten Cluster zu steuern.
Um die Verwendung 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
