mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 14:47:17 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-services/aws-ecs-
This commit is contained in:
@@ -4,30 +4,30 @@
|
||||
|
||||
## ECS
|
||||
|
||||
### Informações Básicas
|
||||
### Basic Information
|
||||
|
||||
Amazon **Elastic Container Services** ou ECS fornece uma plataforma para **hospedar aplicações conteinerizadas na nuvem**. ECS tem dois métodos de **implantação**, tipo de instância **EC2** e uma opção **serverless**, **Fargate**. O serviço **torna a execução de contêineres na nuvem muito fácil e sem dor**.
|
||||
Amazon **Elastic Container Services** ou ECS fornece uma plataforma para **hospedar aplicações containerized na cloud**. ECS tem dois métodos de **deployment**, o tipo de instância **EC2** e uma opção **serverless**, **Fargate**. O serviço **torna executar containers na cloud muito fácil e sem dor**.
|
||||
|
||||
ECS opera usando os seguintes três blocos de construção: **Clusters**, **Serviços** e **Definições de Tarefas**.
|
||||
ECS opera usando os seguintes três blocos de construção: **Clusters**, **Services** e **Task Definitions**.
|
||||
|
||||
- **Clusters** são **grupos de contêineres** que estão rodando na nuvem. Como mencionado anteriormente, existem dois tipos de lançamento para contêineres, EC2 e Fargate. A AWS define o tipo de lançamento **EC2** como permitindo que os clientes “executem \[suas] aplicações conteinerizadas em um cluster de instâncias Amazon EC2 que \[eles] **gerenciam**”. **Fargate** é semelhante e é definido como “\[permitindo] que você execute suas aplicações conteinerizadas **sem a necessidade de provisionar e gerenciar** a infraestrutura de backend”.
|
||||
- **Serviços** são criados dentro de um cluster e responsáveis por **executar as tarefas**. Dentro de uma definição de serviço **você define o número de tarefas a serem executadas, escalonamento automático, provedor de capacidade (Fargate/EC2/Externo),** informações de **rede** como VPCs, sub-redes e grupos de segurança.
|
||||
- Existem **2 tipos de aplicações**:
|
||||
- **Serviço**: Um grupo de tarefas lidando com um trabalho computacional de longa duração que pode ser interrompido e reiniciado. Por exemplo, uma aplicação web.
|
||||
- **Tarefa**: Uma tarefa independente que é executada e finalizada. Por exemplo, um trabalho em lote.
|
||||
- Entre as aplicações de serviço, existem **2 tipos de agendadores de serviço**:
|
||||
- [**REPLICA**](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html): A estratégia de agendamento de réplica coloca e **mantém o número desejado** de tarefas em todo o seu cluster. Se por algum motivo uma tarefa for encerrada, uma nova é lançada no mesmo ou em um nó diferente.
|
||||
- [**DAEMON**](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html): Implanta exatamente uma tarefa em cada instância de contêiner ativa que possui os requisitos necessários. Não há necessidade de especificar um número desejado de tarefas, uma estratégia de colocação de tarefas ou usar políticas de Escalonamento Automático de Serviço.
|
||||
- **Definições de Tarefas** são responsáveis por **definir quais contêineres serão executados** e os vários parâmetros que serão configurados com os contêineres, como **mapeamentos de porta** com o host, **variáveis de ambiente**, **entrypoint** do Docker...
|
||||
- Verifique **variáveis de ambiente para informações sensíveis**!
|
||||
- **Clusters** são **grupos de containers** que estão rodando na cloud. Como mencionado anteriormente, existem dois launch types para containers, EC2 e Fargate. A AWS define o launch type **EC2** como permitindo que os clientes “executem \[suas] aplicações containerized em um cluster de instâncias Amazon EC2 que \[eles] **manage**”. **Fargate** é similar e é definido como “\[permitindo] que você execute suas aplicações containerized **sem a necessidade de provisionar e manage** a infraestrutura de backend”.
|
||||
- **Services** são criados dentro de um cluster e responsáveis por **executar as tasks**. Dentro de uma definição de service, **você define o número de tasks para executar, auto scaling, capacity provider (Fargate/EC2/External),** informações de **networking** como VPC’s, subnets e security groups.
|
||||
- Existem **2 tipos de applications**:
|
||||
- **Service**: Um grupo de tasks lidando com um trabalho de computação de longa duração que pode ser parado e reiniciado. Por exemplo, uma web application.
|
||||
- **Task**: Uma task independente que executa e termina. Por exemplo, um batch job.
|
||||
- Entre as service applications, existem **2 tipos de service schedulers**:
|
||||
- [**REPLICA**](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html): A estratégia de scheduling replica coloca e **mantém o número desejado** de tasks em todo o seu cluster. Se por algum motivo uma task for encerrada, uma nova é lançada no mesmo ou em outro node.
|
||||
- [**DAEMON**](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html): Faz deploy de exatamente uma task em cada container instance ativa que tenha os requisitos necessários. Não há necessidade de especificar um número desejado de tasks, uma task placement strategy ou usar políticas de Service Auto Scaling.
|
||||
- **Task Definitions** são responsáveis por **definir quais containers vão rodar** e os vários parâmetros que serão configurados com os containers, como **port mappings** com o host, **env variables**, Docker **entrypoint**...
|
||||
- Verifique **env variables para sensitive info**!
|
||||
|
||||
### Dados Sensíveis em Definições de Tarefas
|
||||
### Sensitive Data In Task Definitions
|
||||
|
||||
As definições de tarefas são responsáveis por **configurar os contêineres reais que estarão rodando no ECS**. Como as definições de tarefas definem como os contêineres serão executados, uma infinidade de informações pode ser encontrada dentro delas.
|
||||
Task definitions são responsáveis por **configurar os containers reais que estarão rodando no ECS**. Como as task definitions definem como os containers vão rodar, uma grande quantidade de informações pode ser encontrada nelas.
|
||||
|
||||
Pacu pode enumerar ECS (list-clusters, list-container-instances, list-services, list-task-definitions), também pode despejar definições de tarefas.
|
||||
Pacu pode enumerar ECS (list-clusters, list-container-instances, list-services, list-task-definitions), também pode fazer dump de task definitions.
|
||||
|
||||
### Enumeração
|
||||
### Enumeration
|
||||
```bash
|
||||
# Clusters info
|
||||
aws ecs list-clusters
|
||||
@@ -51,27 +51,60 @@ aws ecs describe-tasks --cluster <cluster> --tasks <tasks>
|
||||
## Look for env vars and secrets used from the task definition
|
||||
aws ecs describe-task-definition --task-definition <TASK_NAME>:<VERSION>
|
||||
```
|
||||
### Acesso Não Autenticado
|
||||
### Enumeração no Host via o ECS Agent State DB (`agent.db`)
|
||||
|
||||
Quando você tem **shell access em uma ECS container instance** , ou você **escapeu de um container com um host bind-mount de `/var/lib/ecs`** (uma misconfiguration comum quando tasks rodam privileged ou com `volumesFrom` expondo o host data dir), o ECS agent deixa `agent.db` em disco que pode ser lido **sem nenhuma AWS API call**, **sem nenhuma IAM permission**, e **sem disparar CloudTrail**.
|
||||
```
|
||||
/var/lib/ecs/data/agent.db
|
||||
```
|
||||
(ou, ao ler de um container que tem o host montado em `/host`, `/host/var/lib/ecs/data/agent.db`).
|
||||
```bash
|
||||
# Most useful one-liner — dumps everything readable
|
||||
strings /var/lib/ecs/data/agent.db
|
||||
|
||||
# From inside a container with the host mounted at /host
|
||||
strings /host/var/lib/ecs/data/agent.db
|
||||
|
||||
# Filter for the highest-value artefacts
|
||||
strings /var/lib/ecs/data/agent.db | grep -aE 'arn:aws:|AKIA|ASIA|"secret|password|TOKEN|credentials|taskRoleArn|executionRoleArn'
|
||||
|
||||
# Save the outcome from strings for offline analysis
|
||||
strings /host/var/lib/ecs/data/agent.db >> /tmp/agent.txt
|
||||
tr -s '{}[],:"\\' '\n' < /tmp/agent.txt | sed 's/^[[:space:]]*//; s/[[:space:]]*$//' | awk 'NF && length($0)>2 && !/^[0-9.]+$/' | sort -u
|
||||
```
|
||||
#### O que você pode recuperar
|
||||
|
||||
Dependendo da idade do cluster e da rotatividade da workload, `strings` em `agent.db` normalmente retorna:
|
||||
|
||||
- **ARNs de IAM role da task e da execução** (`taskRoleArn`, `executionRoleArn`) para toda task que o agent executou — alvos úteis para [credential retrieval via the task metadata endpoint](https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-services/aws-ecs-enum.html) (`169.254.170.2`).
|
||||
- **Definições completas de task** — image URIs (muitas vezes repositórios privados do ECR), command, entrypoint, port mappings, mount points, log configuration e **variáveis de ambiente em plaintext** que frequentemente incluem database URLs, API tokens e secrets de terceiros.
|
||||
- **Referências a secrets** — blocos `secretOptions` e `secrets` apontando para paths do SSM Parameter Store e ARNs do Secrets Manager (ótima lista para pivot).
|
||||
- **ARN da container instance, ARN do cluster e registration token** — confirma o nome do cluster e o contexto de account/region sem nenhuma chamada de API.
|
||||
- **Metadados da ENI** — IPs privados, MAC addresses, subnet IDs e security group IDs atribuídos em modo `awsvpc` (útil para planejamento de movement lateral).
|
||||
- **Credenciais de image pull** — quando a task definition usa `repositoryCredentials`, o ARN do Secrets Manager referenciado fica aqui; em agents antigos, blobs de auth de private-registry (`ECS_ENGINE_AUTH_DATA`) também podem estar em cache.
|
||||
- **Containers de tasks recentemente paradas** — incluindo nomes, IDs, exit codes e labels, às vezes muito tempo depois de a chamada correspondente `aws ecs describe-tasks` já ter expurgado esses dados da resposta da API.
|
||||
|
||||
### Unauthenticated Access
|
||||
|
||||
{{#ref}}
|
||||
../aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum/README.md
|
||||
{{#endref}}
|
||||
|
||||
### Escalação de Privilégios
|
||||
### Privesc
|
||||
|
||||
Na página a seguir, você pode verificar como **abusar das permissões do ECS para escalar privilégios**:
|
||||
Na página seguinte você pode ver como **abusar das permissões do ECS para escalar privilégios**:
|
||||
|
||||
{{#ref}}
|
||||
../aws-privilege-escalation/aws-ecs-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
### Pós Exploração
|
||||
### Post Exploitation
|
||||
|
||||
{{#ref}}
|
||||
../aws-post-exploitation/aws-ecs-post-exploitation/README.md
|
||||
{{#endref}}
|
||||
|
||||
### Persistência
|
||||
### Persistence
|
||||
|
||||
{{#ref}}
|
||||
../aws-persistence/aws-ecs-persistence/README.md
|
||||
|
||||
Reference in New Issue
Block a user