În proiectul în dezvoltare Kubernetes ingress-controller ingress-nginx au fost identificate patru vulnerabilități care permit executarea de cod pe serverele sistemelor cloud care utilizează platforma Kubernetes și obținerea unui acces complet privilegiat la clusterul Kubernetes. Aceste probleme au fost clasificate cu un nivel critic de pericol (9.8 din 10). Cercetătorii care au descoperit problemele au atribuit vulnerabilităților numele de cod IngressNightmare și au subliniat că acestea afectează aproximativ 43% din medii cloud. Vulnerabilitățile au fost remediate în versiunile ingress-nginx 1.11.5 și 1.12.1.
Ingress-controller-ul funcționează ca un gateway și este folosit în Kubernetes pentru a organiza accesul din rețeaua externă la serviciile din interiorul cluster-ului. Controller-ul ingress-nginx este cel mai popular și utilizează serverul NGINX pentru redirecționarea apelurilor către cluster, rutarea solicitărilor externe și realizarea echilibrării încărcăturii. Proiectul Kubernetes oferă controlere ingress de bază pentru AWS, GCE și nginx, acesta din urmă nefiind legat de controller-ul kubernetes-ingress, întreținerea căruia este gestionată de compania F5/NGINX (vulnerabilitățile menționate nu afectează proiectele dezvoltate de dezvoltatorii NGINX, menționarea nginx în numele ingress-nginx fiind legată doar de utilizarea nginx ca proxy).
Vulnerabilitățile permit unui atacator neautentificat să execute codul său în contextul controller-ului ingress-nginx, având posibilitatea de a trimite o solicitare către procesorul web Admission. În urma scanării rețelei, au fost identificate peste 6500 de clustere Kubernetes vulnerabile care folosesc controlere vulnerabile publice cu procesorul Admission deschis pentru solicitări externe.
În configurația implicită, codul executat de atacator poate obține acces la setările obiectului Ingress, în care, printre altele, sunt stocate și acreditivele pentru a interacționa cu serverele Kubernetes, ceea ce permite obținerea unui acces privilegiat la întregul cluster. Ca măsură de securitate, se recomandă dezactivarea funcției „Validating Admission Controller” în ingress-nginx.
Controller-ul Admission rulează într-un mediu pod separat și efectuează operațiunea de verificare a obiectelor ingress care intră înainte de desfășurarea lor. În mod implicit, procesorul web Admission acceptă solicitări fără autentificare din rețeaua publică. La efectuarea verificării, controller-ul Admission creează o configurație pentru serverul http nginx pe baza conținutului obiectului ingress primit și îi verifică corectitudinea.
Vulnerabilitățile identificate permit inserarea propriilor configurații în nginx prin trimiterea unui obiect ingress formatat special direct în controlerul Admission. Cercetătorii au descoperit că unele proprietăți ale cererilor de verificare, specificate în câmpul „.request.object.annotations”, sunt direct incluse în configurația nginx. Configurația generată nu este aplicată, ci doar testată prin rularea executabilului „nginx” cu opțiunea „-t”.
În special, inserarea datelor externe în configurație se face pentru parametrii „mirror-target”, „mirror-host” (CVE-2025-1098), „auth-tls-match-cn” (CVE-2025-1097) și „auth-url” (CVE-2025-24514). De exemplu, în linia de configurație „set $target {{ $externalAuth.URL }};”, în loc de „{{ $externalAuth.URL }}” se va insera URL-ul specificat în parametrul „auth-url”. În acest caz, corectitudinea URL-ului nu este verificată. Astfel, un atacator ar putea trimite o valoare de tipul „http://example.com/#;\nconfigurații” ca URL și își poate insera propriile configurații în fișierul de configurație.
Pentru a executa cod arbitrar în timpul verificării configurației cu comanda „nginx -t”, cercetătorii au profitat de faptul că, pe lângă verificarea sintaxei, nginx încarcă biblioteci cu module și deschide fișierele menționate în configurație pentru a evalua disponibilitatea acestora. Printre altele, la procesarea directivei ssl_engine se efectuează încărcarea bibliotecii partajate specificate în directivă pentru SSL-motor.
Pentru a încărca propria bibliotecă pe serverul Kubernetes, cercetătorii au profitat de (CVE-2025-1974) faptul că, în timpul procesării cererilor mari, nginx salvează corpul cererii într-un fișier temporar, care este imediat șters, dar în sistemul de fișiere „/proc” pentru acest fișier rămâne un descriptor de fișier deschis. Astfel, se pot trimite simultan cereri pentru a salva fișierul temporar și pentru a iniția verificarea configurației, în care în directiva „ssl_engine” este specificat un drum către descriptor în sistemul de fișiere „/proc”.
Pentru ca descriptorul de fișiere să rămână accesibil o perioadă lungă, valoarea „Content-Length” din solicitare poate fi setată la un număr evident mai mare decât datele transmise efectiv (serverul va aștepta primirea datelor rămase). O complexitate suplimentară este necesitatea de a ghici PID-ul procesului și numărul descriptorului de fișiere asociat bibliotecii partajate încărcate, însă, deoarece în container este de obicei folosit un număr minim de procese active, valorile necesare sunt ghicite prin încercări repetate. În caz de succes și încărcare a bibliotecii partajate furnizate, atacatorul poate obține acces la parametrii stocați în interiorul mediului pod, suficienți pentru a controla întregul cluster.
Pentru a verifica utilizarea ingress-nginx vulnerabil, puteți executa comanda: kubectl get pods —all-namespaces —selector app.kubernetes.io/name=ingress-nginx
Sursa: opennet.ro
