Critical Unauthenticated Remote Code Execution Vulnerabilities in Ingress NGINX

https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities

by puppion • 1 year ago

79 11 1 year ago

SCdF• 1 year ago

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

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.

kjs3• 1 year ago

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.

INTPenis• 1 year ago

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.

Zacru• 1 year ago

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

pcthrowaway• 1 year ago

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.

boxed• 1 year ago

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.

yoru-sulfur• 1 year ago

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

arccy• 1 year ago

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....).

rollulus• 1 year ago

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?

KronisLV• 1 year ago

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.

Critical Unauthenticated Remote Code Execution Vulnerabilities in Ingress NGINX

Related Stories