Kwetsbaarheid in Kubernetes-Ingress-controller laat hackers clusters overnemen

Beveiligingsonderzoekers van Wiz hebben vijf ernstige kwetsbaarheden gevonden in de Ingress NGINX Controller voor Kubernetes. De belangrijkste kwetsbaarheid heeft een CVSS-score van 9.8 gekregen.

De verzameling kwetsbaarheden, gezamenlijk ‘IngressNightmare’ genoemd, maakt het mogelijk voor aanvallers om zonder authenticatie code uit te voeren op kwetsbare systemen. De kwetsbaarheden zijn vooral gevaarlijk omdat ze de admission controller component treffen, die zonder authenticatie via het netwerk bereikbaar is. Volgens Wiz is ongeveer 43 procent van alle cloudomgevingen kwetsbaar. Meer dan 6500 clusters die de component aan het internet blootstellen lopen direct gevaar.

Een aanvaller kan via het versturen van een gemanipuleerd ingress object willekeurige NGINX-configuraties injecteren. Dit kan leiden tot code-uitvoering binnen de Ingress NGINX Controller-pod. Door de verhoogde rechten van de admission controller kan een aanvaller vervolgens toegang krijgen tot alle secrets in het cluster, wat uiteindelijk tot een volledige overname kan leiden. Het Kubernetes Security Response Committee heeft patches uitgebracht in versies 1.12.1, 1.11.5 en 1.10.7 van de Ingress NGINX Controller.

Reacties (60)

[orvintax]

Als ik het goed begrijp is dit enkel een probleem wanneer je de admission controller publiekelijk bereikbaar maakt. Maar zover ik weet is dit standaard niet het geval.

[Mattie112]

"By default, admission controllers are accessible over the network without authentication, making them a highly appealing attack vector. "

https://www.wiz.io/blog/i...ubernetes-vulnerabilities

[orvintax]

Accessible over the network != accessible over the internet. De admission controller is nog benaderbaar van binnenuit de cluster over het netwerk. Maar standaard wordt er geen ingress gebruikt voor de admission controller.

[Power2All]

Ligt eraan hoe je netwerk config is.
Als het van buitenaf benaderbaar is op wat voor manier dan ook, is het toegankelijk.
Hetzelfde geldt voor alles, maar je kan het enigzins voorkomen sowieso door VLAN config toe te passen, of voor de belangrijke omgeving, airgapped.

[faim]

Dus jouw netwerken hangen zonder tussenkomst van een firewall aan het internet?

[sebastienbo]

Als ik malware deploy naar uw werknemers (phishing), dan kan mijn malware uw cluster benaderen, daar een call home app installeren, en voila ik kan doen wat ik wil op je cluster (en intern netwerk)

Dat is waarom je goede segregation van netwerken nodig hebt. En dat outbound internet access gelimiteerd moet worden .

[EraYaN]

De kans dat workstations op hetzelfde netwerk draaien als het pod netwerk en dat daar geen firewalls bij horen is dan wel weer heel klein. Waarom zou je dan uberhaupt een ingress controller nodig hebben, dan kan iedereen direct bij de pod services als ze dat willen.

[P1nGu1n]

Dat is het grootste risico, maar ook als de admission controller niet publiekelijk toegankelijk is zou een kwaadaardige werknemer hiermee het cluster kunnen overnemen. Of een aanvaller die al binnen is zou hiermee k8s secrets kunnen exfiltreren.

[orvintax]

Dit lijkt mij dan inderdaad het realistische scenario. Maar dan vind ik de kwetsbaar een stuk minder spannend dan het doet voorkomen (CVSS 9.8). Buiten dat er blijkbaar wel genoeg clusters de admission controller wel publiekelijk bereikbaar hebben.

[Reactie gewijzigd door orvintax op 25 maart 2025 14:06]

[the_stickie]

In geval van een targeted attack is helemaal geen kwaadaardige werknemer nodig. Toegang tot het netwerk betekent zoveel als toegang tot één device op dat netwerk - niet eens administrative access nodig in veel gevallen...
De 9.5 komt dus van het feit dat één andere, kleine kwetsbaarheid, of één gefopte gebruiker (met toegang tot de juiste vlan) ALLES wat op je kubernetes cluster draait kan compromitteren...

[orvintax]

Dat is waar, maar dan nog. Voor mij persoonlijk was het belangrijk om te weten of dit van buitenaf standaard kan.

[supersnathan94]

Volgens Wiz is ongeveer 43 procent van alle cloudomgevingen kwetsbaar.

in 43% van de gevallen is dat dus wel degelijk een ja. Dat vind ik erg veel. Zeker aangezien dit ook fortune500 bedrijven zijn.

[orvintax]

