Critical Unauthenticated Remote Code Execution Vulnerabilities in Ingress NGINX | Hacker News Reader

Critical Unauthenticated Remote Code Execution Vulnerabilities in Ingress NGINX

wiz.io

79 pointspuppion11 comments

> Based on our analysis, about 43% of cloud environments are vulnerable to these vulnerabilities, with our research uncovering over 6,500 clusters, including Fortune 500 companies, that publicly expose vulnerable Kubernetes ingress controllers’ admission controllers to the public internet—putting them at immediate critical risk.

I don't understand that. Under what circumstances are those admission controllers exposed to the public internet? The k8s API of my EKS is definitely exposed to the public internet, but my understanding is that it will say "no" to whatever unauthenticated request it receives, isn't it?

Did I read this right that it's a problem with k8s, and not nginx? Seems not very nice to have nginx in the title, when it's not the problem.

It's a problem with a k8s component called "Ingress Nginx" (the ingress controller that uses Nginx).

Nginx isn't the problem, but I don't think you can really get away from including it in the title given the name of the component

it's not core k8s either, it's "ingress-nginx", a community maintained implementation of k8s ingresses using nginx as the underlying proxy, (which is different from the nginx / f5 version called nginx-ingress....).

> However, because the Admission Controller lacks authentication, an attacker with minimal network access could craft and send arbitrary AdmissionReview requests from any pod within the cluster.

Do I understand this correctly?

- To exploit this vulnerability, you need to send a request directly to a kubernetes resource, the admission controller, something that is generally not possible unless you have a misconfiguration on the level of "MySQL server is reachable from any external ip".

- Exploiting this vulnerability by communicating with the nginx server itself is not possible.

- Normally, kubernetes resources should never be accessible from the internet. This requires an obviously dangerous misconfiguration or extremely lax security standards. Ideally, no one should be able to tell you are using kubernetes from outside.

I think you've got it. But I'm on the fence about the rest. I mean, you're spot on that it would require a monumentally bad collection of misconfigurations to mount the attack and 9.8 seems to be somewhat histrionic. But considering how often I run into a monumentally bad collection of misconfigurations when doing incident post-mortems, I'm sorely tempted to be ok with assigning ratings with the assumption that the target has done all the compensating controls wrong. YMMV.

I think they might be targeting cloud providers that expose such endpoints to their clients.

I built clusters using ingress-nginx at my old job and I can guarantee you that not one single endpoint of k8s was accessible outside of NAT.

This makes a SSRF bug go from "oops, that's bad" to "oops, your whole cluster is pwned", right?

Well the attacker can be inside, or can infiltrate part of your network, then combine this attack to get control over your kubernetes deployment.

Yes, if the call is coming from inside the house, you're already in a bad spot, but going beyond capabilities like DDoS and network traversal (such as also gaining the ability to enumerate the secrets in your k8s) is quite a bit worse.

Also, a public-facing running in the cluster itself could have a vulnerability that, combined with this bug, gives an attacker much further reach.

Here’s a page with some other ingress controllers as well: https://kubernetes.io/docs/concepts/services-networking/ingr...

The Traefik one is also quite pleasant. It does surprise me a bit that we don’t see more ingress controllers built on regular web servers, like a Caddy or Apache2 one, especially because a configurable version of the latter would also help with some homelab or long lived/legacy project environments, given how widespread that web server is.

> Our research show that over 41% of internet-facing clusters are running Ingress-NGINX.

This definitely feels like one of those cases where more fragmentation is a good thing, because at least it limits the fallout of issues like this. I can bet that many out there won’t get the memo and will keep running insecure software.

Already discussed here: https://news.ycombinator.com/item?id=43465424

Reply on news.ycombinator.com