Docker Breakout / Privilege Escalation
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Automatic Enumeration & Escape
linpeas: It can also enumerate containers
CDK: This tool is pretty useful to enumerate the container you are into even try to escape automatically
amicontained: Useful tool to get the privileges the container has in order to find ways to escape from it
deepce: Tool to enumerate and escape from containers
grype: Get the CVEs contained in the software installed in the image
Mounted Docker Socket Escape
If somehow you find that the docker socket is mounted inside the docker container, you will be able to escape from it. This usually happen in docker containers that for some reason need to connect to docker daemon to perform actions.
In this case you can use regular docker commands to communicate with the docker daemon:
In case the docker socket is in an unexpected place you can still communicate with it using the docker
command with the parameter -H unix:///path/to/docker.sock
Docker daemon might be also listening in a port (by default 2375, 2376) or on Systemd-based systems, communication with the Docker daemon can occur over the Systemd socket fd://
.
Additionally, pay attention to the runtime sockets of other high-level runtimes:
dockershim:
unix:///var/run/dockershim.sock
containerd:
unix:///run/containerd/containerd.sock
cri-o:
unix:///var/run/crio/crio.sock
frakti:
unix:///var/run/frakti.sock
rktlet:
unix:///var/run/rktlet.sock
...
Capabilities Abuse Escape
You should check the capabilities of the container, if it has any of the following ones, you might be able to scape from it: CAP_SYS_ADMIN
, CAP_SYS_PTRACE
, CAP_SYS_MODULE
, DAC_READ_SEARCH
, DAC_OVERRIDE, CAP_SYS_RAWIO
, CAP_SYSLOG
, CAP_NET_RAW
, CAP_NET_ADMIN
You can check currently container capabilities using previously mentioned automatic tools or:
In the following page you can learn more about linux capabilities and how to abuse them to escape/escalate privileges:
Escape from Privileged Containers
A privileged container can be created with the flag --privileged
or disabling specific defenses:
--cap-add=ALL
--security-opt apparmor=unconfined
--security-opt seccomp=unconfined
--security-opt label:disable
--pid=host
--userns=host
--uts=host
--cgroupns=host
Mount /dev
The --privileged
flag significantly lowers container security, offering unrestricted device access and bypassing several protections. For a detailed breakdown, refer to the documentation on --privileged
's full impacts.
Privileged + hostPID
With these permissions you can just move to the namespace of a process running in the host as root like init (pid:1) just running: nsenter --target 1 --mount --uts --ipc --net --pid -- bash
Test it in a container executing:
Privileged
Just with the privileged flag you can try to access the host's disk or try to escape abusing release_agent or other escapes.
Test the following bypasses in a container executing:
Mounting Disk - Poc1
Well configured docker containers won't allow command like fdisk -l. However on miss-configured docker command where the flag --privileged
or --device=/dev/sda1
with caps is specified, it is possible to get the privileges to see the host drive.
So to take over the host machine, it is trivial:
And voilà ! You can now access the filesystem of the host because it is mounted in the /mnt/hola
folder.
Mounting Disk - Poc2
Within the container, an attacker may attempt to gain further access to the underlying host OS via a writable hostPath volume created by the cluster. Below is some common things you can check within the container to see if you leverage this attacker vector:
Privileged Escape Abusing existent release_agent (cve-2022-0492) - PoC1
Privileged Escape Abusing created release_agent (cve-2022-0492) - PoC2
Find an explanation of the technique in:
Privileged Escape Abusing release_agent without known the relative path - PoC3
In the previous exploits the absolute path of the container inside the hosts filesystem is disclosed. However, this isn’t always the case. In cases where you don’t know the absolute path of the container inside the host you can use this technique:
Executing the PoC within a privileged container should provide output similar to:
Privileged Escape Abusing Sensitive Mounts
There are several files that might mounted that give information about the underlaying host. Some of them may even indicate something to be executed by the host when something happens (which will allow a attacker to escape from the container). The abuse of these files may allow that:
release_agent (already covered before)
However, you can find other sensitive files to check for in this page:
Arbitrary Mounts
In several occasions you will find that the container has some volume mounted from the host. If this volume wasn’t correctly configured you might be able to access/modify sensitive data: Read secrets, change ssh authorized_keys…
Privilege Escalation with 2 shells and host mount
If you have access as root inside a container that has some folder from the host mounted and you have escaped as a non privileged user to the host and have read access over the mounted folder. You can create a bash suid file in the mounted folder inside the container and execute it from the host to privesc.
Privilege Escalation with 2 shells
If you have access as root inside a container and you have escaped as a non privileged user to the host, you can abuse both shells to privesc inside the host if you have the capability MKNOD inside the container (it's by default) as explained in this post. With such capability the root user within the container is allowed to create block device files. Device files are special files that are used to access underlying hardware & kernel modules. For example, the /dev/sda block device file gives access to read the raw data on the systems disk.
Docker safeguards against block device misuse within containers by enforcing a cgroup policy that blocks block device read/write operations. Nevertheless, if a block device is created inside the container, it becomes accessible from outside the container via the /proc/PID/root/ directory. This access requires the process owner to be the same both inside and outside the container.
Exploitation example from this writeup:
hostPID
If you can access the processes of the host you are going to be able to access a lot of sensitive information stored in those processes. Run test lab:
For example, you will be able to list the processes using something like ps auxn
and search for sensitive details in the commands.
Then, as you can access each process of the host in /proc/ you can just steal their env secrets running:
You can also access other processes file descriptors and read their open files:
You can also kill processes and cause a DoS.
If you somehow have privileged access over a process outside of the container, you could run something like nsenter --target <pid> --all
or nsenter --target <pid> --mount --net --pid --cgroup
to run a shell with the same ns restrictions (hopefully none) as that process.
hostNetwork
If a container was configured with the Docker host networking driver (--network=host
), that container's network stack is not isolated from the Docker host (the container shares the host's networking namespace), and the container does not get its own IP-address allocated. In other words, the container binds all services directly to the host's IP. Furthermore the container can intercept ALL network traffic that the host is sending and receiving on shared interface tcpdump -i eth0
.
For instance, you can use this to sniff and even spoof traffic between host and metadata instance.
Like in the following examples:
You will be able also to access network services binded to localhost inside the host or even access the metadata permissions of the node (which might be different those a container can access).
hostIPC
With hostIPC=true
, you gain access to the host's inter-process communication (IPC) resources, such as shared memory in /dev/shm
. This allows reading/writing where the same IPC resources are used by other host or pod processes. Use ipcs
to inspect these IPC mechanisms further.
Inspect /dev/shm - Look for any files in this shared memory location:
ls -la /dev/shm
Inspect existing IPC facilities – You can check to see if any IPC facilities are being used with
/usr/bin/ipcs
. Check it with:ipcs -a
Recover capabilities
If the syscall unshare
is not forbidden you can recover all the capabilities running:
User namespace abuse via symlink
The second technique explained in the post https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/ indicates how you can abuse bind mounts with user namespaces, to affect files inside the host (in that specific case, delete files).
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
CVEs
Runc exploit (CVE-2019-5736)
In case you can execute docker exec
as root (probably with sudo), you try to escalate privileges escaping from a container abusing CVE-2019-5736 (exploit here). This technique will basically overwrite the /bin/sh binary of the host from a container, so anyone executing docker exec may trigger the payload.
Change the payload accordingly and build the main.go with go build main.go
. The resulting binary should be placed in the docker container for execution.
Upon execution, as soon as it displays [+] Overwritten /bin/sh successfully
you need to execute the following from the host machine:
docker exec -it <container-name> /bin/sh
This will trigger the payload which is present in the main.go file.
For more information: https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html
There are other CVEs the container can be vulnerable too, you can find a list in https://0xn3va.gitbook.io/cheat-sheets/container/escaping/cve-list
Docker Custom Escape
Docker Escape Surface
Namespaces: The process should be completely separated from other processes via namespaces, so we cannot escape interacting with other procs due to namespaces (by default cannot communicate via IPCs, unix sockets, network svcs, D-Bus,
/proc
of other procs).Root user: By default the user running the process is the root user (however its privileges are limited).
Capabilities: Docker leaves the following capabilities:
cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep
Syscalls: These are the syscalls that the root user won't be able to call (because of lacking capabilities + Seccomp). The other syscalls could be used to try to escape.
Container Breakout through Usermode helper Template
If you are in userspace (no kernel exploit involved) the way to find new escapes mainly involve the following actions (these templates usually require a container in privileged mode):
Find the path of the containers filesystem inside the host
You can do this via mount, or via brute-force PIDs as explained in the second release_agent exploit
Find some functionality where you can indicate the path of a script to be executed by a host process (helper) if something happens
You should be able to execute the trigger from inside the host
You need to know where the containers files are located inside the host to indicate a script you write inside the host
Have enough capabilities and disabled protections to be able to abuse that functionality
You might need to mount things o perform special privileged actions you cannot do in a default docker container
References
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Last updated