Dat is 43% van de door hun geanalyzeerde 6500 Kubernetes clusters. Er zijn een hoop meer Kubernetes clusters dan dat in de wereld, dus ik betwijfel ten strengste of 43% in de buurt komt wereldwijd.

[supersnathan94]

Dat is niet wat zij zeggen.

with our research uncovering over 6,500 clusters,

Dat zijn dus al 6500 kwetsbare clusters. Niet dat het maar 6500 geanalyseerde clusters zijn.

Punt is meer dat als een fortune500 partij dit al op die manier aan het internet heeft geknupt, dat de kans vrij groot is dat een of andere startup uit schubbekutteveen dat hoogstwaarschijnlijk niet heel veel beter heeft geregeld.

[orvintax]

Dat heb ik inderdaad verkeerd verwoord. Ik wilde enkel stellen dat het om 6500 clusters/ 43% van de door hun geanalyzeerde clusters gaat. En dat je dus niet kan stellen dat wereldwijd 43% kwetsbaar is. Daarnaast is dit expliciet niet de standaard instelling voor de ingress controller. Dus ik denk persoonlijk dat dit getal een stuk lager ligt.

[supersnathan94]

En dat je dus niet kan stellen dat wereldwijd 43% kwetsbaar is.

again. Niet mijn interpretatie, maar wat zij daadwerkelijk zelf zeggen. Kan zeker dat het lager ligt, maar ik geloof ook wel dat er een en ander gewoon niet goed is ingeregeld.

Daarnaast is dit expliciet niet de standaard instelling voor de ingress controller.

Het gaat ook niet om de ingress controller zelf en het is ook niet alleen als ie aan het internet hangt. Ik denk wel degelijk dat er meer clusters kwetsbaar zijn dan alleen die berg die het hoe dan ook verkeerd doet.

[roelboel]

Correct.

[glaaj]

Ik weet niet hoe jullie aan versie 1.10.7 komen maar dat staat haaks op het artikel wat jullie linken, daarin staat

"Today, we have released ingress-nginx v1.12.1 and v1.11.5, which have fixes for all five of these vulnerabilities."

Deze bron haalt dezelfde versies aan overigens: https://www.wiz.io/blog/i...ubernetes-vulnerabilities

[Reactie gewijzigd door glaaj op 25 maart 2025 12:44]

[Pinkelmans]

Deze wordt ook o.a. hier genoemd: https://thehackernews.com...ess-nginx-controller.html . Echter kan ik de 1.10.7 release nog niet vinden en is er geen 1.10 branch meer op Github te vinden ( https://github.com/kubernetes/ingress-nginx/ ); misschien dat ze de fix nog gaan backporten?

[glaaj]

1.10.x heeft geen actieve support meer, dus wellicht dat de release wat langer op zich laat wachten. Ik zou er persoonlijk niet op wachten en gelijk de gepatchte versies van 1.11.x en 1.12.x doorzetten. Zeker als je controller aan het internet hangt.

[CH4OS]

Ook op Github zie ik de genoemde 1.10 versie niet terug. Het gaat om de releases van (op het oment van schrijven) 11 uur geleden, van 25 maart 2025 (iets na middernacht NL tijd dus).
https://github.com/kubernetes/ingress-nginx/releases

[Reactie gewijzigd door CH4OS op 25 maart 2025 12:59]

[nicket84]

Heftig, daar gaat m'n middag

[Keypunchie]

Mijn allereerste reactie was dat de koffie mijn neus uit spoot. Dit is een heel serieus lek, met grote gevolgen! PATCH! PATCH! PATCH!

Toen ik doorlas dat het om de admissions controller ging (die niet standaard aan het internet, maar wel het lokale netwerk hangt), ging mijn hartslag iets omlaag.

Nu lekker druk bezig om de versnelde uitrol van patches te coordineren. Lokale netwerk is al erg genoeg, namelijk, dus dat gaan we zeker niet tot het volgende geplande onderhoudswindow uitstellen. Wel netjes de (infra) OTAP door.

[nicket84]

Hier verliep het net zo. Naarmate ik beter was ingelezen en de nuclei scans had uitgevoerd is de schrik afgenomen.

[gwijsman]

En nieuwe koffie gezet hoop ik!

[Jay-v]

Indien je het snel wil controleren:

kubectl get pods -n ingress-nginx ingress-nginx-controller-667f9c7ff9-6547n -o jsonpath='{.metadata.labels.app\.kubernetes\.io/version}'
1.12.1

:-)

[supersnathan94]

Ik denk dat het antwoord altijd een error gaat zijn. Jij bent namelijk ws de enige die een deployment heeft met `-667f9c7ff9-6547nz` als suffix

[nicket84]

