Critical Vulnerability Allows Kubernetes Node Hacking
Kubernetes has received fixes for one of the most serious vulnerabilities ever found in the project to date. If left unpatched, the flaw could allow attackers to take over entire compute nodes.
“With a specially crafted request, users that are allowed to establish a connection through the Kubernetes API server to a backend server can then send arbitrary requests over the same connection directly to that backend, authenticated with the Kubernetes API server’s TLS credentials used to establish the backend connection,” the Kubernetes developers said in an advisory.
Furthermore, in default configurations, both authenticated and unauthenticated users are allowed to perform API discovery calls and could exploit this vulnerability to escalate their privileges. For example, attackers could list all pods on a node, could run arbitrary commands on those pods and could obtain the output of those commands.
Known mitigations include not using aggregated API servers or removing the pod exec/attach/portforward permissions from users that should not have full access to kubelet APIs. Both of these strategies are likely to be disruptive to existing deployments, so upgrading to patched Kubernetes versions as soon as possible is recommended.
The privilege escalation vulnerability, tracked as CVE-2018-1002105, was fixed in Kubernetes versions 1.10.11, 1.11.5 and 1.12.3. Versions 1.0.x to 1.9.x are also affected but have not received patches.
Detecting if the vulnerability has already been exploited in an environment is not easy because the authorized requests don’t get recorded in the Kubernetes API server’s audit logs or server log. They do appear in the logs for the kubelet or the aggregated API server, but cannot be easily distinguished from all the other legitimate requests.
“All 3.x versions of OpenShift Container Platform allow for compromise of pods (multiple running container instances) running on a compute node to which a pod is scheduled with normal user privilege,” Red Hat said in an advisory. “This access could include access to all secrets, pods, environment variables, running pod/container processes, and persistent volumes.”
In OpenShift Container Platform 3.6 or higher, the vulnerability also allows attackers to obtain cluster-admin access to any API of an aggregated API server, including the metrics-service and service catalog. With access to the service catalog, an attacker could create brokered services in any namespace or node, deploying malicious code or altering existing services.
“This is a big deal,” said Ashesh Badani, the vice president and general manager for Cloud Platforms at Red Hat, in a blog post. “Not only can this actor steal sensitive data or inject malicious code, but they can also bring down production applications and services from within an organization’s firewall.”
Red Hat has released fixes for OpenShift Container Platform versions 3.2 and higher but has also provided detailed mitigation instructions in its advisory for environments where updates can’t be immediately applied.
“This is where open source products can separate themselves from projects,” Badani said. “Red Hat has decades of experience in delivering open source products, from hardening code for enterprise requirements to delivering fixes for vulnerabilities and flaws. […] Part of this expertise is knowing that it’s not enough to push a fix – we need to provide our customers with the documentation and strategies to help them assess how they are affected, what systems are affected and why (or even why not) they should apply the fixes.”
“All Google Kubernetes Engine (GKE) masters were affected by these vulnerabilities, and we have already upgraded clusters to the latest patch versions,” the Google Cloud team said in a security bulletin. “No action is required.”
The Cloud Native Computing Foundation, which manages Kubernetes, and Red Hat are sponsors of The New Stack.
