Në projektin në zhvillim të kontrolluesit ingress të Kubernetes, ingress-nginx, janë identifikuar katër dobësi që lejojnë ekzekutimin e kodit të domosdoshëm në serverat e sistemeve cloud që përdorin platformën Kubernetes dhe sigurojnë akses të plotë me privilegje në klasterin Kubernetes. Problemet kanë marrë një nivel të lartë rreziku (9.8 nga 10). Studiuesit që identifikuan problemet i vunë dobësive emrin IngressNightmare dhe theksuan se këto dobësi prekin rreth 43% të mjediseve cloud. Dobësitë janë eliminuar në versionet ingress-nginx 1.11.5 dhe 1.12.1.
Kontrolluesi ingress vepron si një portë dhe përdoret në Kubernetes për të organizuar aksesin nga rrjeti i jashtëm në shërbimet brenda klasterit. Kontrolluesi ingress-nginx është më i popullarizuari dhe aplikohet server NGINX për kalimin e kërkesave në klaster, rute të kërkesave të jashtme dhe balancimin e ngarkesës. Projekti Kubernetes ofron kontrollues të bazuar infrastukturor për AWS, GCE dhe nginx, i fundit prej të cilëve nuk ka lidhje me kontrolluesin kubernetes-ingress, për mbështetjen e të cilit kujdeset kompania F5/NGINX (vulnerabilitetet e gjithanshme nuk prekin projektet e zhvilluara nga zhvilluesit e NGINX; përmendja e nginx në emrin ingress-nginx lidhet vetëm me përdorimin e nginx si proxy).
Vulnerabilitetet lejojnë një agresor të paautorizuar të arrijë ekzekutimin e kodit të tij në kontekstin e kontrolluesit ingress-nginx, kur është e mundur të dërgojë një kërkesë te web-përpunuesi Admission. Gjatë skanimit të rrjetit janë zbuluar më shumë se 6500 klasterë të prekshëm Kubernetes që përdorin kontrollues të dobët të aksesit publik me përpunuesin Admission të hapur për kërkesat e jashtme.
Në konfigurimin e paracaktuar, kodi i sulmit të lançuar mund të aksesojë cilësimet e objektit Ingress, ku, ndër të tjera, ruhet edhe kredencialet për t'u lidhur me serverat Kubernetes, çka lejon arritjen e aksesit me privilegje në të gjithë klasterin. Si një mënyrë për të anashkaluar mbrojtjen, rekomandohet të çaktivizohet funksioni 'Validating Admission Controller' në ingress-nginx.
Kontrollori Admission ekzekutohet në një ambient të veçantë pod-i dhe kryen operacionin e verifikimit të objekteve ingress që hyjnë para se të vendosen. Nga standardi, përpunuesi web i Admission pranon kërkesa pa autentifikim nga rrjeti publik. Gjatë verifikimit, kontrollori Admission krijon një konfigurim për serverin http të nginx mbi bazën e përmbajtjes së marrë nga objekti ingress dhe e kontrollon për saktësinë e saj.
Dobitja e ndjeshmërisë të zbuluara lejon zëvendësimin e cilësimeve të veta në nginx përmes dërgimit të një objekti ingress të formatuar posaçërisht direkt në kontrolluesin Admission. Kërkuesit kanë zbuluar se disa pronësi të kërkesave të verifikimit, të vendosura në fushën " .request.object.annotations ", zëvendësohen direkt në konfigurimin e nginx. Në këtë rast, konfigurimi i gjeneruar nuk aplikohet, por vetëm testohet përmes ekzekutimit të skedarit "nginx" me opsionin "-t".
Veçanërisht, zëvendësimi i të dhënave të jashtme në konfigurim realizohet për parametrat "mirror-target", "mirror-host" (CVE-2025-1098), "auth-tls-match-cn" (CVE-2025-1097) dhe "auth-url" (CVE-2025-24514). Për shembull, në rreshtin e konfigurimit "set $target {{ $externalAuth.URL }};" në vend të "{{ $externalAuth.URL }}" zëvendësohet URL-ja e specifikuar në parametrin "auth-url". Në këtë rast, saktësia e URL-së nuk kontrollohet. Si rezultat, sulmuesi mund të dërgojë si URL një vlerë si "http://example.com/#;\ncilësime" dhe të zëvendësojë cilësimet e tij në skedarin e konfigurimit.
Për të ekzekutuar kod të rastësishëm gjatë kontrollit të konfiguracionit me komandën "nginx -t", hulumtuesit shfrytëzuan faktin se përveç kontrollit të sintaksës, nginx ngarkon bibliotekat me modulet dhe hap skedarët e përmendur në konfigurim për të vlerësuar aksesueshmërinë e tyre. Ndër të tjera, gjatë përpunimit të direktivës ssl_engine, bëhet ngarkimi i bibliotekës së ndarë të specifikuar në direktivë për SSL-motorin.
Për të ngarkuar bibliotekën e tij në serverin Kubernetes, hulumtuesit shfrytëzuan (CVE-2025-1974) faktin se gjatë përpunimit të kërkesave të mëdha, nginx ruan trupin e kërkesës në një skedar përkohësisht, i cili menjëherë fshihet, por në sistemin e skedarëve "/proc" mbetet një deshifruese e hapur për këtë skedar. Kështu, është e mundur të dërgoni kërkesa për të ruajtur skedarin përkohësisht dhe për të iniciuar kontrollin e konfiguracionit, në të cilin në direktivën "ssl_engine" është specifikuar rruga në deshifruesin në sistemin e skedarëve "/proc".
Për të siguruar që një deshifrues skedari të mbetet i aksesueshëm për një kohë të gjatë, vlera e «Content-Length» në kërkesë mund të specifikohet si më e madhe se sa të dhënat e dërguara në realitet (serveri do të presë marrjen e të dhënave të mbetura). Një vështirësi shtesë është nevoja për të guesses PID e procesit dhe numrin e deshifruesit të skedarit të lidhur me bibliotekën e ndarë të ngarkuar, por për shkak se zakonisht në kontejner përdoren një numër minimal procesesh të hapura, vlerat e nevojshme mund të merren përmes përpjekjeve të shumta. Nëse arrin të ngarkohet biblioteka e ndarë e kujtuar, sulmuesi mund të ketë akses në parametrat e ruajtur brenda ambientit pod, të mjaftueshëm për të kontrolluar të gjithë klasterin.
PĂ«r tĂ« kontrolluar pĂ«rdorimin e ingress-nginx tĂ« dobĂ«t, mund tĂ« ekzekutoni komandĂ«n: kubectl get pods âall-namespaces âselector app.kubernetes.io/name=ingress-nginx
Burimi: opennet.ru
