Kubernetes
Container Orchestration for managing big scalable infrastructure of containerized applications
Last updated
Container Orchestration for managing big scalable infrastructure of containerized applications
Last updated
The way of attacking a Kubernetes cluster is similar to attacking Windows Active Directory:
Find a vulnerability in an application (RCE, SSRF, SSH, etc.)
Perform Lateral Movement to access more pods and nodes with higher privileges
Reach the Highest Privileges to do anything an attacker wants
The /var/run/secrets/kubernetes.io/serviceaccount/token file (sometimes /run instead of /var/run) on a Kubernetes pod contains a Service Account Token in the form of a JSON Web Token. It can be decoded, and the payload tells you exactly who or what the account belongs to:
This token can be used for Lateral Movement in the rest of the cluster and interact with the API server, and due to being in the internal network, a lot more servers are now accessible. A few useful endpoints are:
/api/v1/namespaces/default/pods/: List all pods
/api/v1/namespaces/default/secrets/: List all secrets
These can be requested with the found Service Account Token (JWT) as a header:
If the machine has kubectl installed (or you download a static binary), it is also possible to simply use it instead of manual curl commands. Some similar and useful commands are:
At the time of writing, Helm V3 is the newest version, but many clusters still use the outdated V2. This bears some serious security considerations as the Tiller component has full cluster administration RBAC privileges, which can be exploited if we have access to helm.
Taken from here, you can test the TCP connection on port 44134 and verify the version:
To start exploiting this, a ready-to-use template exists that requires some minimal changes:
Inside the newly created ./pwnchart folder there the two clusterrole.yaml and clusterrolebiniding.yaml files in the templates/ folder require the following change:
As well as the values.yml file where the name: key needs to be changed to the name of the service account token which will gain all privileges. Make sure this is a service account you own:
Finally, after setting this up you can run the command to install it:
After doing so, the compromised-user token will have every permission on the cluster and can access anything. Check kubectl get all for a list of everything.
