W rozwijanym projekcie Kubernetes ingress-kontrolerze ingress-nginx zidentyfikowano cztery luki, które umożliwiają wykonanie kodu na serwerach systemów chmurowych wykorzystujących platformę Kubernetes oraz uzyskanie pełnego dostępu z uprawnieniami do klastra Kubernetes. Problemy te otrzymały krytyczny poziom zagrożenia (9.8 z 10). Badacze, którzy je odkryli, nadali lukom kodową nazwę IngressNightmare i zauważyli, że dotyczą one około 43% środowisk chmurowych. Luki zostały usunięte w wersjach ingress-nginx 1.11.5 i 1.12.1.
Kontroler Ingress pełni rolę bramy i jest używany w Kubernetes do organizacji dostępu z sieci zewnętrznej do usług wewnątrz klastra. Kontroler ingress-nginx jest najpopularniejszy i stosuje serwer NGINX do przekazywania zapytań do klastra, routowania zewnętrznych żądań i równoważenia obciążenia. Projekt Kubernetes dostarcza podstawowe ingress-kontrolery dla AWS, GCE oraz nginx, który nie ma związku z kontrolerem kubernetes-ingress, którym zarządza firma F5/NGINX (rozpatrywane luki nie dotyczą projektów rozwijanych przez deweloperów NGINX, odniesienie do nginx w nazwie ingress-nginx dotyczy jedynie wykorzystania nginx jako proxy).
Luki umożliwiają nieautoryzowanemu atakującemu wykonanie swojego kodu w kontekście kontrolera ingress-nginx, w przypadku możliwości wysłania zapytania do web-obsługiwacza Admission. W trakcie skanowania sieci zidentyfikowano ponad 6500 podatnych klastrów Kubernetes, wykorzystujących publicznie dostępne lukowe kontrolery z otwartym dla zewnętrznych zapytań obsługiwaczem Admission.
W konfiguracji domyślnej uruchomiony kod atakującego może uzyskać dostęp do ustawień obiektu Ingress, w których przechowywane są, między innymi, dane uwierzytelniające do komunikacji z serwerami Kubernetes, co pozwala na uzyskanie dostępu z uprawnieniami do całego klastra. Jako obejście ochrony zaleca się wyłączenie w ingress-nginx funkcji „Validating Admission Controller”.
Kontroler Admission działa w osobnym pod-środowisku i wykonuje operację weryfikacji nadchodzących obiektów ingress przed ich wdrożeniem. Domyślnie web-obsługiwacz Admission przyjmuje zapytania bez uwierzytelnienia z publicznej sieci. Podczas weryfikacji kontroler Admission tworzy konfigurację dla serwera http nginx na podstawie zawartości otrzymanego obiektu ingress i sprawdza jej poprawność.
Wykryte luki umożliwiają wstrzykiwanie własnych ustawień do nginx poprzez wysłanie specjalnie przygotowanego obiektu ingress bezpośrednio do kontrolera Admission. Badacze odkryli, że niektóre właściwości zapytań kontrolnych, ustalone w polu „.request.object.annotations”, są bezpośrednio wstawiane do konfiguracji nginx. Generowana konfiguracja nie jest stosowana, a jedynie testowana poprzez uruchomienie pliku wykonywalnego „nginx” z opcją „-t”.
W szczególności wstrzykiwanie zewnętrznych danych do konfiguracji odbywa się dla parametrów „mirror-target”, „mirror-host” (CVE-2025-1098), „auth-tls-match-cn” (CVE-2025-1097) oraz „auth-url” (CVE-2025-24514). Na przykład w linii konfiguracyjnej „set $target {{ $externalAuth.URL }};” zamiast „{{ $externalAuth.URL }}” wstawiany jest URL podany w parametrze „auth-url”. Przy tym poprawność URL nie jest weryfikowana. W związku z tym atakujący może przesłać jako URL wartość w formacie „http://example.com/#; nastawienia” i wstrzyknąć swoje ustawienia do pliku konfiguracyjnego.
Aby wykonać dowolny kod w trakcie sprawdzania konfiguracji poleceniem „nginx -t”, badacze skorzystali z faktu, że oprócz sprawdzania składni nginx ładował biblioteki z modułami i otwierał pliki wymienione w konfiguracji, aby ocenić ich dostępność. Wśród innych rzeczy, podczas przetwarzania dyrektywy ssl_engine następuje ładowanie wskazanej w dyrektywie biblioteki współdzielonej dla SSL-silnika.
Aby załadować swoją bibliotekę na serwer Kubernetes, badacze skorzystali z (CVE-2025-1974) faktu, że podczas przetwarzania dużych zapytań nginx zapisuje ciało zapytania w pliku tymczasowym, który jest natychmiast usuwany, ale w systemie plików „/proc” dla tego pliku pozostaje otwarty deskryptor pliku. W ten sposób można jednocześnie wysłać zapytania w celu zapisania pliku tymczasowego i zainicjować sprawdzanie konfiguracji, w której w dyrektywie „ssl_engine” wskazany jest ścieżka do deskryptora w systemie plików „/proc”.
Aby uchwyt plikowy pozostawał dostępny przez dłuższy czas, wartość „Content-Length” w żądaniu można ustawić na znacznie większą niż rzeczywiście przesyłane dane (serwer będzie czekał na odbiór pozostałych danych). Dodatkowym utrudnieniem jest konieczność odgadnięcia PID procesu oraz numeru uchwytu plikowego powiązanego z załadowaną wspólną biblioteką, ale ponieważ w kontenerze zwykle działa minimalna liczba procesów, potrzebne wartości są odgadywane metodą prób i błędów. W przypadku sukcesu i załadowania podmienionej wspólnej biblioteki, atakujący może uzyskać dostęp do parametrów przechowywanych wewnątrz pod-środowiska, wystarczających do zarządzania całym klastrem.
Aby sprawdzić użycie podatnego ingress-nginx, można wykonać polecenie: kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
Źródło: opennet.ru
