|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:
/procfor 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:
Once the target PID has been retrieved, dump the process memory by reading
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.
- 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.
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