Initial access Execution Persistence Privilege escalation Defense evasion Credential access Discovery Lateral movement Collection Impact
Using Cloud Exec into Container Backdoor Container Privileged Container Clear Container Logs List K8s secrets Access the K8s API server Access cloud resources Images from a private repository Data Destruction
Compromised images in registry bash/cmd in container Writable hostPath mount Cluster-admin binding Delete k8s events Mount service principal Access Kubelet API Container service account Ressource hijacking
Kubeconfig file New container Kubernetes CronJob hostPath mount Pod / container name similarity Access container service account Network mapping Cluster internal networking Denial of Service
Application vulnerability Application exploit (RCE) Malicious admission controller Access cloud resources Connect from proxy server Applications credentials in configuration files Access Kubernetes dashboard Applications credentials in configuration files
Exposed sensitive interfaces SSH server running in inside container Disable Namespacing Access managed identity credentials Instance metadata API Writable volume mounts on the host
Sidecar injection Malicious admission controller CoreDNS poisoning
ARP poisoning and IP spoofing

Application exploit (RCE)

An application that is deployed in the cluster and is vulnerable to a remote code execution vulnerability, or a vulnerability that eventually allows code execution, enables attackers to run code in the cluster. If service account is mounted to the container (default behavior in Kubernetes), the attacker will be able to send requests to the API server using this service account credentials (see also “Access the K8s API server“).

Example

We deploy a Pod which contains an application vulnerability that can be exploited to gain a remote code execution (RCE).

apiVersion: v1
kind: Pod
metadata:
  name: vulnerable-pod
spec:
  containers:
  - image: disenchant/vulnerable-app-demo
    name: vulnerable-app
    ports:
    - containerPort: 80

(To keep this example minimal we assume the container port was made reachable outside of the cluster e.g. by using an Ingress.)

By accessing a URL like http://www.example.com/?shell=whoami (domain pointing to our Pod) we can exploit the simple vulnerability and execute the shell command whoami. With something like http://www.example.com/?shell=cat%20/var/run/secrets/kubernetes.io/serviceaccount/token we can access the service account which is mounted into the container as it executes the shell command cat /var/run/secrets/kubernetes.io/serviceaccount/token inside of the container.

References