Two critical security flaws found in Nginx-Ingress controller

Ingress controllers allow users to configure an HTTP load balancer for applications running on Kubernetes. It’s needed to serve those applications to clients outside of the Kubernetes Cluster. It’s also configured with Kubernetes API to deploy objects called Ingress Resources

The NGINX Ingress Controller is a production-grade Ingress controller (daemon) that runs alongside NGINX Open Source or NGINX Plus instances in a Kubernetes environment. The daemon monitors NGINX Ingress resources and Kubernetes Ingress resources to discover requests for services that require ingress load balancing. As the NGINX documentation suggests.

Ingress is responsible for managing HTTP and HTTPS routes from outside of the cluster to services within the cluster. Rules are defined on the Ingress resource to control Routing.

Vulnerability details

On 2021/01/21 CVE-2021-25745 and CVE-2021-25746 were registered on MITRE, but exploits and vulnerabilities descriptions were published only 3 weeks ago. There are information disclosure vulnerabilities in Nginx-ingress that allow attackers to obtain the credentials of the ingress-nginx controller. They were assigned a CVSSv3 score of 7.6 (high severity).

The first vulnerability in the Nginx-Ingress controller arises from spec.rules[].http.paths[].path field and the second from .metadata.annotations. A user with creating/deleting permissions in an Ingress object can use the mentioned fields to obtain the credentials of the ingress-nginx controller.

How to know if you are affected?

The vulnerability in question affects the Nginx-ingress. If you don’t use Nginx-ingress you have nothing to worry about. You can check if you have Nginx-ingress installed by using the command below:

kubectl get po -n ingress-nginx

Affected and Fixed Versions:

Any version before v1.2.0. is vulnerable. This vulnerability has been fixed in version 1.2.0.

Mitigation

Install the fixed versions mentioned in this blog post’s Affected and Fixed Versions section

You can also fix this vulnerability manually by restricting the spec.rules[].http.paths[].path and .metadata.annotations field on networking.k8s.io/Ingress resource.

Go to your Kubernetes Dashboard and Create an ingress resource as follows:

apiVersion: lab.wallarm/v2
kind: 
metadata:
name: restrict-ingress-paths
annotations:
Restrict NGINX Ingress Paths .
spec:
  rules:
- name: restrict
match:
  any:
  - resources:
kinds:
- networking.k8s.io/v1/Ingress
validate:
message: "Path is forbidden"
deny:
conditions:
any:
- key: "{{ request.object.spec.rules[].http.paths[].path.contains(@,'/etc') }}"
operator: AnyIn
value: [true]
- key: "{{ request.object.spec.rules[].http.paths[].path.contains(@,'/var/run/secrets') }}"
operator: AnyIn
value: [true]

- key: "{{ request.object.spec.rules[].http.paths[].path.contains(@,'/var/secrets') }}"
operator: AnyIn
value: [true]

All Wallarm users got this fix as a virtual patch automatically.