hacktricks/linux-hardening/privilege-escalation/docker-security

Segurança do Docker

Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

• Se você quer ver sua empresa anunciada no HackTricks ou baixar o HackTricks em PDF, confira os PLANOS DE ASSINATURA!
• Adquira o material oficial PEASS & HackTricks
• Descubra A Família PEASS, nossa coleção de NFTs exclusivos
• Junte-se ao grupo 💬 Discord ou ao grupo telegram ou siga-me no Twitter 🐦 @carlospolopm.
• Compartilhe suas técnicas de hacking enviando PRs para os repositórios github HackTricks e HackTricks Cloud.

Use Trickest para construir e automatizar fluxos de trabalho facilmente, com as ferramentas comunitárias mais avançadas do mundo.
Obtenha Acesso Hoje:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Segurança Básica do Motor Docker

O motor Docker realiza o trabalho pesado de executar e gerenciar Containers. O motor Docker utiliza recursos do kernel Linux como Namespaces e Cgroups para fornecer isolamento básico entre Containers. Ele também usa recursos como Capabilities dropping, Seccomp, SELinux/AppArmor para alcançar um isolamento melhor.

Por fim, um plugin de autenticação pode ser usado para limitar as ações que os usuários podem executar.

Acesso seguro ao motor Docker

O cliente Docker pode acessar o motor Docker localmente usando socket Unix ou remotamente usando http. Para usá-lo remotamente, é necessário utilizar https e TLS para garantir confidencialidade, integridade e autenticação.

Por padrão, escuta no socket Unix unix:///var/
run/docker.sock e nas distribuições Ubuntu, as opções de inicialização do Docker são especificadas em /etc/default/docker. Para permitir que a API do Docker e o cliente acessem o motor Docker remotamente, precisamos expor o daemon Docker usando socket http. Isso pode ser feito por:

DOCKER_OPTS="-D -H unix:///var/run/docker.sock -H
tcp://192.168.56.101:2376" -> add this to /etc/default/docker
Sudo service docker restart -> Restart Docker daemon

Expondo o daemon do Docker usando http não é uma boa prática e é necessário proteger a conexão usando https. Existem duas opções: a primeira opção é para o cliente verificar a identidade do servidor e na segunda opção tanto o cliente quanto o servidor verificam a identidade um do outro. Certificados estabelecem a identidade de um servidor. Para um exemplo de ambas as opções verifique esta página.

Segurança de imagem de contêiner

Imagens de contêineres são armazenadas ou em repositório privado ou público. A seguir estão as opções que o Docker oferece para armazenar imagens de contêineres:

• Docker hub – Este é um serviço de registro público fornecido pelo Docker
• Docker registry – Este é um projeto de código aberto que os usuários podem usar para hospedar seu próprio registro.
• Docker trusted registry – Esta é a implementação comercial do Docker registry pelo Docker e oferece autenticação de usuário baseada em funções juntamente com integração de serviço de diretório LDAP.

Varredura de Imagem

Contêineres podem ter vulnerabilidades de segurança tanto por causa da imagem base quanto por causa do software instalado em cima da imagem base. O Docker está trabalhando em um projeto chamado Nautilus que faz varredura de segurança de Contêineres e lista as vulnerabilidades. O Nautilus funciona comparando cada camada da imagem do Contêiner com o repositório de vulnerabilidades para identificar falhas de segurança.

Para mais informações leia isto.

• docker scan

O comando docker scan permite que você faça a varredura de imagens Docker existentes usando o nome ou ID da imagem. Por exemplo, execute o seguinte comando para fazer a varredura da imagem hello-world:

docker scan hello-world

Testing hello-world...

Organization:      docker-desktop-test
Package manager:   linux
Project name:      docker-image|hello-world
Docker image:      hello-world
Licenses:          enabled

✓ Tested 0 dependencies for known issues, no vulnerable paths found.

Note that we do not currently have vulnerability data for your image.

• trivy

trivy -q -f json <ontainer_name>:<tag>

• snyk

snyk container test <image> --json-file-output=<output file> --severity-threshold=high

• clair-scanner

clair-scanner -w example-alpine.yaml --ip YOUR_LOCAL_IP alpine:3.5

Assinatura de Imagem Docker

Imagens de Container Docker podem ser armazenadas em registro público ou privado. É necessário assinar imagens de Container para poder confirmar que as imagens não foram adulteradas. O publicador de conteúdo é responsável por assinar a imagem do Container e enviá-la para o registro.
A seguir estão alguns detalhes sobre a confiança de conteúdo Docker:

