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

Two weeks ago, the Kubernetes Product Security Committee disclosed a security regression known as CVE-2020-8554. This man-in-the-middle (MITM) vulnerability impacts all multitenant Kubernetes clusters operating on any version. A patch is not yet available. 

Prisma Cloud Identity-Based Microsegmentation is a cloud native solution that can address the MITM problem. It effectively protects hosts and containerized applications without slowing down application and DevOps teams. 

I’ll explain why Identity-Based Microsegmentation is important when securing cloud-native applications and how it addresses the MITM problem, but first, let’s do a technical analysis of the risk and how to replicate this vulnerability.

 

Why CVE-2020-8554 Presents Risk

Kubernetes is the leading orchestration technology used across public and private clouds. In the 2020 Cloud Native Computing Foundation adoption survey, 91 percent of respondents reported using Kubernetes, with 83 percent using Kubernetes in production.

Regardless of the Kubernetes version running on production clusters, organizations are impacted by this vulnerability – especially multitenant clusters running multiple users. An adversary only needs permissions to create or update Kubernetes services and pods. With these basic privileges, an attacker can configure a new service such that inherits any public IP. 

If containerized applications depend on a service outside of the Kubernetes environment (e.g., GitHub or a repo), the attacker can assign the IP of those external dependencies to their own Kubernetes service. From thereon, any time an application wants to communicate with those external dependencies, the attacker’s new service will intercept the traffic as a man-in-the-middle. 

Diagram comparing normal app communication behavior and behavior of a compromised cluster.
Due to CVE-2020-8554, an attacker can intercept traffic that was intended for an external dependency.

Reproducing the MITM Vulnerability

The Prisma Cloud product team spent just a few moments replicating this vulnerability in a small lab. Here is what we did:

  1. Spun up a client application in Kubernetes with external service dependencies. In this example, our application initiates outbound communications to cncf.io. It should be noted that this vulnerability applies to any public IP – not specific to IP addresses associated with CNCF. 
  2. Created a rogue pod and service, acting as an attacker would.
  3. Exposed the rogue service via an external IP. We obtained the public IP of cncf.io and used this network address as the external IP of the rogue service configuration. 

Now when the client app initiates a connection to cncf.io, the rogue pod intercepts the service. Why is this possible? When exposing a service via an external IP address, the Kubernetes cluster does not check for other colliding IP addresses. The Kubernetes commands below were implemented to create the service as an attacker would: 

kubectl create namespace rogue

kubectl run rogue-pod --image nginx:latest --port 80 -n rogue

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  name: rogue-service
  namespace: rogue
spec:
  selector:
    run: rogue-pod
  type: LoadBalancer
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
  externalIPs:
    - 23.185.0.3 #cncf.io
EOF

 

How Are Organizations Addressing This?

Kubernetes administrators have been advised to mitigate risks associated with the MITM vulnerability with workarounds such as:

  • Continuously monitor external IP addresses and reduce the usage of external IPs in Kubernetes environments
  • Restrict the use of external IPs for services using solutions like Open Policy Agent (OPA)
  • Restrict admin cluster permissions
  • Reduce the usage of multitenant clusters

These workarounds come with operational challenges for both security and application teams while slowing down the application development lifecycle. 

Some admins turn to Kubernetes network security points tools; however, these methods apply address-based controls, which do not prevent an attack once a trusted IP is spoofed. How can businesses continue to operate without compromising speed and security?

 

The Answer: Identity-Based Microsegmentation

Prisma Cloud Identity-Based Microsegmentation takes a unique approach to cloud network security. Here are three reasons why Prisma Cloud is the right approach: 

  • Decoupling Security from the Network: Networking is about interconnecting applications and microsegmentation is about isolating them. Forcing the two together creates complexity and security gaps. Prisma Cloud assigns cryptographic software identity to all of the cloud workloads you want to protect – enabling granular visibility and stronger protection.
  • Zero Trust Protection: Identity-based microsegmentation does not rely on IP data to protect against unauthorized communications, but rather relies on a mutual authorization process based on the identity of Kubernetes pods. Workloads protected by Prisma Cloud mutually verify software identity for every new communication before granting access to application data. This ensures an attack – even through MITM – cannot move laterally through the network.
  • Designed to Keep Pace with Application Development: DevOps teams can integrate identity-based policies into their automation frameworks without needing to understand the underlying network. Policies adapt to changes in the environment for automated security. 

How Does Prisma Cloud Protect Against The MITM Vulnerability?

Using our Kubernetes MITM vulnerability lab described above, we put Prisma Cloud to the test. First we removed the rogue pod and service. After installing Prisma Cloud, we did two things: 

  1. Wrote a policy to allow our client app outbound access to cncf.io.  
  2. Applied Zero Trust enforcement. This blocks any unauthorized communications.

After visually confirming that our client app was safely communicating with the external service, we re-deployed the rogue pod and service. At this point, the service attempted to intercept traffic destined to the cncf.io IP; however, Prisma Cloud instantly blocked the attacker’s interception without any configuration changes to policy. 

As mentioned earlier, Prisma Cloud assigns a cryptographic identity to all workloads in the environment. When the client pod initiates a connection to the rogue pod, both pods mutually authenticate each other’s identity. 

Unlike IP address-based approaches, Prisma Cloud uses the cryptographic identity to determine whether the pods are authorized to communicate. In this case, these two identities are not authorized to communicate; therefore, the MITM attack was prevented. This level of protection comes out-of-the-box with Identity-Based Microsegmentation. 

A screenshot of the Identity-Based Microsegmentation module in Prisma Cloud mapping a compromised cluster.
Prisma Cloud applies zero-trust enforcement to detect and prevent unauthorized communications among untrusted services.

Identity-Based Microsegmentation from Prisma Cloud helps you understand application dependencies and protect cloud native workloads. By designing security with a Zero Trust approach and not relying on IP addresses to protect communications, organizations don’t have to worry about MITM vulnerabilities and future attacks. 

You can get more details about this module through our product page or download our latest eBook. Or, if you are ready to get a demo of our Identity-Based Microsegmentation module, reach out to request a personalized demo.