Three new NGINX ingress controller vulnerabilities reported and how they affect Kubernetes

CVE-2023-5043, CVE-2023-5044 and CVE-2022-4886 can be exploited by attacker to steal secret credentials from the cluster. Read all about it 👇

Three security issues were reported on October 27th by the Kubernetes security community, all of them related to the popular NGINX ingress component.

https://github.com/kubernetes/ingress-nginx/issues/10571

https://github.com/kubernetes/ingress-nginx/issues/10572

https://github.com/kubernetes/ingress-nginx/issues/10570

NGINX ingress 

Ingress in Kubernetes is an API object that provides HTTP and HTTPS routing to services based on a set of rules, including hostnames or URL paths. NGINX Ingress Controller is a solution that manages this routing mechanism using the widely known NGINX reverse proxy server.

There are more than one implementations of the ingress controller concept, all of them based on well known proxy projects like NGINX, Traefik and HAProxy. NGINX was the first implementation of ingress and is still the most popular one. That means thatany NGINX vulnerabilities have a wide impact.

CVE-2023-5043 and CVE-2023-5044

These vulnerabilities enable an attacker who can control the configuration of the Ingress object to steal secret credentials from the cluster. In default configuration, these secrets include credentials for the Kubernetes API server with very high privileges.

The attacker can either use annotation field “configuration-snippet” (2023-5043) or “permanent-redirect” (2023-5044) to inject arbitrary code into the ingress controller process and get access to everything this process has access to. Among them the service account token of the ingress controller, which has a ClusterRole which enables reading on all Kubernetes secrets of the cluster.

In theory, an outside actor cannot change these configurations. However there are multiple scenarios to consider:

• Multi-tenant clusters, where users have rights to manipulate Ingres objects in their own namespaces
• Malicious configurations coming from untrusted sources (malicious Helm charts)
• Using configuration examples from the web or ChatGPT, that can be tainted by malicious actors
• Insider who has change rights to configurations, but no access to cluster

We have discussed previously on ARMO Blogs that there are use cases where Pod definition rights can lead to privilege escalation via host mounts, these vulnerabilities are even more serious since Ingress object definition rights are not considered as elevated privileges while Pod definition is.

Mitigation

In order to mitigate the problem two actions need to be taken: 

1.  Update NGINX to version 1.9.0
2. Add the “–enable-annotation-validation” command line configuration

There is no “fixed version” for these vulnerabilities, if updating to version 1.9.0 and adding the command line “–enable-annotation-validation” mitigates the problem.

CVE-2022-4886

This vulnerability, just as the previous two, enables an attacker who can control the Ingress object to steal Kubernetes API credentials from the ingress controller and thus, if the ingress controller has access to all secrets in the cluster then the attacker can also.

The vulnerability is in the way the “path” field is used in the Ingress routing definitions. In the Ingress object the operator can define which incoming HTTP path is routed to which inner path. The vulnerable application does not checks properly the validity of the inner path an it can point to the internal file which contains the service account token that is the client credential for authentication against the API server.

The same attack scenarios as mentioned above are applicable here. 

The mitigation is different depending on the way the operator uses the Ingress rules. 

In case the rule has “pathType” “Exact” or “Prefix”, the “strict-validate-path-type” option should be enabled from nginx-ingress-controller version 1.8.0. In case that “pathType” “ImplementationSpecific” is used, then the mitigation involves admission controller policy like in this example to filter out the malicious path: https://kubernetes.github.io/ingress-nginx/examples/openpolicyagent/ 

Summary

Although they point in different directions, all of these vulnerabilities point to the same underlying problem. The fact that ingress controllers have access to TLS secrets and Kubernetes API by design makes them workloads with high privilege scope. In addition, since they are often public internet facing components, they are very vulnerable to external traffic entering the cluster through them.

ARMO’s Attack Path feature is here to pinpoint these vulnerable components in your environments that require actions.