• A confiança de conteúdo Docker é uma implementação do projeto open source Notary. O projeto open source Notary é baseado no projeto The Update Framework (TUF).
• A confiança de conteúdo Docker é ativada com export DOCKER_CONTENT_TRUST=1. A partir da versão 1.10 do Docker, a confiança de conteúdo não é ativada por padrão.
• Quando a confiança de conteúdo está ativada, só podemos baixar imagens assinadas. Quando uma imagem é enviada, precisamos inserir a chave de etiquetagem.
• Quando o publicador envia a imagem pela primeira vez usando docker push, é necessário inserir uma frase-senha para a chave raiz e chave de etiquetagem. Outras chaves são geradas automaticamente.
• O Docker também adicionou suporte para chaves de hardware usando Yubikey e os detalhes estão disponíveis aqui.

A seguir está o erro que recebemos quando a confiança de conteúdo está ativada e a imagem não está assinada.

$ docker pull smakam/mybusybox
Using default tag: latest
No trust data for latest

A saída a seguir mostra a imagem do Container sendo enviada para o Docker hub com assinatura ativada. Como não é a primeira vez, solicita-se ao usuário que insira apenas a frase secreta para a chave do repositório.

$ docker push smakam/mybusybox:v2
The push refers to a repository [docker.io/smakam/mybusybox]
a7022f99b0cc: Layer already exists
5f70bf18a086: Layer already exists
9508eff2c687: Layer already exists
v2: digest: sha256:8509fa814029e1c1baf7696b36f0b273492b87f59554a33589e1bd6283557fc9 size: 2205
Signing and pushing trust metadata
Enter passphrase for repository key with ID 001986b (docker.io/smakam/mybusybox):

É necessário armazenar a chave de root, chave do repositório, bem como a frase secreta em um local seguro. O seguinte comando pode ser usado para fazer backup das chaves privadas:

tar -zcvf private_keys_backup.tar.gz ~/.docker/trust/private

Ao mudar o host do Docker, precisei mover as chaves raiz e as chaves do repositório para operar a partir do novo host.

---

Use Trickest para construir e automatizar fluxos de trabalho com o apoio das ferramentas comunitárias mais avançadas do mundo.
Obtenha Acesso Hoje:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Recursos de Segurança de Containers

Resumo dos Recursos de Segurança de Containers

Namespaces

Namespaces são úteis para isolar um projeto dos demais, isolando comunicações de processos, rede, montagens... É útil para isolar o processo do docker de outros processos (e até da pasta /proc) para que não possa escapar abusando de outros processos.

Poderia ser possível "escapar" ou mais exatamente criar novos namespaces usando o binário unshare (que usa a syscall unshare). O Docker por padrão previne isso, mas o kubernetes não (no momento desta escrita).
De qualquer forma, isso é útil para criar novos namespaces, mas não para voltar aos namespaces padrões do host (a menos que você tenha acesso a algum /proc dentro dos namespaces do host, onde você poderia usar nsenter para entrar nos namespaces do host.).

CGroups

Isso permite limitar recursos e não afeta a segurança do isolamento do processo (exceto pelo release_agent que poderia ser usado para escapar).

Capabilities Drop

Considero isso uma das características mais importantes em relação à segurança do isolamento de processos. Isso porque sem as capabilities, mesmo que o processo esteja rodando como root você não será capaz de realizar algumas ações privilegiadas (porque a syscall chamada syscall retornará erro de permissão porque o processo não possui as capabilities necessárias).

Estas são as capabilities remanescentes após o processo descartar as outras:

{% code overflow="wrap" %}

Current: 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

{% endcode %}

Seccomp

Está ativado por padrão no Docker. Ajuda a limitar ainda mais as syscalls que o processo pode chamar.
O perfil Seccomp padrão do Docker pode ser encontrado em https://github.com/moby/moby/blob/master/profiles/seccomp/default.json

AppArmor

O Docker possui um modelo que você pode ativar: https://github.com/moby/moby/tree/master/profiles/apparmor

Isso permitirá reduzir capacidades, syscalls, acesso a arquivos e pastas...

Namespaces

Namespaces são um recurso do kernel Linux que particiona recursos do kernel de forma que um conjunto de processos veja um conjunto de recursos enquanto outro conjunto de processos vê um conjunto diferente de recursos. O recurso funciona tendo o mesmo namespace para um conjunto de recursos e processos, mas esses namespaces se referem a recursos distintos. Recursos podem existir em múltiplos espaços.

O Docker utiliza os seguintes Namespaces do kernel Linux para alcançar o isolamento de Containers:

