New Kubernetes Node Vulnerability (CVE-2020-8558) bypasses localhost boundary

Vulnerability Description and Impact

A security issue was discovered in kube-proxy which allows adjacent nodes/hosts to reach TCP and UDP services bound to 127.0.0.1 running on the node or in the node's network namespace (host network). This breaks security assumptions made by services listening on localhost.

This security bug was originally raised in issue #90259 which details how the kube-proxy sets net.ipv4.conf.all.route_localnet=1 and causes the system not to reject traffic to localhost which originates on other hosts (martian traffic). Such traffic would look like packets on the wire with an IPv4 destination in the range 127.0.0.0/8 and a layer-2 destination MAC address of a target node may indicate that an attack is targeting this vulnerability.

For example, if a cluster administrator runs a TCP service on a node that listens on 127.0.0.1:1234, because of this security bug, that service would be potentially reachable by other hosts on the same LAN as the node, or by containers running on the same node as the service. If the example service on port 1234 required no additional authentication (because it assumed that only other localhost processes could reach it), then it could be vulnerable to attacks that make use of this security bug.

While many Kubernetes installers explicitly disable the API Server's insecure port, and Kubernetes v1.20 is planned to remove this insecure option, An API server that uses this insecure option and listens on 127.0.0.1:8080 will accept requests without authentication.
To mount such an attack on the API server, an attacker must have access to another system on the same LAN or with control of a container running on the master. Managed Kubernetes services such as EKS, AKS, GKE and others should be resilient attacks on the API server insecure port.

Are You Vulnerable?

The vulnerability affects kubelet & kube-proxy which are core Node components:

Affected Versions:

• kubelet/kube-proxy v1.18.0-1.18.3

• kubelet/kube-proxy v1.17.0-1.17.6

• kubelet/kube-proxy <=1.16.10

Or if one or more of the following items are applicable to your environments:

1. Your cluster nodes run in an environment where untrusted hosts share the same layer 2 domain (i.e. same LAN) as the cluster nodes.

2. Your cluster allows untrusted pods to run containers with CAP_NET_RAW which is enabled by default by Kubernetes.

3. Your nodes (or hostnetwork pods) run any localhost-only services which do not require any further authentication. To list services that are potentially affected, run the following commands on nodes:

• lsof +c 15 -P -n -i4TCP@127.0.0.1 -sTCP:LISTEN

• lsof +c 15 -P -n -i4UDP@127.0.0.1

Risk:

• Typical Clusters: medium (5.4) CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

• In clusters where API server insecure port has not been disabled: high (8.8) CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Automatic Detection of adjacent Node attacks with Alcide Runtime

This new vulnerability has long been covered by Alcide Runtime without requiring any configuration by the user.
This detection has been part of Alcide Runtime for a long time, even prior to this vulnerability’s disclosure, and there was no need for us to add additional detection capabilities.

The traffic is flagged as spoofed traffic because localhost traffic should never cross network boundaries. Furthermore, if you explicitly define firewall policies using Alcide’s microservices firewall, then pods can’t access other resources in the network unless explicitly allowed. This is what zero-trust networking is all about!

Automatic Detection of API Server attacks with Alcide kAudit

Exploit attempts of this vulnerability via the unsecured port of the API Server would show up in its audit log as entries from the "system:unsecured" principal, similar to entries from K8s services on the Master node accessing the API Server locally.

Alcide kAudit analyzes the audit log of the Kubernetes API Server, continuously updates and compares behavioral activity profiles to actual observed activity and automatically detects anomalous access patterns from cluster principals (in this case, "system:unsecured" account) to various resource types, k8s APIs, namespaces, and specific resources. Thus, Alcide kAudit can automatically alert security teams to suspected attacks that rely on CVE-2020-8558 as they occur.

Furthermore, Alcide kAudit users can configure and customize it to alert on audit entries violating their specific policy. They can, for example, add alerts on API Server activity that reads or modifies sensitive namespaces or resources in the cluster, and use such alerts if they happen as an indicator that an exploit may be in progress and should be investigated.

Automatic Detection of Vulnerable Clusters with Alcide Advisor

Alcide Advisor is a Kubernetes multi-cluster vulnerability scanner that covers rich Kubernetes and Istio security best practices and compliance checks such as Kubernetes vulnerability scanning, hunting misplaced secrets, or excessive secret access, and many more security configuration and compliance checks.

With Alcide Advisor users can:

1. Identify the vulnerable clusters for this vulnerability (as well as other CVEs)

2. Identify and explicitly allow/deny which Pods can run with elevated privileges that enables CAP_NET_RAW

3. Identify and explicitly allow/deny which Pods can run on the host network.

4. On applicable environments, identify Pods that can run on master nodes that can potentially exploit the Kubernetes API Server.

Conclusion

Kubernetes, like any software, has bugs and vulnerabilities. Leveraging Kubernetes as cloud-native application infrastructure requires operators to monitor and secure all the moving parts, whether these are the application workloads or the platform and infrastructure components. CVE-2020-8558 joins other recent vulnerability disclosures (CVE-2020-8555 and CVE-2020-10749) and highlights the need for a purpose-built Kubernetes security solution that can drive cluster operators to run workloads, applications, and infrastructure while leveraging the best security practices of the native Kubernetes security controls, as well as security monitoring & prevention.

Start your 14-day trial or request a demo.