Kubernetes is a maze: deployments, pods, containers, namespaces, services… When you arrive at kube-world as a beginner (like me) nothing has sense. For a while, I’ve been thinking about to create a checklist for pentesting purposes and put together every tool, repo or technique I’ve been discovering about kubernetes lately, but every implementation of kube is different so this could be consider as much as a basic recon checklist.

Check your kubernetes server version kubectl version Usually, from the offensive perspective, kubernetes is not the “run-that-exploit” scenario that we’re used to. Find breaches on kube is more like checking misconfigurations, exposed resources and so, but if this is your first contact then check out this lab, based on CVE-2020–8558 exploitation, directly related on a vulnerable kubernetes version:

TryHackMe | Kubernetes Chall TDI 2020 Kubernetes Challenge/Workshop by Tabitha Sable from The Diana Initiative 2020 CTF tryhackme.com

2. Dump all

for res in $(kubectl api-resources -o name);do kubectl get "${res}" -A -o yaml > ${res}.yaml; done Based on :

Build software better, together You can't perform that action at this time. You signed in with another tab or window. You signed out in another tab or… github.com

Just dump everything, we’ll use later.

3. Check anonymous access

#Kube API curl -k https://<master_ip>: #Check etcdctl (binary on https://github.com/etcd-io/etcd/releases) etcdctl –endpoints=http://:2379 get / –prefix –keys-only #Kubelet curl http://:10255/pods These resources may allow us to retrieve many information from the cluster or even run commands anonymously.

Etcdctl Cheat sheet:

etcd Cluster infos Accessing the key space Batch queries Creating a path Manipulate keys Make data and paths expire by… lzone.de

Kubelet API basic code exec:

Kubernetes: unauth kublet API 10250 basic code exec - Security Boulevard Unauth API access (10250)Most Kubernetes deployments provide authentication for this port. securityboulevard.com

Accessing Kubelet API:

4. Check images version

kubectl get deployments -A -o yaml | grep "image:" This will output all the images deployed on the cluster and their version, then check out if some of them are vulnerable. This helped me to discover a vulnerable blackbox image that allows SSRF into the cluster, so do it!

5. Check services

kubectl get services -A -o wide You can take this output as an nmap result, there’re services exposed (or not, maybe they’re only reachable inside the cluster) just check and try to exploit those services as a “legacy” system.

6. Check deployments

We can use deployments.yaml extracted on section 2, or:

kubectl get deployments -A -o yaml > deployments.yaml Deployments are the main recipe, here’s where the DevOps tell to kubernetes what they want to run and how everything should work. We’ve a few tools to check this yaml file, just check out this article:

Validating Kubernetes YAML for best practice and policies Published in June 2020 TL;DR: The article compares six static tools to validate and score Kubernetes YAML files for… learnk8s.io

Those tools will find missconfigurations that may lead us get in the cluster.

I recommend this tool that is not mentioned in the previous article but it works pretty fine, let me introduce you to checkov:

bridgecrewio/checkov Checkov is a static code analysis tool for infrastructure-as-code. It scans cloud infrastructure provisioned using… github.com

checkov -f deployments.yaml 6. Check permissions

kubectl auth can-i --list (-n <namespace) Check what you can do, the best thing you can find here is * which means ALL resources (pods, secrets, deployments…) and/or ALL actions (get, list, create, patch….)

7. Check risky roles

If you have enough permissions just check the role binding permissions with this:

cyberark/kubernetes-rbac-audit ExtensiveRoleCheck is a Python tool that scans the Kubernetes RBAC for risky roles. The tool is a part of the… github.com

As CyberArk wrote: “The privilege to create Rolebindings allows a user to bind roles to a service account. This privilege can potentially lead to privilege escalation because it allows the user to bind admin privileges to a compromised service account.” (Source https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1)

8. Pod capabilities

Enter to any pod:

kubectl exec -ti <pod_name> -n bash Some images have no bash or PATH variable is not defined, so you can also run:

kubectl exec -ti <pod_name> -n /bin/sh Then, when you’re in a pod check what it can do:

capsh --print Many capabilities will be shown, here we got some interesting capabilities:

· cap_sys_admin: In some cases this can mount/umount disks on the host machine, so try if you can see disks from the pod and mount them:

fdisk -l (or lvsdisplay for LVM partitions) mount /dev/ /mnt/ #you can then run commands on localhost #i.e. create a user in the host machine: ​chroot /mnt/ adduser john · cap_sys_module: This allow us to insert/remove kernel modules in/from the host machine. I.e. you can use any reverse shell (or anything else) write in C and load it as a kernel module.

· cap_sys_ptrace: You may debug processes of the host machine, just run a ps -ef and host processes will be shown. Pentester Academy has a great labs about process injection that may help you on this topic. I won’t pretend that I know how process injection works, so if you’re brave and talented enough then go ahead. I do not recommend this on production environments.

In a safer way, you may want to try this to run any command from inside the pod into the host node:

nsenter --all --target=1 Source: https://twitter.com/infosec_scarlet/status/1347288430531604480

· cap_sys_boot: Reboot system and load a new kernel. Too risky.

· cap_net_raw: You can forge your own raw network packets from inside the pod as some malwares do.

· cap_dac_read_search & cap_dac_override: Bypass file read permission checks and directory read and execute permission checks. (Check: http://stealth.openwall.net/xSports/shocker.c)

9. Sensitive information

Pods are interesting not only by its capabilities, they may contain sensitive information so get in and harvest some intel.

10. Tokens

Every pod as a token (JWT) to talk to API Server, so retrieve them from inside the pod:

#Dump tokens from inside the pod kubectl exec -ti -n cat /run/secrets/kubernetes.io/serviceaccount/token #Dump all tokens from secrets kubectl get secrets -A -o yaml | grep " token:" | sort | uniq > alltokens.txt I usually like to check if those tokens can reach other namespaces or can read sensitive information, so try them:

#Standard query: curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:#/api/v1/namespaces/// #Example: curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:/api/v1/namespaces/default/pods/ 11. Secrets

With the previous tokens, check out if they can read secrets from other namespaces, you may obtain passwords, ssh keys, OAuth tokens…:

curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:/api/v1/namespaces//secrets/ 12. Breakout pods, reach the node

We got several techniques on how to get out the pod:

Abusing pod capabilities or privileged pods: We’ve already discussed some of them on capabilities section. Scan your default gateway: From pod POV the default gateway (x.x.x.1) is part of the host, try to scan it and discover some vulnerable services reachable from the pod shell. Deploy malicious pods: If you reach the API Server and you’re allowed to create new pods, deploy a malicious one and mount the root folder / from the node. We’ve already discusses on cap_sys_admin how to abuse this scenario. Abuse the already mounted insecure hostPath: Check the articles below