• pid namespace
• mount namespace
• network namespace
• ipc namespace
• UTS namespace

Para mais informações sobre os namespaces, consulte a seguinte página:

{% content-ref url="namespaces/" %} namespaces {% endcontent-ref %}

cgroups

O recurso do kernel Linux cgroups fornece a capacidade de restringir recursos como cpu, memória, io, largura de banda de rede entre um conjunto de processos. O Docker permite criar Containers usando o recurso cgroup, o que permite o controle de recursos para o Container específico.
A seguir, um Container criado com memória do espaço do usuário limitada a 500m, memória do kernel limitada a 50m, compartilhamento de cpu para 512, blkioweight para 400. O compartilhamento de CPU é uma proporção que controla o uso de CPU do Container. Tem um valor padrão de 1024 e varia entre 0 e 1024. Se três Containers têm o mesmo compartilhamento de CPU de 1024, cada Container pode usar até 33% da CPU em caso de contenção de recurso de CPU. blkio-weight é uma proporção que controla o IO do Container. Tem um valor padrão de 500 e varia entre 10 e 1000.

docker run -it -m 500M --kernel-memory 50M --cpu-shares 512 --blkio-weight 400 --name ubuntu1 ubuntu bash

Para obter o cgroup de um container, você pode fazer:

docker run -dt --rm denial sleep 1234 #Run a large sleep inside a Debian container
ps -ef | grep 1234 #Get info about the sleep process
ls -l /proc/<PID>/ns #Get the Group and the namespaces (some may be uniq to the hosts and some may be shred with it)

Para mais informações, verifique:

{% content-ref url="cgroups.md" %} cgroups.md {% endcontent-ref %}

Capacidades

Capacidades permitem um controle mais refinado das capacidades que podem ser permitidas para o usuário root. O Docker utiliza o recurso de capacidades do kernel Linux para limitar as operações que podem ser feitas dentro de um Container, independentemente do tipo de usuário.

Quando um container Docker é executado, o processo descarta capacidades sensíveis que o processo poderia usar para escapar do isolamento. Isso tenta garantir que o processo não será capaz de realizar ações sensíveis e escapar:

{% content-ref url="../linux-capabilities.md" %} linux-capabilities.md {% endcontent-ref %}

Seccomp no Docker

Este é um recurso de segurança que permite ao Docker limitar as chamadas de sistema que podem ser usadas dentro do container:

{% content-ref url="seccomp.md" %} seccomp.md {% endcontent-ref %}

AppArmor no Docker

AppArmor é um aprimoramento do kernel para confinar containers a um conjunto limitado de recursos com perfis por programa:

{% content-ref url="apparmor.md" %} apparmor.md {% endcontent-ref %}

SELinux no Docker

SELinux é um sistema de rotulagem. Todo processo e cada objeto do sistema de arquivos tem um rótulo. As políticas do SELinux definem regras sobre o que um rótulo de processo é permitido fazer com todos os outros rótulos no sistema.

Os mecanismos de containers iniciam processos de containers com um único rótulo confinado do SELinux, geralmente container_t, e então configuram o interior do container para ser rotulado como container_file_t. As regras da política do SELinux basicamente dizem que os processos container_t só podem ler/escrever/executar arquivos rotulados como container_file_t.

{% content-ref url="../selinux.md" %} selinux.md {% endcontent-ref %}

AuthZ & AuthN

Um plugin de autorização aprova ou nega solicitações ao daemon do Docker com base tanto no contexto de autenticação atual quanto no contexto do comando. O contexto de autenticação contém todos os detalhes do usuário e o método de autenticação. O contexto do comando contém todos os dados relevantes da solicitação.

{% content-ref url="authz-and-authn-docker-access-authorization-plugin.md" %} authz-and-authn-docker-access-authorization-plugin.md {% endcontent-ref %}

DoS a partir de um container

Se você não está limitando adequadamente os recursos que um container pode usar, um container comprometido poderia realizar um DoS no host onde está sendo executado.

• CPU DoS

# stress-ng
sudo apt-get install -y stress-ng && stress-ng --vm 1 --vm-bytes 1G --verify -t 5m

# While loop
docker run -d --name malicious-container -c 512 busybox sh -c 'while true; do :; done'

• Ataque de negação de serviço por largura de banda (Bandwidth DoS)

nc -lvp 4444 >/dev/null & while true; do cat /dev/urandom | nc <target IP> 4444; done

Flags Interessantes do Docker

flag --privileged

Na página a seguir, você pode aprender o que a flag --privileged implica:

