In het ontwikkelde Kubernetes ingress-controller project ingress-nginx zijn vier kwetsbaarheden ontdekt die in staat zijn om de uitvoering van eigen code op servers van cloudsystemen die het Kubernetes-platform gebruiken te bereiken, en om volledige geprivilegieerde toegang tot het Kubernetes-cluster te verkrijgen. De problemen hebben een kritieke risicoscore gekregen (9.8 uit 10). De onderzoekers die de problemen hebben ontdekt, hebben de kwetsbaarheden de codenaam IngressNightmare gegeven en opgemerkt dat ze ongeveer 43% van cloudomgevingen raken. De kwetsbaarheden zijn verholpen in de versies ingress-nginx 1.11.5 en 1.12.1.
De ingress-controller fungeert als een poort en wordt in Kubernetes gebruikt om toegang van extern naar de diensten binnen het cluster te organiseren. De ingress-nginx-controller is de meest populaire en maakt gebruik van server NGINX voor het doorsturen van verzoeken naar het cluster, het routeren van externe aanvragen en het balanceren van de belasting. Het Kubernetes-project biedt basis ingress-controllers voor AWS, GCE en nginx, waarvan de laatste niet gerelateerd is aan de kubernetes-ingress-controller, die wordt onderhouden door F5/NGINX (de besproken kwetsbaarheden betreffen geen projecten ontwikkeld door NGINX-ontwikkelaars, de vermelding van nginx in de naam ingress-nginx is alleen gerelateerd aan het gebruik van nginx als proxy).
De kwetsbaarheden stellen een niet-geauthenticeerde aanvaller in staat om eigen code uit te voeren in de context van de ingress-nginx-controller, met de mogelijkheid om een verzoek naar de webverwerker Admission te sturen. Tijdens netwerkscans zijn meer dan 6500 kwetsbare Kubernetes-clusters ontdekt die gebruikmaken van openbare kwetsbare controllers met een open Admission-verwerker voor externe verzoeken.
In de standaardconfiguratie kan de door de aanvaller uitgevoerde code toegang krijgen tot de instellingen van het Ingress-object, waarin onder andere ook de referenties voor toegang tot de Kubernetes-servers zijn opgeslagen, wat geprivilegieerde toegang tot het hele cluster mogelijk maakt. Als een tijdelijke oplossing voor beveiliging wordt aanbevolen om de functie 'Validating Admission Controller' in ingress-nginx uit te schakelen.
De Admission-controller draait in een aparte pod-omgeving en voert de validatie van inkomende ingress-objecten uit voordat ze worden ingezet. Standaard accepteert de Admission-webhandler verzoeken zonder authenticatie vanuit het publieke netwerk. Tijdens de validatie maakt de Admission-controller een configuratie voor de http-server nginx op basis van de inhoud van het ontvangen ingress-object en controleert het de correctheid ervan.
De ontdekte kwetsbaarheden stellen aanvallers in staat om hun eigen instellingen in nginx te injecteren door een speciaal opgemaakt ingress-object rechtstreeks naar de Admission-controller te sturen. Onderzoekers ontdekten dat sommige eigenschappen van de verificatieverzoeken, die zijn ingesteld in het veld "request.object.annotations", rechtstreeks worden geĆÆnjecteerd in de nginx-configuratie. Daarbij wordt de gegenereerde configuratie niet toegepast, maar alleen getest door het uitvoeren van het uitvoerbare bestand "nginx" met de optie "-t".
In het bijzonder wordt de injectie van externe gegevens in de configuratie uitgevoerd voor de parameters "mirror-target", "mirror-host" (CVE-2025-1098), "auth-tls-match-cn" (CVE-2025-1097) en "auth-url" (CVE-2025-24514). Bijvoorbeeld, in de configuratieregel "set $target {{ $externalAuth.URL }};" wordt in plaats van "{{ $externalAuth.URL }}" de URL ingevoegd die is opgegeven in de parameter "auth-url". Daarbij wordt de correctheid van de URL niet gecontroleerd. Derhalve kan een aanvaller een URL zoals "http://example.com/#; instellingen" doorgeven en zijn eigen instellingen in het configuratiebestand injecteren.
Voor het uitvoeren van willekeurige code tijdens de configuratievalidatie met het commando "nginx -t" maakten de onderzoekers gebruik van het feit dat, naast het controleren van de syntaxis, nginx bibliotheken van modules laadt en bestanden opent die in de configuratie worden genoemd om hun beschikbaarheid te evalueren. Onder andere, bij het verwerken van de ssl_engine-directive, wordt de gespecificeerde gedeelde bibliotheek geladen voor SSL-de engine.
Om hun bibliotheek op de Kubernetes-server te laden, maakten de onderzoekers gebruik van (CVE-2025-1974) het feit dat nginx bij het verwerken van grote verzoeken de requestbody in een tijdelijk bestand opslaat, dat onmiddellijk wordt verwijderd, maar in het bestandssysteem "proc" blijft er een open bestandsdescriptor voor dit bestand bestaan. Op deze manier kan men gelijktijdig verzoeken versturen om het tijdelijke bestand op te slaan en de configuratievalidatie te initiƫren, waarbij in de "ssl_engine"-directive het pad naar de descriptor in het bestandssysteem "proc" is aangegeven.
Om ervoor te zorgen dat de bestandsdescriptor gedurende langere tijd toegankelijk blijft, kan de waarde van "Content-Length" in de aanvraag voorafgaand groter zijn dan de daadwerkelijk verzonden gegevens (de server wacht op het ontvangen van de resterende gegevens). Een bijkomende complicatie is de noodzaak om de PID van het proces en het nummer van de bestanden descriptor die met de geladen gedeelde bibliotheek is verbonden, te raden. Aangezien er meestal een minimum aantal actieve processen in de container is, kunnen de benodigde waarden door middel van een paar pogingen worden geraden. In het geval van succes en het laden van de ingevoegde gedeelde bibliotheek, kan de aanvaller toegang krijgen tot de binnen het pod-omgeving opgeslagen parameters die voldoende zijn om de hele cluster te beheren.
Om te controleren op het gebruik van kwetsbare ingress-nginx, kan de volgende opdracht worden uitgevoerd: kubectl get pods āall-namespaces āselector app.kubernetes.io/name=ingress-nginx
Bron: opennet.ru
