Ingress-nginxini haavatavused, mis võimaldavad koodi täitmist ja Kubernetes klastrite üle kontrolli haaramist.

Kubernetes ingress-kontrolleri ingress-nginx arendatavast projektist leiti neli haavatavust, mis võimaldavad käivitada oma koodi pilvesüsteemide serverites, mis kasutavad Kubernetes platvormi, saavutades täis privilegeeritud juurdepääsu Kubernetes klastri. Probleemidele on määratud kriitiline oht (9.8 skaalal 10). Probleeme avastanud teadlased andsid haavatavustele koodnimeks IngressNightmare ja märkisid, et haavatavused mõjutavad umbes 43% pilveserveritest. Haavatavused on kõrvaldatud ingress-nginx versionites 1.11.5 ja 1.12.1.

Ingress-kontroller toimib väravana ja kasutatakse Kuberneteses, et korraldada juurdepääsu välisest võrgust klastris olevatele teenustele. Kontroller ingress-nginx on kõige populaarsem ja rakendab server NGINX väljasaatmise suunamiseks klastrisse, väliste päringute suunamiseks ja koormuse tasakaalustamiseks. Kubernetes pakub põhilisi ingress-kontrollereid AWS-i, GCE ja NGINX jaoks; viimane ei ole seotud kubernetes-ingress kontrolliga, mille hooldust teostab ettevõte F5/NIGNX (arutluse all olevad haavatavused ei puuduta projekte, mida arendavad NGINX-i arendajad; NGINX-i mainimine ingress-nginx nime koosneb vaid NGINX-i kasutamisest maatriksina).

Haavatavused võimaldavad autentimata ründajal saavutada enda koodi täitmist ingress-nginx kontrolleri kontekstis, saates päringut Admission web-teenusele. Võrgu skaneerimise käigus tuvastati üle 6500 haavatava Kubernetes klastri, mis kasutavad avalikult haavatavaid kontrollerid koos Admission teenusega, mis on avatud välistest päringutest.

Vaikimisi seadistuses võib ründaja käivitatud kood pääseda juurde Ingress objekti seadetele, kus muuhulgas on ka Kubernetes serverite kõnedie, võimaldades privileegide saamist kogu klastrile. Kaitseks soovitatakse keelata ingress-nginx funktsioon „Validating Admission Controller”.

Admission Controller käivitatakse eraldi pod-i keskkonnas ja kontrollib sisenevate ingress-objektide korrektset töötlemist enne nende juurutamist. Vaikimisi võtab Admission web-protsessor vastu autentimata päringud avalikest võrkudest. Kontroller loob auditi käigus nginx http-serveri seadistuse vastavalt saadud ingress-objekti sisule ja kontrollib selle õigsust.

Tuvastatud haavatavused võimaldavad sisestada oma seadeid nginx'i, saates spetsiaalselt vormistatud ingress-objekti otse Admission kontrollimiseks. Uurijad on avastanud, et mõned kontrollpäringute omadused, mis on määratud väljale ".request.object.annotations", sisestatakse otse nginx'i konfiguratsiooni. Samal ajal ei rakendata genereeritud konfiguratsiooni, vaid seda testitakse, käivitades täitmisfaili "nginx" valikuga "-t".

Eelkõige toimub väliste andmete sisestamine konfiguratsiooni parameetrite "mirror-target", "mirror-host" (CVE-2025-1098), "auth-tls-match-cn" (CVE-2025-1097) ja "auth-url" (CVE-2025-24514) osas. Näiteks konfiguratsioonireas "set $target {{ $externalAuth.URL }};" asendatakse "{{ $externalAuth.URL }}" URL-iga, mis on määratud parameetris "auth-url". URL-i õigsust ei kontrollita. Seetõttu saab ründaja edastada URL-i väärtuse tüüpi "http://example.com/#;\nseaded" ja sisestada oma seaded konfiguratsioonifaili.

Koodide käitamiseks konfigureerimise kontrollimise käigus käsuga «nginx -t» kasutasid uurijad seda, et peale süntaksi kontrollimist laadib nginx teegi mooduleid ja avab konfiguratsioonis mainitud faile, et hinnata nende kättesaadavust. Lisaks toimub ssl_engine direktiivi töötlemisel määratud jagatud teegi laadimine SSL-mootorist.

Oma teegi laadimiseks Kubernetes serverisse kasutasid uurijad (CVE-2025-1974) seda, et suurte päringute töötlemisel salvestab nginx päringu sisu ajutisse failisse, mis eemaldatakse kohe, kuid failisüsteemis «/proc» jääb selle faili jaoks avatud failide descriptor. Seega on võimalik samal ajal saata päringuid ajutise faili salvestamiseks ja käivitada konfiguratsiooni kontroll, kus ssl_engine direktiivi all on määratud descriptori tee failisüsteemis «/proc».

Et file descriptor jääb kaua kättesaadavaks, kui päringus on 'Content-Length' väärtus määratud eesmärgiga, mis on oluliselt suurem kui tegelikult edastatud andmed (server ootab ülejäänud andmete vastuvõtmist). Täiendavaks keerukuseks on vajadus aimata protsessi PID-d ja file deskriptorite numbrit, mis on seotud laaditud jagatud teegiga, kuid kuna konteineris kasutatakse tavaliselt minimaalset arvu töötavaid protsesse, siis sobivad väärtused ennustatakse mitme katse kaudu. Õnnestumise korral, kui laaditakse õigesti jagatud teek, võib ründaja saada juurdepääsu pod-keskkonnas hoitavatele parameetritele, mis on piisavad kogu klastri haldamiseks.

Haavatava ingress-nginx kasutamise kontrollimiseks saab käivitada käsu: kubectl get pods —all-namespaces —selector app.kubernetes.io/name=ingress-nginx

Allikas: opennet.ru