{% content-ref url="docker-privileged.md" %} docker-privileged.md {% endcontent-ref %}

--security-opt

no-new-privileges

Se você estiver executando um container onde um atacante consegue acessar como um usuário de baixo privilégio. Se você tiver um binário suid mal configurado, o atacante pode abusar dele e escalar privilégios dentro do container. O que pode permitir que ele escape dele.

Executar o container com a opção no-new-privileges ativada irá prevenir esse tipo de escalada de privilégios.

docker run -it --security-opt=no-new-privileges:true nonewpriv

Outros

#You can manually add/drop capabilities with
--cap-add
--cap-drop

# You can manually disable seccomp in docker with
--security-opt seccomp=unconfined

# You can manually disable seccomp in docker with
--security-opt apparmor=unconfined

# You can manually disable selinux in docker with
--security-opt label:disable

Para mais opções de --security-opt, consulte: https://docs.docker.com/engine/reference/run/#security-configuration

Outras Considerações de Segurança

Gerenciamento de Segredos

Primeiro de tudo, não os coloque dentro da sua imagem!

Além disso, não use variáveis de ambiente para suas informações sensíveis. Qualquer pessoa que possa executar docker inspect ou exec no container pode encontrar seu segredo.

Volumes do Docker são melhores. Eles são a maneira recomendada de acessar suas informações sensíveis na documentação do Docker. Você pode usar um volume como um sistema de arquivos temporário mantido na memória. Volumes removem o risco de docker inspect e de registro em logs. No entanto, usuários root ainda podem ver o segredo, assim como qualquer um que possa executar exec no container.

Melhor ainda que volumes, use Docker secrets.

Se você precisa do segredo na sua imagem, você pode usar BuildKit. BuildKit reduz significativamente o tempo de construção e tem outras características interessantes, incluindo suporte a segredos durante o tempo de construção.

Existem três maneiras de especificar o backend do BuildKit para que você possa usar suas funcionalidades agora:

1. Defina como uma variável de ambiente com export DOCKER_BUILDKIT=1.
2. Inicie seu comando build ou run com DOCKER_BUILDKIT=1.
3. Habilite o BuildKit por padrão. Configure a configuração em /etc/docker/daemon.json para true com: { "features": { "buildkit": true } }. Depois, reinicie o Docker.
4. Então você pode usar segredos durante o tempo de construção com a flag --secret assim:

docker build --secret my_key=my_value ,src=path/to/my_secret_file .

Onde seu arquivo especifica seus segredos como par chave-valor.

Esses segredos são excluídos do cache de construção da imagem e da imagem final.

Se você precisa do seu segredo no seu contêiner em execução, e não apenas durante a construção da sua imagem, use Docker Compose ou Kubernetes.

Com o Docker Compose, adicione o par chave-valor dos segredos a um serviço e especifique o arquivo de segredo. Dica do Stack Exchange answer para a dica de segredos do Docker Compose que o exemplo abaixo é adaptado.

Exemplo de docker-compose.yml com segredos:

version: "3.7"

services:

my_service:
image: centos:7
entrypoint: "cat /run/secrets/my_secret"
secrets:
- my_secret

secrets:
my_secret:
file: ./my_secret_file.txt

Então inicie o Compose como de costume com docker-compose up --build my_service.

Se você está usando Kubernetes, ele tem suporte para segredos. Helm-Secrets pode ajudar a tornar o gerenciamento de segredos no K8s mais fácil. Além disso, o K8s tem Controles de Acesso Baseados em Funções (RBAC) — assim como o Docker Enterprise. RBAC torna o gerenciamento de Segredos mais gerenciável e mais seguro para equipes.

gVisor

gVisor é um kernel de aplicação, escrito em Go, que implementa uma parte substancial da superfície do sistema Linux. Inclui um runtime da Open Container Initiative (OCI) chamado runsc que fornece uma fronteira de isolamento entre a aplicação e o kernel do host. O runtime runsc integra-se com Docker e Kubernetes, facilitando a execução de contêineres em sandbox.

{% embed url="https://github.com/google/gvisor" %}

Kata Containers

Kata Containers é uma comunidade de código aberto trabalhando para construir um runtime de contêiner seguro com máquinas virtuais leves que se comportam e têm desempenho como contêineres, mas fornecem isolamento de carga de trabalho mais forte usando tecnologia de virtualização de hardware como uma segunda camada de defesa.

{% embed url="https://katacontainers.io/" %}

Dicas Resumidas

