A serious vulnerability in the Kubernetes could enable an attacker to gain full administrator privileges over the open source container system’s compute nodes.
The bug, CVE-2018-1002105, is a privilege escalation flaw in RedHat’s OpenShift open source Kubernete’s platform and was spotted by Darren Shephard, founder of Rancher Labs.
The flaw effectively allows hackers to gain full administrator privileges on Kubernetes compute nodes, the physical and virtual machines on which Kubernetes containers run upon.
Once those privileges have been gained, hackers can then steal data, input corrupt code or even delete applications and workloads.
The flaw can be exploited in two ways: one through a ‘normal’ user gaining elevated priveledges over a Kubernetes pod, which is a group of one or more containers that share network and storage resources and run in a shared context, and from there they could wreak havoc.
The second involves the exploitation of API extensions that connect a Kubernetes application server to a backend server. While a hacker will need to create a tailoured network request to hanress the vulnerability within this context, once done they could send requests over the network conection to the backend of the OpenShift deployment.
From there attacker has ‘cluster-level’ admin privileges – clusters are a collection of nodes – and therefore escalated privileges on any node. This would allow said attacker to alter existing brokered services to deploy malicious code.
Due to the connection on Kubernetes API servers, where its authenticated with security credentials, malicious connections and unauthenticated users with admin privileges appear above board. This makes the flaw and its exploitation difficult to identify as would-be hackers appear as authorised users.
According to GitHub, this makes the vulnerability a critical flaw, mostly due to the fact it allows anyone with access to cause damages, but also because of its invisibility as abusing the flaw leaves no traces within system logs.
«There is no simple way to detect whether this vulnerability has been used. Because the unauthorized requests are made over an established connection, they do not appear in the Kubernetes API server audit logs or server log. The requests do appear in the kubelet or aggregated API server logs, but are indistinguishable from correctly authorized and proxied requests via the Kubernetes API server.»
There are fixes and remedies to this flaw, but it’s mostly about upgrading the version of Kubernetes you run. Now. There is patched versions of Kubernetes, such as v1.10.11, v1.11.5, v1.12.3, and v1.13.0-rc.1 and it is recommended that you stop using Kubernetes v1.0.x-1.9.x.
For those that cannot move up, there are cures; you must suspend use of aggregated API servers and remove pod permissions from users that should not have full access to the kubelet API.