Container security is a critical aspect of modern cloud-native environments. As a Red Teamer, understanding how to exploit containerized applications and the underlying orchestration platforms (like Kubernetes) is essential for identifying vulnerabilities and improving security posture.
This post serves as the first part of a collection of notes and techniques for assessing container security, focusing on initial access and container breakout.
1. Initial Access
Initial access to a containerized environment often starts with compromising a running container or gaining access to the cluster API.
Vulnerable Applications
Web applications running inside containers are susceptible to the same vulnerabilities as traditional applications (SQLi, RCE, SSRF). However, successful exploitation lands the attacker inside a container, which is a restricted environment.
Misconfigured Kubelet
If the Kubelet API is exposed (port 10250) and allows anonymous access, an attacker can run commands inside containers.
# Check if Kubelet allows anonymous access
curl -k https://<node-ip>:10250/pods
2. Container Breakout
Once inside a container, the goal is often to escape to the host node.
Privileged Containers
Privileged containers have access to all devices on the host and bypass many security restrictions.
# Check if running as privileged
capsh --print
If you see cap_sys_admin, you are likely in a privileged container. You can mount the host filesystem and access sensitive files.
# Mount host root filesystem
mkdir /host
mount /dev/sda1 /host
chroot /host
Docker Socket Mounting
If the Docker socket (/var/run/docker.sock) is mounted inside the container, you can communicate with the Docker daemon to create new privileged containers or execute commands on the host.
# List containers using the mounted socket
curl --unix-socket /var/run/docker.sock http://localhost/containers/json