Der er identificeret fire sårbarheder i det under udvikling Kubernetes ingress-controller, ingress-nginx, som muliggør, at ondsindet kode kan eksekveres på servere i cloud-systemer, der benytter Kubernetes-platformen, og få fuld privilegeret adgang til Kubernetes-klyngen. Problemerne er angivet med en kritisk faregrad (9,8 ud af 10). De forskere, der opdagede problemerne, har givet sårbarhederne kodeordet IngressNightmare og bemærket, at sårbarhederne påvirker ca. 43% af cloud-miljøerne. Sårbarhederne er blevet rettet i versionerne ingress-nginx 1.11.5 og 1.12.1.
Ingress-controlleren fungerer som en gateway og anvendes i Kubernetes til at organisere adgang fra det eksterne netværk til tjenester inde i klyngen. Controlleren ingress-nginx er den mest populære og anvender server NGINX til at videresende anmodninger til klyngen, rute eksterne forespørgsler og balancere belastningen. Kubernetes-projektet leverer grundlæggende ingress-controllere for AWS, GCE og nginx, sidstnævnte har ikke noget at gøre med kubernetes-ingress-controllere, som vedligeholdes af F5/NGINX (de sårbarheder, der diskuteres, berører ikke projekter udviklet af NGINX-udviklerne, og nævnelsen af nginx i navnet ingress-nginx er udelukkende relateret til brugen af nginx som proxy).
Sårbarhederne giver en ikke-godkendt angriber mulighed for at eksekvere sin kode i konteksten af ingress-nginx-controlleren, når der sendes en anmodning til Admission-webhandleren. Under netværksscanning er over 6500 sårbare Kubernetes-klynger blevet identificeret, som anvender offentligt tilgængelige sårbare controllere med Admission-handleren åben for eksterne forespørgsler.
I standardkonfigurationen kan den kode, der kører angreb, få adgang til konfigurationerne af Ingress-objektet, hvor blandt andet legitimationsoplysninger til adgang til Kubernetes-serverne opbevares, hvilket muliggør privilegeret adgang til hele klyngen. Som en midlertidig beskyttelse anbefales det at deaktivere "Validating Admission Controller"-funktionen i ingress-nginx.
Admission-controlleren køres i et separat pod-miljø og udfører en kontrol af indgående ingress-objekter før deres implementering. Som standard accepterer web-handleren Admission anmodninger uden autentificering fra det offentlige netværk. Under kontrolprocessen opretter Admission-controlleren en konfiguration til http-serveren nginx baseret på indholdet af det modtagne ingress-objekt og verificerer, at det er korrekt.
Identificerede sårbarheder muliggør, at ens egne indstillinger kan indsættes i nginx ved at sende et særligt formateret ingress-objekt direkte til Admission-controlleren. Forskere har opdaget, at nogle egenskaber fra kontrolanmodningerne, der er angivet i feltet «.request.object.annotations», direkte indsættes i nginx-konfigurationen. Den genererede konfiguration anvendes dog ikke, men testes blot ved at køre eksekveringsfilen «nginx» med indstillingen «-t».
Specifikt udføres indsættelse af eksterne data i konfigurationen for parametrene «mirror-target», «mirror-host» (CVE-2025-1098), «auth-tls-match-cn» (CVE-2025-1097) og «auth-url» (CVE-2025-24514). For eksempel i konfigurationslinjen «set $target {{ $externalAuth.URL }};» indsættes URL'en angivet i parameteren «auth-url» i stedet for «{{ $externalAuth.URL }}». URL'ens korrekthed kontrolleres ikke. Dermed kan en angriber overføre en URL-værdi som «http://example.com/#; indstillinger» og indsætte sine indstillinger i konfigurationsfilen.
For at udføre vilkårlig kode under kontrolen af konfigurationen ved hjælp af kommandoen «nginx -t» brugte forskerne det faktum, at udover at kontrollere syntaksen, indlæser nginx biblioteker med moduler og åbner filer, der nævnes i konfigurationen, for at evaluere deres tilgængelighed. Blandt andet under behandlingen af direktivet ssl_engine indlæses det angivne delte bibliotek ved hjælp af direktivet. SSL-motor.
For at indlæse sit eget bibliotek på Kubernetes-serveren udnyttede forskerne (CVE-2025-1974) det faktum, at ved behandling af store anmodninger gemmer nginx anmodningsindholdet i en midlertidig fil, der straks slettes, men der forbliver en åben filbeskriver i filsystemet «/proc» for denne fil. Derved kan man samtidig sende anmodninger for at gemme den midlertidige fil og igangsætte kontrol af konfigurationen, hvor stien til beskriveren i filsystemet «/proc» er angivet i direktivet «ssl_engine».
For the file descriptor to remain accessible for a long time, the value of 'Content-Length' in the request can be specified as significantly larger than the actual data sent (the server will wait for the remainder of the data). An additional complexity is the necessity to guess the PID of the process and the file descriptor number associated with the loaded shared library, but since the container usually runs a minimal number of processes, the needed values can be guessed through trial and error. In case of success and the loading of the substituted shared library, the attacker can gain access to the stored parameters within the pod environment, sufficient to manage the entire cluster.
To check the usage of the vulnerable ingress-nginx, you can execute the command: kubectl get pods —all-namespaces —selector app.kubernetes.io/name=ingress-nginx
Kilde: opennet.ru
