mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-15 09:01:01 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/
This commit is contained in:
Translator
@@ -60,10 +60,10 @@ aws codebuild start-build-batch --project <project-name> --buildspec-override fi
|
||||
|
||||
**Nota**: A diferença entre esses dois comandos é que:
|
||||
|
||||
- `StartBuild` aciona um único trabalho de construção usando um `buildspec.yml` específico.
|
||||
- `StartBuildBatch` permite que você inicie um lote de construções, com configurações mais complexas (como executar várias construções em paralelo).
|
||||
- `StartBuild` aciona um único trabalho de build usando um `buildspec.yml` específico.
|
||||
- `StartBuildBatch` permite que você inicie um lote de builds, com configurações mais complexas (como executar vários builds em paralelo).
|
||||
|
||||
**Impacto Potencial:** Privesc direto para funções do AWS Codebuild anexadas.
|
||||
**Impacto Potencial:** Privesc direto para funções AWS Codebuild anexadas.
|
||||
|
||||
### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
|
||||
|
||||
@@ -298,7 +298,7 @@ aws codebuild start-build-batch --project-name codebuild-demo-project
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impacto Potencial:** Privesc direto para funções do AWS Codebuild anexadas.
|
||||
**Impacto Potencial:** Privesc direto para funções AWS Codebuild anexadas.
|
||||
|
||||
### SSM
|
||||
|
||||
@@ -309,7 +309,7 @@ O projeto codebuild precisará ter um ponto de interrupção:
|
||||
<pre class="language-yaml"><code class="lang-yaml">phases:
|
||||
pre_build:
|
||||
commands:
|
||||
- echo Entered the pre_build phase...
|
||||
- echo Entrou na fase pre_build...
|
||||
- echo "Hello World" > /tmp/hello-world
|
||||
<strong> - codebuild-breakpoint
|
||||
</strong></code></pre>
|
||||
|
||||
@@ -80,7 +80,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
|
||||
|
||||
Assim como no exemplo anterior, um atacante que abuse das permissões **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** no ECS pode **gerar uma nova definição de tarefa** com um **container malicioso** que rouba as credenciais de metadados e **executá-lo**.\
|
||||
No entanto, neste caso, uma instância de container para executar a definição de tarefa maliciosa precisa ser.
|
||||
No entanto, neste caso, uma instância de container para executar a definição de tarefa maliciosa precisa estar.
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -140,7 +140,7 @@ aws ecs run-task \
|
||||
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Este cenário é como os anteriores, mas **sem** a permissão **`iam:PassRole`**.\
|
||||
Isso ainda é interessante porque se você puder executar um contêiner arbitrário, mesmo que seja sem uma função, você poderia **executar um contêiner privilegiado para escapar** para o nó e **roubar a função IAM do EC2** e as **outras funções de contêineres ECS** em execução no nó.\
|
||||
Isso ainda é interessante porque, se você puder executar um contêiner arbitrário, mesmo que sem uma função, você poderia **executar um contêiner privilegiado para escapar** para o nó e **roubar a função IAM do EC2** e as **outras funções dos contêineres ECS** em execução no nó.\
|
||||
Você poderia até **forçar outras tarefas a serem executadas dentro da instância EC2** que você comprometeu para roubar suas credenciais (como discutido na [**seção Privesc para nó**](aws-ecs-privesc.md#privesc-to-node)).
|
||||
|
||||
> [!WARNING]
|
||||
@@ -187,7 +187,7 @@ aws ecs run-task --task-definition iam_exfiltration \
|
||||
```
|
||||
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Um atacante com as permissões **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** pode **executar comandos** dentro de um contêiner em execução e exfiltrar a função IAM anexada a ele (você precisa das permissões de descrição porque é necessário executar `aws ecs execute-command`).\
|
||||
Um atacante com o **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** pode **executar comandos** dentro de um contêiner em execução e exfiltrar a função IAM anexada a ele (você precisa das permissões de descrição porque é necessário executar `aws ecs execute-command`).\
|
||||
No entanto, para fazer isso, a instância do contêiner precisa estar executando o **ExecuteCommand agent** (que por padrão não está).
|
||||
|
||||
Portanto, o atacante pode tentar:
|
||||
|
||||
@@ -16,7 +16,7 @@ Um atacante poderia enviar mensagens maliciosas ou indesejadas para o tópico SN
|
||||
```bash
|
||||
aws sns publish --topic-arn <value> --message <value>
|
||||
```
|
||||
**Impacto Potencial**: Exploração de vulnerabilidades, Corrupção de dados, ações não intencionais ou exaustão de recursos.
|
||||
**Impacto Potencial**: Exploração de vulnerabilidades, corrupção de dados, ações não intencionais ou exaustão de recursos.
|
||||
|
||||
### `sns:Subscribe`
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Step Functions
|
||||
|
||||
Para mais informações sobre este serviço AWS, verifique:
|
||||
Para mais informações sobre este serviço AWS, consulte:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-stepfunctions-enum.md
|
||||
@@ -25,7 +25,7 @@ Ou você também pode ir à documentação da API AWS e verificar a documentaç
|
||||
|
||||
### `states:TestState` & `iam:PassRole`
|
||||
|
||||
Um atacante com as permissões **`states:TestState`** & **`iam:PassRole`** pode testar qualquer estado e passar qualquer função IAM para ele sem criar ou atualizar uma máquina de estado existente, potencialmente permitindo acesso não autorizado a outros serviços AWS com as permissões da função. Combinadas, essas permissões podem levar a ações não autorizadas extensas, desde manipulação de fluxos de trabalho para alterar dados até vazamentos de dados, manipulação de recursos e escalonamento de privilégios.
|
||||
Um atacante com as permissões **`states:TestState`** e **`iam:PassRole`** pode testar qualquer estado e passar qualquer função IAM para ele sem criar ou atualizar uma máquina de estado existente, potencialmente permitindo acesso não autorizado a outros serviços AWS com as permissões da função. Combinadas, essas permissões podem levar a ações não autorizadas extensas, desde manipulação de fluxos de trabalho para alterar dados até vazamentos de dados, manipulação de recursos e escalonamento de privilégios.
|
||||
```bash
|
||||
aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
|
||||
```
|
||||
@@ -63,7 +63,7 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn
|
||||
|
||||
### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
|
||||
|
||||
Um atacante com **`states:CreateStateMachine`** & **`iam:PassRole`** seria capaz de criar uma máquina de estado e fornecer a ela qualquer função IAM, permitindo acesso não autorizado a outros serviços AWS com as permissões da função. Em contraste com a técnica de elevação de privilégios anterior (**`states:TestState`** & **`iam:PassRole`**), esta não se executa por si só, você também precisará ter as permissões **`states:StartExecution`** ou **`states:StartSyncExecution`** (**`states:StartSyncExecution`** **não está disponível para fluxos de trabalho padrão**, **apenas para máquinas de estado expressas**) para iniciar uma execução sobre a máquina de estado.
|
||||
Um atacante com **`states:CreateStateMachine`** & **`iam:PassRole`** seria capaz de criar uma máquina de estados e fornecer a ela qualquer função IAM, permitindo acesso não autorizado a outros serviços AWS com as permissões da função. Em contraste com a técnica de elevação de privilégios anterior (**`states:TestState`** & **`iam:PassRole`**), esta não se executa por si só, você também precisará ter as permissões **`states:StartExecution`** ou **`states:StartSyncExecution`** (**`states:StartSyncExecution`** **não está disponível para fluxos de trabalho padrão**, **apenas para máquinas de estados expressas**) para iniciar uma execução sobre a máquina de estados.
|
||||
```bash
|
||||
# Create a state machine
|
||||
aws states create-state-machine --name <value> --definition <value> --role-arn <value> [--type <STANDARD | EXPRESS>] [--logging-configuration <value>]\
|
||||
@@ -75,7 +75,7 @@ aws states start-execution --state-machine-arn <value> [--name <value>] [--input
|
||||
# Start a Synchronous Express state machine execution
|
||||
aws states start-sync-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]
|
||||
```
|
||||
Os seguintes exemplos mostram como criar uma máquina de estado que cria uma chave de acesso para o **`admin`** usuário e exfiltra essa chave de acesso para um bucket S3 controlado pelo atacante, aproveitando essas permissões e um papel permissivo do ambiente AWS. Esse papel permissivo deve ter qualquer política de alto privilégio associada a ele (por exemplo, **`arn:aws:iam::aws:policy/AdministratorAccess`**) que permite que a máquina de estado execute as ações **`iam:CreateAccessKey`** e **`s3:putObject`**.
|
||||
Os seguintes exemplos mostram como criar uma máquina de estados que cria uma chave de acesso para o **`admin`** e exfiltra essa chave de acesso para um bucket S3 controlado pelo atacante, aproveitando essas permissões e um papel permissivo do ambiente AWS. Esse papel permissivo deve ter qualquer política de alto privilégio associada a ele (por exemplo, **`arn:aws:iam::aws:policy/AdministratorAccess`**) que permite que a máquina de estados execute as ações **`iam:CreateAccessKey`** e **`s3:putObject`**.
|
||||
|
||||
- **stateMachineDefinition.json**:
|
||||
```json
|
||||
@@ -138,7 +138,7 @@ aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:1
|
||||
|
||||
### `states:UpdateStateMachine` & (não sempre necessário) `iam:PassRole`
|
||||
|
||||
Um atacante com a permissão **`states:UpdateStateMachine`** seria capaz de modificar a definição de uma máquina de estados, podendo adicionar estados extras furtivos que poderiam resultar em uma escalada de privilégios. Dessa forma, quando um usuário legítimo inicia uma execução da máquina de estados, esse novo estado furtivo malicioso será executado e a escalada de privilégios será bem-sucedida.
|
||||
Um atacante com a permissão **`states:UpdateStateMachine`** seria capaz de modificar a definição de uma máquina de estados, podendo adicionar estados extras furtivos que poderiam resultar em uma escalada de privilégios. Dessa forma, quando um usuário legítimo inicia uma execução da máquina de estados, este novo estado furtivo malicioso será executado e a escalada de privilégios será bem-sucedida.
|
||||
|
||||
Dependendo de quão permissivo é o IAM Role associado à máquina de estados, um atacante enfrentaria 2 situações:
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Buckets Públicos do S3
|
||||
## Buckets Públicos S3
|
||||
|
||||
Um bucket é considerado **“público”** se **qualquer usuário pode listar o conteúdo** do bucket, e **“privado”** se o conteúdo do bucket pode **ser listado ou escrito apenas por certos usuários**.
|
||||
|
||||
@@ -10,7 +10,7 @@ As empresas podem ter **permissões de buckets mal configuradas**, dando acesso
|
||||
|
||||
**Saiba mais sobre a má configuração do AWS-S3 aqui:** [**http://flaws.cloud**](http://flaws.cloud/) **e** [**http://flaws2.cloud/**](http://flaws2.cloud)
|
||||
|
||||
### Encontrando Buckets da AWS
|
||||
### Encontrando Buckets AWS
|
||||
|
||||
Diferentes métodos para encontrar quando uma página da web está usando AWS para armazenar alguns recursos:
|
||||
|
||||
@@ -25,8 +25,8 @@ http://s3.amazonaws.com/[bucket_name]/
|
||||
http://[bucket_name].s3.amazonaws.com/
|
||||
```
|
||||
|
||||
- Verifique por **CNAMES** já que `resources.domain.com` pode ter o CNAME `bucket.s3.amazonaws.com`
|
||||
- **[s3dns](https://github.com/olizimmermann/s3dns)** – Um servidor DNS leve que identifica passivamente buckets de armazenamento em nuvem (S3, GCP, Azure) analisando o tráfego DNS. Ele detecta CNAMEs, segue cadeias de resolução e combina padrões de buckets, oferecendo uma alternativa silenciosa à descoberta por força bruta ou baseada em API. Perfeito para recon e fluxos de trabalho de OSINT.
|
||||
- Verifique por **CNAMES** como `resources.domain.com` que pode ter o CNAME `bucket.s3.amazonaws.com`
|
||||
- **[s3dns](https://github.com/olizimmermann/s3dns)** – Um servidor DNS leve que identifica passivamente buckets de armazenamento em nuvem (S3, GCP, Azure) analisando o tráfego DNS. Ele detecta CNAMEs, segue cadeias de resolução e combina padrões de buckets, oferecendo uma alternativa silenciosa à descoberta por força bruta ou baseada em API. Perfeito para fluxos de trabalho de recon e OSINT.
|
||||
- Verifique [https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/), um site com **buckets abertos já descobertos**.
|
||||
- O **nome do bucket** e o **nome do domínio do bucket** precisam ser **os mesmos.**
|
||||
- **flaws.cloud** está no **IP** 52.92.181.107 e se você for lá, ele redireciona você para [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/). Além disso, `dig -x 52.92.181.107` retorna `s3-website-us-west-2.amazonaws.com`.
|
||||
@@ -98,13 +98,13 @@ Non-authoritative answer:
|
||||
```
|
||||
Verifique se o domínio resolvido contém a palavra "website".\
|
||||
Você pode acessar o site estático indo para: `flaws.cloud.s3-website-us-west-2.amazonaws.com`\
|
||||
ou você pode acessar o bucket visitando: `flaws.cloud.s3-us-west-2.amazonaws.com`
|
||||
ou pode acessar o bucket visitando: `flaws.cloud.s3-us-west-2.amazonaws.com`
|
||||
|
||||
|
||||
|
||||
#### Tentando
|
||||
|
||||
Se você tentar acessar um bucket, mas no **nome do domínio você especificar outra região** (por exemplo, o bucket está em `bucket.s3.amazonaws.com`, mas você tenta acessar `bucket.s3-website-us-west-2.amazonaws.com`, então você será **indicado para o local correto**:
|
||||
Se você tentar acessar um bucket, mas no **nome do domínio você especificar outra região** (por exemplo, o bucket está em `bucket.s3.amazonaws.com`, mas você tenta acessar `bucket.s3-website-us-west-2.amazonaws.com`), então você será **indicado para o local correto**:
|
||||
|
||||
.png>)
|
||||
|
||||
@@ -134,7 +134,7 @@ Se o bucket não tiver um nome de domínio, ao tentar enumerá-lo, **coloque ape
|
||||
```
|
||||
https://{user_provided}.s3.amazonaws.com
|
||||
```
|
||||
### Obter ID da Conta de um Bucket público
|
||||
### Obter ID da Conta a partir de um Bucket público
|
||||
|
||||
É possível determinar uma conta AWS aproveitando a nova **`S3:ResourceAccount`** **Chave de Condição de Política**. Esta condição **restrige o acesso com base no bucket S3** em que uma conta está (outras políticas baseadas em conta restringem com base na conta em que o principal solicitante está).\
|
||||
E como a política pode conter **coringas**, é possível encontrar o número da conta **apenas um número por vez**.
|
||||
|
||||
Reference in New Issue
Block a user