February 4, 2021

Kubernetes Man-in-the-Middle Vulnerability: CVE-2020-8554

Security
Containers

By

CVE-2020-8554, which impacts Kubernetes, proves that the world of containers is not immune from the same vulnerabilities that plague bare metal and regular virtual machines. CVE-2020-8554 allows attackers to carry out man-in-the-middle attacks within pods and nodes in a Kubernetes cluster.

In this blog, we'll give background on Kubernetes CVE-2020-8554, including details on how it works, who it affects, and what the CVE looks like when exploited.

What Is Kubernetes CVE-2020-8554?

Kubernetes CVE-2020-8554 is a Kubernetes API server vulnerability that, when exploited, allows "man in the middle" attacks to be carried out against pods and nodes in a cluster.

As it reads, the Kubernetes API server in all versions currently available has a vulnerability that allows an attacker able to create a ClusterIP service and set the spec.externalIPs field to intercept traffic to that IP address. On top of that, attackers that are able to patch the status, an action typically reserved for a privileged operation, of a LoadBalancer service can set the status.loadBalancer.ingress.ip as well. What this really means is that users who can manage services can exploit the vulnerability to carry out man-in-the-middle attacks against pods and nodes in a cluster.

Who Does Kubernetes CVE-2020-8554 Affect?

As of right now, to be clear, this is affecting ALL versions of Kubernetes and it is also unpatched at this time. The vulnerability was discovered by The Kubernetes Product Security Committee. Clusters are affected if they allow non-admin Kubernetes users to create or update services or to patch the services in addition to allowing those users to control a pod, or, allowing those users to create or update endpoints. 

How Does Kubernetes CVE-2020-8554 Work?

The vulnerability stems from a design flaw in two features of Kubernetes services: External IPs and Load Balancer IPs. Kubernetes Services are an abstract way to expose an application running on a set of pods as a network service. That service is exposed on one or more IP addresses. After being deployed, cluster nodes can route traffic destined to the service IPs to one of the backing pods that make up the service. Typically a cluster manages and assigns IP addresses. There’s an issue when a Kubernetes user is able to assign arbitrary IPs to their services. A malicious user can assign IPs that are already in use by other endpoints, either internal or external, and intercept cluster traffic to those IP addresses. You can control an IP address of a service in 2 different ways. First, you can just assign it an external IP. The other is you can assign it a Load Balancer IP.

Kubernetes CVE-2020-8554 Exploit Example

The following Kubernetes CVE-2020-8554 exploit example was provided by Palo Alto Networks:

code showing example of kubernetes cve-2020-8554
CVE-2020-8554 Example (Via Palo Alto Networks)

In this example, a malicious pod called evil-dns-server is attempting to intercept DNS traffic over port 53. Attackers are able to route intercepted traffic to an external endpoint outside of the cluster since services can also be backed by external endpoints. The Kubernetes endpoint needed for this type of attack requires the create endpoint privilege. The most at risk at this time are multi-tenant clusters since they have the highest probability of being configured in the way previously described.

Tenants often use Kubernetes namespaces to separate themselves which limits permissions to each tenant’s namespace. However, despite a tenant only managing services and pods in their own namespaces, the CVE can still be exploited to listen in on all traffic within the entire cluster. It should be noted that clusters currently using Cillium to replace kube-proxy are not affected at all.  

Final Thoughts

While open source packages are typically as, or more, secure than their commercial counterparts, it's important for teams to stay aware of the latest open source vulnerabilities so they can minimize potential exposure.

Early identification of CVEs like CVE-2020-8554 can give your team time to disable impacted features, or establish workarounds until the vulnerability can be patched. 

Worried About Your Kubernetes Security?

Minimizing your exposure to CVEs is a necessity for containerized applications and systems. Our team can help to assess your infrastructure and determine the steps to make it more secure. Talk to an expert today to schedule your assessment.

TALK TO AN EXPERT

Additional Resources

image-zend-blog-author-bio-andrew-pomponio

Andrew Pomponio

Associate Enterprise Architect, OpenLogic by Perforce

Andrew's areas of specialization include networking, Linux, network security including OpenSSL, and operational troubleshooting. He has been working in the industry for over seven years and is acquiring new skills every day.