• Não use a flag --privileged ou monte um socket do Docker dentro do contêiner. O socket do Docker permite a criação de contêineres, então é uma maneira fácil de assumir o controle total do host, por exemplo, executando outro contêiner com a flag --privileged.
• Não execute como root dentro do contêiner. Use um usuário diferente e namespaces de usuário. O root no contêiner é o mesmo que no host, a menos que seja remapeado com namespaces de usuário. Ele é apenas levemente restrito, principalmente, por namespaces do Linux, capacidades e cgroups.
• Remova todas as capacidades (--cap-drop=all) e habilite apenas aquelas que são necessárias (--cap-add=...). Muitas cargas de trabalho não precisam de nenhuma capacidade e adicioná-las aumenta o escopo de um ataque potencial.
• Use a opção de segurança “no-new-privileges” para impedir que processos ganhem mais privilégios, por exemplo, através de binários suid.
• Limite os recursos disponíveis para o contêiner. Limites de recursos podem proteger a máquina contra ataques de negação de serviço.
• Ajuste perfis de seccomp, AppArmor (ou SELinux) para restringir as ações e syscalls disponíveis para o contêiner ao mínimo necessário.
• Use imagens oficiais do docker e exija assinaturas ou construa as suas próprias baseadas nelas. Não herde ou use imagens comprometidas. Além disso, armazene chaves raiz, frases de acesso em um local seguro. O Docker tem planos para gerenciar chaves com UCP.
• Reconstrua regularmente suas imagens para aplicar patches de segurança ao host e imagens.
• Gerencie seus segredos com sabedoria para que seja difícil para o atacante acessá-los.
• Se você expõe o daemon do docker, use HTTPS com autenticação de cliente e servidor.
• No seu Dockerfile, prefira COPY em vez de ADD. ADD extrai automaticamente arquivos compactados e pode copiar arquivos de URLs. COPY não tem essas capacidades. Sempre que possível, evite usar ADD para não estar suscetível a ataques através de URLs remotas e arquivos Zip.
• Tenha contêineres separados para cada micro-serviço
• Não coloque ssh dentro do contêiner, "docker exec" pode ser usado para acessar o Contêiner via ssh.
• Tenha imagens de contêiner menores

Docker Breakout / Escalada de Privilégios

Se você está dentro de um contêiner docker ou tem acesso a um usuário no grupo docker, você pode tentar escapar e escalar privilégios:

{% content-ref url="docker-breakout-privilege-escalation/" %} docker-breakout-privilege-escalation {% endcontent-ref %}

Bypass de Plugin de Autenticação Docker

Se você tem acesso ao socket do docker ou tem acesso a um usuário no grupo docker, mas suas ações estão sendo limitadas por um plugin de autenticação docker, verifique se você pode burlá-lo:

{% content-ref url="authz-and-authn-docker-access-authorization-plugin.md" %} authz-and-authn-docker-access-authorization-plugin.md {% endcontent-ref %}

Fortalecimento do Docker

• A ferramenta docker-bench-security é um script que verifica dezenas de práticas recomendadas comuns ao implantar contêineres Docker em produção. Os testes são todos automatizados e baseiam-se no CIS Docker Benchmark v1.3.1.
  Você precisa executar a ferramenta a partir do host que executa o docker ou de um contêiner com privilégios suficientes. Descubra como executá-lo no README: https://github.com/docker/docker-bench-security.

Referências

• https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/
• https://twitter.com/_fel1x/status/1151487051986087936
• https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html
• https://sreeninet.wordpress.com/2016/03/06/docker-security-part-1overview/
• https://sreeninet.wordpress.com/2016/03/06/docker-security-part-2docker-engine/
• https://sreeninet.wordpress.com/2016/03/06/docker-security-part-3engine-access/
• https://sreeninet.wordpress.com/2016/03/06/docker-security-part-4container-image/
• https://en.wikipedia.org/wiki/Linux_namespaces
• https://towardsdatascience.com/top-20-docker-security-tips-81c41dd06f57

Use Trickest para construir e automatizar fluxos de trabalho com as ferramentas comunitárias mais avançadas do mundo.
Obtenha Acesso Hoje:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

• Se você quer ver sua empresa anunciada no HackTricks ou baixar o HackTricks em PDF Confira os PLANOS DE ASSINATURA!
• Adquira o merchandising oficial do PEASS & HackTricks
• Descubra A Família PEASS, nossa coleção de NFTs exclusivos
• Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-me no Twitter 🐦 @carlospolopm.
• Compartilhe suas dicas de hacking enviando PRs para os repositórios do GitHub HackTricks e HackTricks Cloud.