The recently disclosed critical-impact bug in Kubernetes created strong ripples in the security space of the container-orchestration system. Now, multiple demo exploits exist and come with easy-to-understand explanations.
The severity score of the vulnerability (CVE-2018-1002105) has been established at 9.8, just 0.2 points shy of the perfect ten. This is because one avenue of attack involves unauthenticated users who could escalate privileges and run commands that could allow them to take over entire compute nodes.
An attacker would have to send a specially crafted request to set up a connection to a backend server using the Kubernetes API server. By default, the system’s configuration enabled users, authenticated or not, to perform API discovery calls, making a threat actor’s work easier.
Although mitigations exist, “none can really be applied without breaking anything else in the cluster,” says Twistlock security researcher Ariel Zelivansky.
Multiple PoC exploits available
Soon after the vulnerability disclosure, code that demonstrated the security bug emerged in public repositories. Zelivansky wrote a simple Ruby script that leverages the flaw against the ‘metrics-server‘ for monitoring container CPU and RAM resources, which uses the API server extension feature.
In a demo video released yesterday, the researcher shows that his exploit “leaks information on pods from all namespaces in the cluster. It can be executed from any pod and should work assuming metrics-server deployed and default configuration.”
Another proof-of-concept comes from software-as-a-service company Gravitational who made it available on GitHub on December 5, just two days after the Kubernetes developers announced the vulnerability and the availability of new software versions to mitigate it.
The PoC is actually a test utility that checks if a Kubernetes cluster is vulnerable to CVE-2018-1002105. It comes with the warning that under it may render incorrect results under some circumstances.
“This test operates by connecting to the apiserver, and checking for side effects of the apiserver that exhibit the bug in Kubernetes. Running this proof of concept through a layer 7 load balancer, may falsely indicate that the API is vulnerable to CVE-2018-1002105,” reads the advice.
Exploit for unauthenticated users
A third exploit code has been published by a developer with the Twitter username Vincent. Initially, he released code for exploiting the Kubernetes flaw by an authenticated user, and achieved stealing information from the default ‘etcd-kubernetes’ pod – a key-value store for critical data.
Over the weekend, the developer created code for exploiting the flaw to allow privilege escalation without authentication.
I have the unauthenticated privilege escalation working! But cannot find a way to leverage that into getting pod access yet… #kubernetes63:57 PM – Dec 9, 2018Twitter Ads info and privacySee Vincent’s other TweetsTwitter Ads info and privacy
A few hours after tweeting the above, Vincent announced that the exploit was ready and pointed to his GitHub. He said that although his demo allows an unauthenticated user to get cluster-admin rights on the Service Catalog extension API, it should be successful with any API exposed through the aggregates layer. Furthermore, the developer adds that it might also work to get code execution on the pods.
The unauthenticated #Kubernetes exploit has been finished! 😀 Repo here: https://github.com/evict/poc_CVE-2018-1002105#unauthenticated-poc … Demo here: https://asciinema.org/a/TjbO5p1JJN0dnNSSWhrcopn9e …3156:59 PM – Dec 9, 2018Twitter Ads info and privacyuntitledRecorded by kubesasciinema.org178 people are talking about thisTwitter Ads info and privacyK