EXPLOIT_HOST_READ
Source | Destination | MITRE |
---|---|---|
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.
Details
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.
Prerequisites
Execution within a container with a sensitive host path mounted as readonly.
See the example pod spec.
Checks
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)
Exploitation
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:
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):
Finally extract any SSH keys offline from memory using the ssh-grab python script.
Monitoring
- Monitor for access to sensitive host files (e.g SSH keys) originating from container processes
Implement security policies
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.
Least Privilege
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.