Docker Breakout / Privilege Escalation
Aprenda e pratique Hacking na AWS:Treinamento HackTricks AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking no GCP:
Treinamento HackTricks GCP Red Team Expert (GRTE)
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F910640767-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjzQiXe8oFAkPoN0MXcUG%252Fuploads%252Fgit-blob-78abb7891633b1e8147b4e743e4f00af375d3cd6%252Fimage%2520%2848%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=5de16767&sv=1)
Use Trickest para construir facilmente e automatizar fluxos de trabalho com as ferramentas comunitárias mais avançadas do mundo. Tenha Acesso Hoje:
Enumeração e Fuga Automáticas
linpeas: Também pode enumerar containers
CDK: Esta ferramenta é bastante útil para enumerar o container em que você está e tentar escapar automaticamente
amicontained: Ferramenta útil para obter os privilégios que o container possui a fim de encontrar maneiras de escapar dele
deepce: Ferramenta para enumerar e escapar de containers
grype: Obtenha as CVEs contidas no software instalado na imagem
Fuga do Socket Docker Montado
Se de alguma forma você descobrir que o socket do docker está montado dentro do container do docker, você será capaz de escapar dele. Isso geralmente acontece em containers do docker que, por algum motivo, precisam se conectar ao daemon do docker para realizar ações.
Neste caso, você pode usar comandos regulares do docker para se comunicar com o daemon do docker:
Caso o socket do docker esteja em um local inesperado, ainda é possível se comunicar com ele usando o comando docker
com o parâmetro -H unix:///caminho/para/docker.sock
O daemon do Docker também pode estar ouvindo em uma porta (por padrão 2375, 2376) ou em sistemas baseados em Systemd, a comunicação com o daemon do Docker pode ocorrer sobre o socket do Systemd fd://
.
Além disso, preste atenção nos sockets de tempo de execução de outras 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
...
Fuga de Abuso de Capacidades
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 as ferramentas automáticas mencionadas anteriormente ou:
Na seguinte página você pode aprender mais sobre as capacidades do Linux e como abusar delas para escapar/elevar privilégios:
Linux CapabilitiesEscapando de Containers Privilegiados
Um container 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
Montar /dev
A flag --privileged
reduz significativamente a segurança do container, oferecendo acesso irrestrito a dispositivos e contornando diversas proteções. Para uma análise detalhada, consulte a documentação sobre os impactos completos de --privileged
.
Privileged + hostPID
Com essas permissões, você pode simplesmente mover-se para o namespace de um processo em execução no host como root como o init (pid:1) apenas executando: nsenter --target 1 --mount --uts --ipc --net --pid -- bash
Teste em um container executando:
Privilegiado
Apenas com a flag privilegiada você pode tentar acessar o disco do host ou tentar escapar abusando do release_agent ou de outras formas de escape.
Teste os seguintes bypasses em um contêiner executando:
Montagem de Disco - Poc1
Contêineres Docker bem configurados não permitirão comandos como fdisk -l. No entanto, em um comando Docker mal configurado onde a flag --privileged
ou --device=/dev/sda1
com caps é especificada, é possível obter privilégios para visualizar a unidade do host.
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fbestestredteam.com%2Fcontent%2Fimages%2F2019%2F08%2Fimage-16.png&width=768&dpr=4&quality=100&sign=45b35987&sv=1)
Portanto, para assumir o controle da máquina host, é trivial:
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 mais acesso ao sistema operacional host subjacente 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 pode aproveitar esse vetor de ataque:
Fuga de Privilégios Abusando do release_agent existente (cve-2022-0492) - PoC1
Fuga de privilégios abusando do release_agent criado (cve-2022-0492) - PoC2
Encontre uma explicação da técnica em:
Docker release_agent cgroups escapeFuga de Privilégios Abusando do 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, nem sempre é o caso. Em situações em que você não conhece o caminho absoluto do contêiner dentro do host, você pode usar esta técnica:
release_agent exploit - Relative Paths to PIDsExecutar o PoC dentro de um contêiner privilegiado deve fornecer uma saída semelhante a:
Fuga de Privilégios Abusando de Montagens Sensíveis
Existem vários arquivos que podem ser montados e 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á a um atacante escapar do contêiner). A exploração desses arquivos pode permitir que:
release_agent (já abordado anteriormente)
No entanto, você pode encontrar outros arquivos sensíveis para verificar nesta página:
Sensitive MountsMontagens Arbitrárias
Em várias ocasiões, você descobrirá que o contêiner possui algum volume montado do host. Se este volume não estiver configurado corretamente, você pode ser capaz de acessar/modificar dados sensíveis: Ler segredos, alterar chaves autorizadas do ssh...
Escalação de Privilégios com 2 shells e montagem de host
Se você tem 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.
Escalação de Privilégios com 2 shells
Se você tem acesso como root dentro de um container e conseguiu escapar como um usuário não privilegiado para o host, você pode abusar de ambos os shells para escalar privilégios dentro do host se tiver a capacidade MKNOD dentro do container (por padrão) conforme explicado neste post. Com essa capacidade, o usuário root dentro do container tem permissão para criar arquivos de dispositivo de bloco. Arquivos de dispositivo são arquivos especiais 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 containers aplicando uma política cgroup que bloqueia operações de leitura/gravação de dispositivos de bloco. No entanto, se um dispositivo de bloco for criado dentro do container, ele se torna acessível de fora do container através do diretório /proc/PID/root/. Esse acesso requer que o dono do processo seja o mesmo tanto dentro quanto fora do container.
Exemplo de exploração deste artigo:
hostPID
Se você pode acessar os processos do host, você será capaz de acessar muitas informações sensíveis armazenadas nesses processos. Execute o laboratório de teste:
Por exemplo, você poderá listar os processos usando algo como ps auxn
e procurar por detalhes sensíveis nos comandos.
Depois, como você pode acessar cada processo do host em /proc/, você pode simplesmente roubar seus segredos de ambiente executando:
Você também pode acessar os descritores de arquivos de outros processos e ler os arquivos abertos por eles:
Você também pode encerrar processos e causar um DoS.
Se você de alguma forma tiver acesso privilegiado a um processo fora do contêiner, você poderia executar algo como nsenter --target <pid> --all
ou nsenter --target <pid> --mount --net --pid --cgroup
para executar um shell com as mesmas restrições ns (esperançosamente nenhuma) daquele processo.
hostNetwork
Se um contêiner foi configurado com o driver de rede do Docker host (--network=host
), a pilha de rede desse contêiner não está isolada do host do 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é falsificar o tráfego entre o host e a instância de metadados.
Como nos exemplos a seguir:
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 daquelas que um contêiner pode acessar).
hostIPC
Com hostIPC=true
, você ganha acesso aos recursos de comunicação interprocessual (IPC) do host, como memória compartilhada em /dev/shm
. Isso permite a leitura/escrita onde os mesmos recursos de IPC são usados por outros processos do host ou do pod. Use ipcs
para inspecionar esses mecanismos de IPC.
Inspecionar /dev/shm - Procure por arquivos neste local de memória compartilhada:
ls -la /dev/shm
Inspecionar instalações de IPC existentes - Você pode verificar se alguma instalação de IPC está sendo usada com
/usr/bin/ipcs
. Verifique com:ipcs -a
Recuperar capacidades
Se a chamada de sistema unshare
não estiver proibida, você pode recuperar todas as capacidades executando:
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/ indica como você pode abusar de bind mounts com namespaces de usuário, para afetar arquivos dentro do host (naquele caso específico, excluir arquivos).
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F910640767-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjzQiXe8oFAkPoN0MXcUG%252Fuploads%252Fgit-blob-78abb7891633b1e8147b4e743e4f00af375d3cd6%252Fimage%2520%2848%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=5de16767&sv=1)
Use Trickest para construir facilmente e automatizar fluxos de trabalho com as ferramentas comunitárias mais avançadas do mundo. Tenha acesso hoje:
CVEs
Exploração do Runc (CVE-2019-5736)
Caso você consiga executar docker exec
como root (provavelmente com sudo), você pode tentar escalar privilégios escapando de um contêiner abusando do CVE-2019-5736 (exploit aqui). Essa técnica basicamente sobrescreverá o binário /bin/sh do host a partir de um contêiner, então qualquer pessoa que execute docker exec pode acionar o payload.
Altere o payload conforme necessário e compile 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 [+] Sobrescrito /bin/sh com sucesso
, você precisa executar o seguinte da máquina host:
docker exec -it <nome-do-contêiner> /bin/sh
Isso acionará o payload presente no arquivo main.go.
Para mais informações: https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html
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
Fuga Personalizada do Docker
Superfície de Fuga do Docker
Namespaces: O processo deve estar completamente separado de outros processos por meio de namespaces, para que não possamos escapar interagindo com outros processos devido a namespaces (por padrão, não pode se comunicar via IPCs, soquetes unix, serviços de rede, D-Bus,
/proc
de outros processos).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: Estes são os syscalls que o usuário root não poderá chamar (por falta de capacidades + Seccomp). Os outros syscalls poderiam ser usados para tentar escapar.
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://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F910640767-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjzQiXe8oFAkPoN0MXcUG%252Fuploads%252Fgit-blob-78abb7891633b1e8147b4e743e4f00af375d3cd6%252Fimage%2520%2848%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=5de16767&sv=1)
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated