A critical Kubernetes vulnerability CVE-2020-8558 puts clusters at risk of remote takeover


Unit 42 research arm of Palo Alto Networks issues alert Kubernetes vulnerability CVE-2020-8558 which allows remote takeover

Palo Alto Network’s Unit 42 has warned that a previously disclosed Kubernetes vulnerability may be more severe than initially thought. The Kubernetes vulnerability CVE-2020-8558 was discovered in April 2020 in the kube-proxy, a networking component running on Kubernetes nodes.

CV-2020-8558 issue exposed internal services of Kubernetes nodes, often run without authentication. The issue details were made public on April 18, 2020, and a patch released on June 1, 2020. Unit 42 researchers say found that some Kubernetes installations didn’t disable the api-server insecure-port, which is normally only accessible from within the master node. This could be used by potential hackers to gain access to the insecure-port and remotely gain control over the cluster.

Unit 42 researchers say that they informed the Kubernetes security team about this vulnerability. The security team rated the severity as High in clusters where the api-server insecure-port is enabled.

The researchers say that the impact of CVE-2020-8558’s is somewhat reduced on most hosted Kubernetes services like Azure Kubernetes Service (AKS), Amazon’s Elastic Kubernetes Service (EKS) and Google Kubernetes Engine (GKE). CVE-2020-8558 was patched in Kubernetes versions v1.18.4, v1.17.7, and v1.16.11 (released June 17, 2020). They confirmed that unpatched Kubernetes clusters were still open to this attack.

Jen Miller-Osborn, deputy director for threat intelligence for Unit 42, says localhost bound services expect that only trusted, local processes can interact with them so they are often not configured without any authentication requirements. The ultimate fix adds mitigations around route_localnet: routing rules that cause nodes to drop external packets. Route_localnet is still enabled by the kube-proxy, but Miller-Osborn says there are ongoing discussions about disabling it.

Miller-Osborn says that even with those mitigations applied, there’s still a unique scenario in which cyber attacks could send packets to Kubernetes internal UDP services. However, the attack only works if the victim node disables reverse path filtering.

You are vulnerable to CVE-2020-8558 if your Kubernetes instance is:

  • is a cluster is running a vulnerable version (earlier than v1.18.4, v1.17.7, and v1.16.11) (Note that while the issue originated from the kube-proxy, the patch is in the kubelet)
  • Your nodes have the kube-proxy running on them.
  • Your nodes (or hostnetwork pods) run localhost-only services that don’t require any further authentication.
  • Your cluster doesn’t disable the api-server insecure-port via –insecure-port=0
  • The api-server runs on a node alongside a kube-proxy, for example, in deployments where the api-server is a pod itself.

About Author

"The Internet is the first thing that humanity has built that humanity doesn't understand, the largest experiment in anarchy that we have ever had." Eric Schmidt

Notify of
Inline Feedbacks
View all comments