Je was me voor

[stefklep]

Kan nog makkelijker

kubectl exec -it -n NAMESPACE ingress-nginx-controller-(deployment-id) -- /nginx-ingress-controller --version

Ik gebruik het samen met gitlab.. kwestie van template Cluster-Management(template) aanpassen van applications/ingress/helmfile.yaml

version: 4.9.0 -> 4.12.1 (Zeer oude versie wordt daar al gebruikt standart)

[ApexAlpha]

Oei, dit is een flinke zeg!

[supersnathan94]

Het Kubernetes Security Response Committee heeft patches uitgebracht in versies 1.12.1, 1.11.5 en 1.10.7 van de Ingress NGINX Controller.

Today, we have released ingress-nginx v1.12.1 and v1.11.5, which have fixes for all five of these vulnerabilities.

Hoe komt tweakers aan 1.10.7? De laatste .10 versie is .6 uit december vorig jaar (zie: https://github.com/kubernetes/ingress-nginx/releases)

[supersnathan94]

By default, ingress-nginx has access to all Secrets cluster-wide,

https://kubernetes.io/blo...ress-nginx-cve-2025-1974/

Misschien moeten we daar dan eerst eens mee stoppen? Waarom zou de nginx admission-controller überhaupt toegang moeten hebben tot secrets, laat staan alle secrets?

[hello123456]

Voor de certificaten die aangemaakt worden binnen verschillende namespaces die gebruikt moeten worden door NGINX voor de SSL verbindingen.

[supersnathan94]

Fair! dan heb je dat inderdaad wel nodig, maar als je er nog een LB voor hebt oid dan is het vaak makkelijker om de Loadbalancer SSL termination te laten doen. Dan is het verkeer daarna allemaal HTTP. Dus voor cloud omgevingen kan ik me zo voorstellen dat dit geen sane default is, laat staan cluster wide en niet scoped naar specifieke namespace.

[eborn]

Dat zeg je wel, maar ook partijen als CloudFlare zetten steeds meer in op end-to-end encryptie. Je ingress controller zou in dat geval dan ook netjes certificaten moeten hebben.

[supersnathan94]

Dat snap ik, maar de ingress controller zelf is iets anders dan de Admission controller right?

Even vanuit de documentatie:

Admission controllers apply to requests that create, delete, or modify objects. Admission controllers can also block custom verbs, such as a request to connect to a pod via an API server proxy. Admission controllers do not (and cannot) block requests to read (get, watch or list) objects, because reads bypass the admission control layer.

Dus de Admission Controller doet in dat opzicht niks met "lezen" van certificaten. Ik vind het nog maar een lastig verhaal. interessante materie wel om verder in te duiken, maar vind nog niet heel helder uitgelegd door WiZ wat er nu precies aan de hand is en wat de impact nu is. Kennelijk ben je er op openshift namelijk niet vatbaar voor (want andere admission controller) bijvoorbeeld.

[Alxndr]

Kubernetes? Ingress controller?

Dit wordt verondersteld parate kennis te zijn op Tweakers? Eén enkel zinnetje toevoegen om ook maar een beetje een idee te geven waar dit over gaat is te veel gevraagd?

Sorry, maar als jullie te druk zijn gooi ik er zelf wel ff de ChatGPT uitleg tegenaan:

Admin-edit:

- knip-
Geheel of grotendeels middels Ai vervaardigde reacties zijn volgens onze huisregels niet toegestaan.

[Reactie gewijzigd door Bor op 25 maart 2025 21:32]

[Woohooo]

Je zit dan waarschijnlijk niet in de materie, maar Kubernetes bestaat al ongeveer 10jaar als wereldwijd veel gebruikt container platform

[sircampalot]

Ik vroeg het me ook af.
Dank voor de nuttige aanvulling!

[oef!]

Ingress en egress (binnenkomend en uitgaand) zijn relatief bekende termen in IT/cloud land. Zeker omdat je voor de laatste nog wel eens betaalt.

[supersnathan94]

Dit wordt verondersteld parate kennis te zijn op Tweakers?

Mwah, Kubernetes als ter wel denk ik. Dat is toch wel een platform waar het grootste deel van de wereld op een willekeurig moment in tijd een keer op gedraaid heeft.

Ik snap dat je de interne werking en termen niet kent of vol in die materie bezig bent wel. Ingress controller is al behoorlijk diep de materie in.

[Hobbit13]

Als je zelf niets met serverbeheer doet, of daar een GUI voor gebruikt (Synology, TrueNAS) dan kom je als gebruiker Kubernetes toch nooit tegen? Het is dat mijn TrueNAS server vrij buggy was, waardoor ik een boel met de command line heb lopen klooien, maar ik was Kubernetes daarbij liever ook niet tegen gekomen....

Ik ben het met Alxndr eens dat dit niet erg algemene kennis is.

[supersnathan94]

Algemene kennis niet, maar onder het tech publiek hier veronderstel ik de term "Kubernetes" wel als iets wat je een keer ergens hebt gehoord. Net als dat je ws van AWS, Google Cloud of Azure hebt gehoord. Alledrie bieden ze zeer uitgebreide Kubernetes services aan.

[Neggs]

Voor mij werkte dit op onze clusters:
- Maak backup van deploy.yaml > deploy.bup
- Kies nieuwe versie en download:
> wget https://raw.githubusercon...rovider/cloud/deploy.yaml

- Vergelijk en pas nieuwe deploy.yaml aan

- Verwijder jobs:
> kubectl delete job ingress-nginx-admission-create -n ingress-nginx
> kubectl delete job ingress-nginx-admission-patch -n ingress-nginx

> kubectl apply -f deploy.yaml

[Niemand_Anders]

Het is daarnaast natuurlijk ook een zeer mooi moment voor een herevaluatie van de K8S cluster components. Alternatieve ingress controllers zijn bijvoorbeeld caddy, traefik, contour en ambassador.

[syl765]

Een caddy, traefik, contour en ambassador kunnen net zo goed een zero day bevatten die op een moment misbruikt kan worden. Als je die route gaat nemen dan blijf je bezig.

[Niemand_Anders]

Uiteraard kunnen die componenten ook zero-day exploits bevatten, alleen ik heb zeer veel K8S omgevingen gezien waar mee vele jaren geleden de pro- en cons hebben afgewogen bij het initieel opzetten van de cluster en daarna nooit meer een her-evaluatie doen van de componenten. Software veranderd continue, maar ook de eisen welke worden gesteld aan de software.

Momenten zoals een zero-day exploit zijn een goed moment om te kijken of alles nog steeds voldoet en of er geen andere componenten inmiddels bestaan welke nog beter aansluiten het gebruik van de cluster.

[roelboel]

Ik vind het allemaal erg angstaanjagend overkomen maar volgens mij is het niet meer dan een privilege escalation probleem, voor iemand die al netwerk-toegang heeft tot k8s. Niet waar?

[Keypunchie]

Geen privilege escalation, want je hoeft alleen maar binnen het netwerk te zijn, dat kan ook zonder rechten.

In veel scenario's kan het zijn dat je een pod exploit, maar het kan ook zo simpel zijn als toegang tot een kantoornetwerk hebben (niet iedereen heeft netjes beheernetwerken/bastion-servers).

Moet je je hoofd verliezen? Nee. Moet je dit met urgentie gaan patchen? Ja!

[Reactie gewijzigd door Keypunchie op 25 maart 2025 15:56]

[Niemand_Anders]

Die toegang is gemakkelijker dan je denkt. Deployments worden vaak niet zomaar aangepast omdat bij elke re-deployment men nog steeds zeker moet weten dat alles nog perfect samen werkt. Een nadeel van de micro service architectuur. Een exploit waarbij je een remote shell opzet (netcat) in een van deze microservices is voldoende om toegang te krijgen tot dat interne netwerk.

Dat is een van de redenen waarom deze zo'n hoge score heeft gekregen.

SQL servers hangen niet direct aan het internet, maak via SQL injection kun je toch toegang krijgen tot de data in de database.

Een beetje obfuscation kan dus geen kwaad. Vermeld daarom geen versie nummers van je software. Gebruikt een egress filter om webserver/webframework versie uit de response te filteren.

Het is al veel lastiger een wordpress website te hacken als je niet weet welke versie men draait. Nu zijn er tal van manier om daar alsnog achter te komen, maar het werpt een drempel op voor de meeste script kiddies, hoewel deze ook steeds beter worden in het gebruik van Kali en de hacking security tools, zeker in combinatie met ChatGPT of zelf een unfiltered modem op een self-hosted ollama instance waarmee het nog meer copy/paste werk is geworden...

[supersnathan94]

Ik hoor hier best wel wat dingen waar ik wel een beetje van schrik.

Hier zijn toch al lang en breed standaard practices voor? Sws versienummers van software niet vermelden is toch ook niet relevant? tegenwoordig wordt er echt niet meer handmatig naar responses gekeken en gaat vrijwel alles volledig automatisch. Een variant van Nginx draaien als webserver is dan al voldoende. Alles exploits die er zijn worden er toch wel tegenaan gegooid.

Maar een remote shell in de microservice? met toegang naar buiten? Ik mag toch aannemen dat je je poorten goed instelt en niet als root draait enzo. Geen privileges of extra capabilities ed.