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

This article mainly introduces the example analysis of kube-proxy vulnerability CVE-2020-8558 in Kubernetes, which is very detailed and has certain reference value. Friends who are interested must finish it!

Preface

The researchers found a serious security vulnerability (CVE-2020-8558) in the network component kube-proxy of the Kubernetes node, which exposes the internal services of the Kubernetes node. In some cases, this vulnerability may also expose api-server, which will allow unauthenticated attackers to gain full control of the Kubernetes cluster. In this case, the attacker will be able to steal sensitive information stored in the target cluster, deploy encrypted mining software, or remove online services, and so on.

The vulnerability exposes the "localhost service" of the target Kubernetes node, which was originally accessible only from within the node or from the node itself, but now exposes it to the local network or Pods running on that node. The service bound by the local host can only allow trusted local processes to interact with it, so you can usually request the service without authentication. If your node does not require mandatory authentication when running the localhost service, you will also be affected by this vulnerability.

In short, vulnerability CVE-2020-8558 will allow an attacker to access insecure-port in the target Kubernetes cluster and gain full control of the target cluster.

Kube-proxy

Kube-proxy is a network agent running on every node in the Kubernetes cluster, and its task is to manage the connection between the Pods and the service. The Kubernetes service exposes a clusterIP and may consist of multiple back-end Pods to achieve load balancing. A service typically consists of three Pods, each with its own IP address, but they expose only one clusterIP, assuming "10.0.0.1". When Podas accesses the target service, it sends the packet to its clusterIP, "10.0.0.1", but then the packet must be redirected to one of the Pods.

Here, the role of kube-proxy is to provide routing table services for each node, so as to ensure that the request can be correctly routed to one of the Pods.

The culprit-route_localnet

Kube-proxy can configure multiple network parameters through sysctl files, one of which is net.ipv4.conf.all.route_localnet, which is the culprit for this vulnerability. According to the description of the sysctl document: "route_localnet: routing does not need to set the loopback address as the destination address, so you can use 127Comp8 as the local routing address, which defaults to FALSE."

For the IPv4 address, the loopback address consists of 127.0.0.1 IPv4 8 blocks (127.0.0.1-127.255.255.255). Generally, we use 127.0.0.1 and map "localhost" to this address, and packets for local services will be sent to IP 127.0.0.1 through the loopback network interface.

When setting up route_localnet, you need to instruct the kernel not to define the address 127.0.0.1 IP 8 IP as "martian", so what does "martian" mean here? For example, when some packets arrive at a network interface, they can declare their source IP address or destination IP address. Assuming that the packet source IP address is 255.255.255.255, the packet should not exist, because 255.255.255.255 is a reserved address used to identify the broadcast address. At this point, your kernel is unsure and can only determine that the packet comes from an unknown place and should be discarded.

"Martian" packets often mean that someone is trying to attack you over the network, and in the above example, the attacker may want your service to respond to IP 255.255.255.255 and allow the route to broadcast the response message. But in some complex routing scenarios, you may want the kernel to allow certain "martian" packets to pass through, and that's what route_localnet does. It tells the kernel not to define the address 127.0.0.1 IP 8 IP as the "martian" package. Kube-proxy enables route_localnet to support a variety of routing packets, so without deploying proper security mechanisms, attackers will be able to perform various attacks over the local network and using route_localnet.

Localhost-only service

Linux allows processes to listen on a specified IP address so that they can be bound to the network interface corresponding to the address. Internal services typically use this feature to listen on 127.0.0.1, which generally ensures that only local processes can access the service. However, due to the presence of route_localnet, external packets will also be able to reach 127.0.0.0Uni8.

Access internal services

In this case, if an attacker attempts to access the internal services of the target device, a malicious packet with a destination IP of 127.0.0.1 and a destination MAC address of the target device MAC address needs to be constructed. If the destination IP is invalid, malicious packets can only rely on layer 2 (MAC-based) routing to reach the target device. Therefore, even if the target user has route_localnet enabled, only attackers on the local network can access the localhost service of the target device.

When the target device receives a malicious packet, route_localnet will allow the packet to pass, because the packet's destination IP is 127.0.0.1, then it will be allowed to access the localhost service. The following table shows the structure of the malicious package:

Due to the existence of kube-proxy, every node in the cluster has route_localnet enabled. Therefore, each host in the node's local network will be able to access the node's internal services. If your node does not deploy an authentication mechanism when running internal services, you will be affected by this vulnerability. It is worth mentioning that in addition to the neighboring hosts in the node's internal network, the Pods running in the node can also access its internal services.

Vulnerability repair

The Unit 42 team reported the vulnerability to the Kubernetes security team, which said that if the cluster has api-server insecure-port enabled, the vulnerability is at high risk and if it is not enabled, it is moderately dangerous. Fortunately, the impact of this vulnerability is limited to most managed Kubernetes services, such as Azure Kubernetes Service (AKS), Amazon's Elastic Kubernetes Service (EKS), and Google Kubernetes Engine (GKE).

The vulnerability affects Kubernetes versions 1.1.0 to 1.16.10, 1.17.0 to 1.17.6, and 1.18.0 to 1.18.3. Kubernetes versions 1.18.4, 1.17.7 and 1.16.11 have fixed this vulnerability.

The above is all the contents of the article "sample Analysis of kube-proxy vulnerability CVE-2020-8558 in Kubernetes". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

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.