Në projektin në zhvillim të kontrollet të ingress Kubernetes, ingress-nginx, janë identifikuar katër vulnerabilitete që lejojnë ekzekutimin e kodit të përdoruesit në serverët e sistemeve cloud që përdorin platformën Kubernetes, duke fituar kështu akses të plotë dhe me privilegje në klasterin Kubernetes. Problemet janë vlerësuar me një nivel kritic rreziku (9.8 nga 10). Kërkuesit që identifikuan problemet i dhanë këtyre vulnerabiliteteve emrin kodor IngressNightmare dhe theksuan se ato prekin rreth 43% të mjediseve cloud. Vulnerabilitetet janë rregulluar në versionet ingress-nginx 1.11.5 dhe 1.12.1.
Ingress-controller vepron si një gateway dhe përdoret në Kubernetes për të organizuar qasjen nga rrjeti i jashtëm te shërbimet brenda klasterit. Controller-i ingress-nginx është më i përdoruri dhe përdor server NGINX për të dirigjuar kërkesat në klaster dhe për të balancuar ngarkesën. Projekti Kubernetes ofron kontrolle bazike ingress për AWS, GCE dhe nginx, i fundit prej të cilëve nuk është i lidhur me kontrollin kubernetes-ingress, për të cilin përkujdeset kompanisë F5/NGINX (vulnerabilitetet e shqyrtuara nuk prekin projektet që zhvillohen nga zhvilluesit NGINX, përmendja e nginx në emrin e ingress-nginx është vetëm për shkak të përdorimit të nginx si një proksi).
Vulnerabilitetet lejojnë një sulmues të paautorizuar të ekzekutojë kodin e tij në kontekstin e kontrollit ingress-nginx, në rastin e dërgimit të një kërkese në procesorin web Admission. Gjatë skanimit të rrjetit janë identifikuar më shumë se 6500 klastere Kubernetes që janë vulnerabël, duke përdorur kontrollet e ndjeshme me procesor të hapur për kërkesa të jashtme.
Në konfigurimin e zakonshëm, kodi i aktivizuar nga sulmuesi mund të fitojë qasje në cilësimet e objektit Ingress, ku përfshihen, ndër të tjera, edhe kredencialet për akses në serverët Kubernetes, duke lejuar kështu qasje me privilegje në tërë klasterin. Si një mënyrë për të rritur mbrojtjen, rekomandohet çaktivizimi i funksionit 'Validating Admission Controller' në ingress-nginx.
Kontrolli Admission ekzekutohet në një ambient të veçantë pod dhe kryen operacionin e verifikimit të objekteve ingress para shpërndarjes së tyre. Në konfigurimin e zakonshëm, procesori web Admission pranon kërkesa pa autentikim nga rrjeti publik. Gjatë verifikimit, kontrolli Admission krijon një konfigurim për serverin http të nginx bazuar në përmbajtjen e objektit ingress të marrë dhe kontrollon saktësinë e saj.
Identifikimi i dobësive lejon vendosjen e konfigurimeve të personalizuara në nginx përmes dërgimit të një objekti ingress të formatuar në mënyrë të veçantë direkt në kontrollorin e pranimit. Kërkuesit zbuluan se disa karakteristika të kërkesave verifikuese, të vendosura në fushën «.request.object.annotations», vendosen drejtpërdrejt në konfigurimin e nginx. Në këtë rast, konfigurimi i gjeneruar nuk aplikohet, por thjesht testohet duke ekzekutuar skedarin «nginx» me opsionin «-t».
Në veçanti, vendosja e të dhënave të jashtme në konfigurim bëhet 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ë linjën e konfigurimit «set $target {{ $externalAuth.URL }};», URL-ja e specifikuar në parametrin «auth-url» vendoset në vend të «{{ $externalAuth.URL }}». Në këtë rast, saktësia e URL-së nuk verifikohet. Prandaj, sulmuesi mund të dërgojë një vlerë të tillë si URL «http://example.com/#;\nkonfigurime» dhe të vendosë konfigurimet e tij në skedarin e konfigurimit.
Për të ekzekutuar kode të rastit në procesin e verifikimit të konfigurimit me komandën «nginx -t», kërkuesit shfrytëzuan faktin se përveç verifikimit të sintaksës, nginx ngarkon biblioteka me module dhe hap skedare që përmenden në konfigurim për të vlerësuar aksesueshmërinë e tyre. Ndër të tjera, gjatë përpunimit të drejtorive ssl_engine, ngarkohet biblioteka e ndarë e specifikuar në direktivë. SSL-motori.
Për të ngarkuar bibliotekën e tij në serverin Kubernetes, kërkuesit 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ë deshifrues i hapur për këtë skedar. Në këtë mënyrë, është e mundur të dërgoni kërkesa njëkohësisht për të ruajtur skedarin përkohësor dhe për të iniciuar verifikimin e konfigurimit, ku në direktivën «ssl_engine» është specifikuar rruga për deshifruesin në sistemin e skedarëve «/proc».
Për të siguruar që deshifruesi i skedarëve të mbetet i disponueshëm për një periudhë të gjatë, vlera "Content-Length" në kërkesë mund të specifikohet si dukshëm më e madhe se të dhënat faktike të dërguara (serveri do të presë për marrjen e të dhënave të mbetura). Një kompleksitet të shtuar përbën nevoja për të gjykuar PID-në e procesit dhe numrin e deshifruesit të skedarit të lidhur me bibliotekën e ngarkuar të ndarë, por ndërsa në kontejner zakonisht përdoret një numër minimal i proceseve të ekzekutuar, vlerat e nevojshme gjenden përmes provave të shumta. Nëse arrin të ngarkojë bibliotekën e ndarë të vendosur, sulmuesi mund të fitojë qasje në parametrat e ruajtur brenda mjedisit pod, të mjaftueshëm për të menaxhuar të gjithë klasterin.
Për të kontrolluar përdorimin e ingress-nginx që ka rrezikshmëri, mund të ekzekutoni komandën: kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
Burimi: opennet.ru
