Kubernetes user impersonation to obtain exec privileges

Question

I am exploring CVE 2018-1002105 about privilege escalation vulnerabilities in Kubernetes. As a remote unuauthenticated user, I would want to make use of a metrics server deployed on my cluster to exec arbitrary commands on any pod.

I am quite confused on how to do so. Currently, I have sent a GET request to the kube api server to request for a connection upgrade to web socket (CVE), and then i used the x-remote-header user to impersonate a user in the cluster that has access to the metrics server (in this case i used X-Remote-User: system:serviceaccount:kube-system:horizontal-pod-autoscaler)

However, I am unable to exec and I think it is because this user does not have exec privileges. How do I check this?

I am also thinking of creating my own user with root privileges and can do anything he wants on the cluster and impersonate him instead. How do I do this and also ensure this user has access to the metrics server?

Answer 1

So as a first point on this one you're not going to be able to exploit this CVE without a very old version of Kubernetes as it's been patched back in 2018. From the advisory we're talking Kubernetes 1.12 at the latest.

The way this issue is exploited is described pretty well in this Unit42 blog, and if you're looking for a walkthrough and PoC, I'd refer to that post in the first instance.

The attack path you're describing is the one relating to Aggregated API servers, so it only applies if you're using an external aggregated API server such as the metrics server and it was possible as, in those days, unauthenticated users had rights to make discovery requests to aggregated API servers. That attack path was hardened up in 1.14 when the rights of unauthenticated users to the API server were reduced.

To answer some other tagental points from your question. The best way to check your rights to a Kubernetes cluster is kubectl auth can-i --list which will return back your rights as determined by the RBAC system.

If you are using a metrics server that's deployed to a Kubernetes cluster, and you have a user with cluster-admin rights (effectively root) they'll have rights to modify that service, as they'll have all rights to workloads deployed in the cluster.