Shulou(Shulou.com)05/31 Report--

This article is to share with you the content of the example analysis of Kubernetes's man-in-the-middle vulnerability CVE-2020-8554. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Overview of vulnerabilities

On December 4, 2020, the Kubernetes Product Safety Committee revealed a new Kubernetes vulnerability, CVE-2020-8554. This is a medium-to-critical vulnerability and all Kubernetes versions will be affected by it. This vulnerability allows the Kubernetes service to intercept cluster traffic to any IP address, which can be exploited by any user who can manage the service to perform man-in-the-middle (MITM) attacks on Pod and nodes in the cluster.

Attackers can use MITM attacks to disguise as internal or external nodes, then obtain credentials from network traffic, tamper with the target user's data before sending it to its intended target, or completely prevent it from communicating with a specific IP address. However, if you use the encryption protocol of the TLS address class, the attacker is not so easy.

Multi-user clusters are more affected by this vulnerability because they are most likely to have non-administrator users who can manage services.

The Kubernetes Product Safety Board determined that patching CVE-2020-8554 would result in changes in several functions of Kubernetes, so there was no solution to this vulnerability in the short term. On the contrary, the Commission has provided several restrictions that can mitigate the impact of the vulnerability.

Loophole analysis

CVE-2020-8554 stems from design flaws in two features of Kubernetes services: external IP and load balancer IP. Kubernetes services are abstract methods that expose applications running on a set of Pod as network services. A service is exposed to one or more IP addresses, and once the deployment is complete, the nodes in the cluster will route the traffic destined for the service IP to a backup Pod that makes up the service.

Everything is fine when the cluster manages and allocates the service IP. But the problem arises when Kubernetes users are able to assign arbitrary IP to their services. In this case, a malicious user can allocate IP that has been used by other nodes (internal or external) and intercept all cluster traffic from those IP. We have two ways to control the IP of the service:

Assign an external IP

Assign a load balancer IP through the loadBalancer.ingress.ip field, which requires patch service/status permission.

When deployed to a cluster, the following service will block all cluster DNS traffic to the IP address of 8.8.8.8 (Google's DNS server), and then route it to evil-dns-server Pod:

In order to receive intercepted traffic, the attacker must control the nodes that support their malicious services. In most cases, we will choose a Pod, but the service can also be hosted by an external node (rather than a cluster Pod), which means that an attacker can also route intercepted traffic to an external node outside the cluster. This requires an attacker to create a Kubernetes node that points to an external address, which requires create endpoint privileges.

CVE-2020-8554 intrusion identifier IoC

If you find one of the following situations, you may have been attacked:

Services should not be exposed to external IP or load balancer IP

The external IP of a service or the load balancer IP matches an external IP address in the cluster, such as the cluster IP of a Pod IP or other service

The external IP of a service or load balancer IP points to a known external domain name, such as 8.8.8. We can execute nslookup to determine whether an IP points to a known domain name.

The load balancer IP of a service is 0.0.1, indicating that the node host traffic has been hijacked.

To identify whether the services in the cluster are exposed to an external IP address, run the following command:

Kubectl get services-all-namespaces-obsolete jsonpathologic'{"NAMESPACE\ tNAME\ tEXTERNAL IPS\ n"} {metadata.items [? (.spec.externalIPs)]} {.metadata.namespace} {"\ t"} {"\ n"} {end}'| column-t-s "$(printf'\ t')"

To identify whether the services in the cluster are exposed to the load balancer IP address, you can run the following command:

Kubectl get services-all-namespaces-obsolete jsonpathologic'{"NAMESPACE\ tNAME\ tLOAD BALANCER IPs\ n"} {metadata.items [? (.status.loadBalancer.ingress [*] .IP)]} {"\ t"} {"\ t"} {range .status.loadBalancer.ingress [*]} {"\" IP} {"\", "} {end} {"]\ n "} {end}'| sed's /\ (. *\) /\ 1ax'| column-t-s "$(printf'\ t')" Prisma Cloud Compute mitigation scheme

Prisma Cloud Compute's built-in Admission support for Rego rules can be used to implement the mitigation scheme proposed by the Kubernetes Product Safety Committee.

Restrict external IP access

Customers can use the following methods to set licensing rules to prevent services from accessing external IP, and customers can select allowed IP addresses by setting a whitelist.

Follow the Prisma Cloud Compute documentation to enable Admission Control in your cluster.

Download the [Mitigation for Kubernetes CVE-2020-8554-External IPs] rule template, and we can download the rules using the following command:

Wget https://raw.githubusercontent.com/twistlock/k8s-cve-2020-8554-mitigations/main/PrismaExternalIPs.json

Go to 'Defend/Access/Admission' and click' Import', then select the downloaded rule template, and click the 'Add' button:

To use some IP as an external IP, update the rules as shown in the following figure, and the whitelist of the following rules IP is 54.74.83:

Once the rules are set, any attempt to expose the service to a prohibited external IP will fail and an alert will be triggered.

Summary

CVE-2020-8554 is a unique vulnerability due to a design flaw in Kubernetes services. If your cluster is a multi-user cluster or allows unauthorized users to create and update services, you are likely to be affected by this vulnerability. If the applications in the cluster are not forced to encrypt communications through TLS, you are at greater risk. Even if the vulnerability is not fixed, the mitigation measures proposed by the Kubernetes Product Safety Committee can effectively prevent such attacks.

Thank you for reading! This is the end of this article on "example analysis of Kubernetes's man-in-the-middle vulnerability CVE-2020-8554". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.