V rozvíjející se aplikaci Kubernetes ingress-kontroleru ingress-nginx byly odhaleny čtyři zranitelnosti, které umožňují provést spuštění vlastního kódu na serverech cloudových systémů využívajících platformu Kubernetes a získat plný privilegovaný přístup k clusteru Kubernetes. Problémům byla přiřazena kritická úroveň nebezpečnosti (9.8 z 10). Výzkumníci, kteří odhalili problémy, přiřadili zranitelnostem kódové jméno IngressNightmare a poznamenali, že se zranitelnosti dotýkají přibližně 43 % cloudových prostředí. Zranitelnosti byly odstraněny ve verzích ingress-nginx 1.11.5 a 1.12.1.
Ingress kontrolér funguje jako brána a používá se v Kubernetes k organizaci přístupu ze vnější sítě k službám uvnitř clustru. Kontrolér ingress-nginx je nejpopulárnější a využívá server NGINX pro přesměrování požadavků na cluster, směrování externích požadavků a vyvažování zátěže. Projekt Kubernetes poskytuje základní ingress-kontrolery pro AWS, GCE a nginx, což není nijak spojeno s kontrolerem kubernetes-ingress, jehož údržbu zajišťuje společnost F5/NGINX (zmiňované zranitelnosti se netýkají projektů vyvíjených vývojáři NGINX, zmínka o nginx v názvu ingress-nginx souvisí pouze s využitím nginx jako proxy).
Zranitelnosti umožňují neautentizovanému útočníkovi provést spuštění vlastního kódu v kontextu kontroleru ingress-nginx s možností odeslání požadavku na webový zpracovatel Admission. Během skenování sítě bylo odhaleno více než 6500 zranitelných clusterů Kubernetes, které využívají veřejně dostupné zranitelné kontrolery s otevřeným zpracovatelem Admission pro externí požadavky.
V defaultní konfiguraci může spuštěný útočný kód získat přístup k nastavením objektu Ingress, v nichž jsou mimo jiné uloženy i autentizační údaje pro přístup k serverům Kubernetes, což umožňuje dosáhnout privilegovaného přístupu k celému clusteru. Jako obranou strategií se doporučuje vypnout v ingress-nginx funkci „Validating Admission Controller“.
Kontroler Admission běží v samostatném pod-okolí a provádí operaci ověřování příchozích ingress-objektů před jejich nasazením. Ve výchozím nastavení webový zpracovatel Admission přijímá požadavky bez autentizace z veřejné sítě. Během ověřování kontroler Admission vytváří konfiguraci pro http-server nginx na základě obsahu přijatého ingress-objektu a kontroluje její správnost.
Zjištěné zranitelnosti umožňují vložení vlastních nastavení do nginx prostřednictvím odeslání speciálně formátovaného ingress objektu přímo do Admission kontroléru. Výzkumníci zjistili, že některé vlastnosti kontrolních požadavků, které jsou uvedeny v poli „.request.object.annotations“, jsou přímo vloženy do konfigurace nginx. Přitom generovaná konfigurace není aplikována, ale pouze testována spuštěním spustitelného souboru „nginx“ s volbou „-t“.
Konkrétně, vložení externích dat do konfigurace se provádí pro parametry „mirror-target“, „mirror-host“ (CVE-2025-1098), „auth-tls-match-cn“ (CVE-2025-1097) a „auth-url“ (CVE-2025-24514). Například v řádku konfigurace „set $target {{ $externalAuth.URL }};“ je místo „{{ $externalAuth.URL }}“ vložena URL adresa zadaná v parametru „auth-url“. Při tom není ověřována správnost URL. Útočník tedy může předat jako URL hodnotu ve formátu „http://example.com/#; nastavení“ a vložit svá vlastní nastavení do konfiguračního souboru.
K provedení libovolného kódu během kontroly konfigurace příkazem „nginx -t“ výzkumníci využili skutečnosti, že kromě kontroly syntaxe nginx načítá knihovny s moduly a otevírá soubory uvedené v konfiguraci pro posouzení jejich dostupnosti. Mezi jiným, při zpracování direktivy ssl_engine dochází k načtení údajné sdílené knihovny uvedené v direktivě. SSL-enginu.
Pro načtení své knihovny na server Kubernetes výzkumníci využili (CVE-2025-1974) skutečnost, že při zpracování velkých požadavků nginx uchovává tělo požadavku v dočasném souboru, který je okamžitě smazán, ale v souborovém systému „/proc“ zůstává pro tento soubor otevřený deskriptor souboru. Takovým způsobem lze současně odeslat požadavky na uložení dočasného souboru a iniciaci kontroly konfigurace, ve které je v direktivě „ssl_engine“ uvedena cesta k deskriptoru v souborovém systému „/proc“.
Aby byl souborový popisovač dlouhodobě dostupný, může být hodnota „Content-Length“ v požadavku nastavena na zjevně větší, než fakticky přenášená data (server bude čekat na příjem zbývajících dat). Další komplikací je nutnost uhodnout PID procesu a číslo souborového popisovače spojeného s načtenou sdílenou knihovnou, ale protože v kontejneru je obvykle používáno minimální množství spuštěných procesů, potřebné hodnoty se hádají pomocí několika pokusů. V případě úspěchu a načtení dodávané sdílené knihovny může útočník získat přístup k uloženým parametrům uvnitř pod-životního prostředí, které jsou dostatečné pro ovládání celého clusteru.
Pro kontrolu použití zranitelného ingress-nginx můžete provést příkaz: kubectl get pods —all-namespaces —selector app.kubernetes.io/name=ingress-nginx
Zdroj: opennet.ru
