Falha ECScape no AWS ECS: Como proteger seus contêineres

Imagem do autor do SempreUpdate Jardeson Márcio
Escrito por
Jardeson Márcio
Jardeson Márcio é Jornalista e Mestre em Tecnologia Agroalimentar pela Universidade Federal da Paraíba. Com 8 anos de experiência escrevendo no SempreUpdate, Jardeson é um especialista...

Entenda a vulnerabilidade que abala a segurança de contêineres no Amazon ECS e saiba como proteger seu ambiente agora mesmo.

Uma vulnerabilidade crítica no Amazon ECS foi revelada durante a prestigiada conferência Black Hat USA 2025, chamando atenção imediata da comunidade de segurança em nuvem. Batizada de ECScape, a falha demonstra como um contêiner com poucos privilégios pode escapar de seu isolamento e roubar credenciais de tarefas mais privilegiadas no mesmo ambiente — comprometendo totalmente a infraestrutura.

A apresentação, conduzida pela equipe da Sweet Security, chocou especialistas ao mostrar que o ataque não requer acesso root, explora protocolos internos não documentados da AWS, e permite o uso indevido de perfis IAM atribuídos a outras tarefas. Neste artigo, vamos dissecar essa cadeia de ataque, analisar os impactos reais para ambientes em nuvem, e fornecer um guia completo de mitigação com foco em segurança, ação imediata e boas práticas.

O Amazon ECS (Elastic Container Service) é amplamente utilizado por empresas para orquestrar contêineres em escala. Com a crescente adoção de microsserviços, qualquer falha em seu modelo de isolamento representa um risco sistêmico. A falha ECScape é mais do que uma vulnerabilidade: é um alerta sobre os perigos escondidos nas abstrações da computação em nuvem.

AWS ECS
Imagem: TheHackerNews

O que é o ECScape e por que ele é perigoso?

A vulnerabilidade ECScape é uma cadeia de escalonamento de privilégios descoberta no Amazon ECS, especificamente em implantações que rodam várias tarefas dentro da mesma instância EC2. O ataque permite que uma tarefa com baixo privilégio obtenha credenciais temporárias IAM de outras tarefas mais privilegiadas, violando totalmente o isolamento lógico esperado.

No Amazon ECS, uma “tarefa” representa a menor unidade de execução de contêineres. Cada tarefa pode receber permissões específicas por meio de funções IAM. Em um modelo seguro, essas permissões devem ser isoladas. No entanto, a falha ECScape explora vulnerabilidades no mecanismo de entrega dessas credenciais, permitindo que uma tarefa se passe por outra.

O perigo central está na quebra do modelo de confiança interno da AWS. Em vez de confiar apenas em quem deveria ter acesso, o sistema pode ser enganado por um invasor habilidoso que simula comportamentos legítimos.

Como a cadeia de ataque do ECScape funciona

A cadeia de ataque do ECScape é composta por três etapas principais, explorando falhas no fluxo de comunicação entre instâncias, agentes e o controle de tarefas do ECS.

Abusando de um protocolo interno não documentado

Tudo começa com o acesso ao serviço de metadados da instância EC2, uma interface que fornece informações sensíveis sobre a própria instância, incluindo credenciais temporárias. Este é um ponto comum de ataque, mas o ECScape vai além.

O atacante utiliza essas credenciais básicas para realizar chamadas autenticadas dentro do ambiente AWS. A falha está em um protocolo interno não documentado, utilizado para comunicação entre o agente ECS e o serviço de controle (ACS). Essa brecha dá início ao processo de falsificação.

Falsificando a comunicação para se passar pelo agente ECS

A etapa seguinte envolve o ataque mais sofisticado: o invasor simula o comportamento do agente ECS, o processo responsável por gerenciar as tarefas e reportar status ao plano de controle da AWS.

O atacante coleta identificadores de tarefas em execução e começa a enviar solicitações falsificadas ao plano de controle. Como as credenciais utilizadas são válidas (embora de menor privilégio), e o protocolo não exige uma validação forte de identidade entre tarefas, o sistema aceita a comunicação como legítima.

O roubo das credenciais de tarefas privilegiadas

Com a comunicação estabelecida, o invasor envia requisições para acessar as credenciais IAM de outras tarefas. O plano de controle, sem diferenciar adequadamente as origens, entrega as credenciais solicitadas.

Esse é o ponto crítico: o atacante agora possui credenciais altamente privilegiadas de outras tarefas no mesmo host, podendo acessar recursos AWS como bancos de dados, buckets S3, ou executar comandos com permissões administrativas.

O impacto real: Riscos e consequências para seu ambiente

Embora o ataque ECScape seja tecnicamente complexo, suas implicações práticas são devastadoras para qualquer empresa que utilize o Amazon ECS em modo EC2.

Cenários de ataque incluem:

  • Movimentação lateral entre serviços e clusters, usando as credenciais roubadas para explorar outras partes do ambiente.
  • Exfiltração de dados sensíveis armazenados em bancos de dados, buckets S3 ou serviços protegidos por IAM.
  • Execução de comandos destrutivos, como exclusão de instâncias, alteração de configurações de segurança ou provisionamento de novos recursos para ataque persistente.
  • Comprometimento completo da infraestrutura AWS, caso a tarefa invadida possua permissões amplas (admin).

Como o ataque não requer acesso root e se baseia em credenciais válidas, muitas vezes ele passa despercebido pelos mecanismos de detecção tradicionais.

Mitigação: Como proteger seu ambiente da falha ECScape e ataques similares

A boa notícia é que medidas claras e práticas podem ser adotadas para eliminar ou mitigar significativamente os riscos da falha ECScape. A seguir, os três pilares principais de proteção:

A recomendação oficial: Isolamento total com AWS Fargate

A AWS recomenda fortemente o uso do Fargate, que executa cada tarefa em ambientes isolados por hardware. Como o Fargate não compartilha hosts entre tarefas, o vetor de ataque da ECScape é eliminado pela raiz.

Migrar cargas críticas para o Fargate é a ação mais eficaz. Embora possa ter custos maiores em alguns cenários, o ganho em segurança justifica a decisão para aplicações sensíveis.

Boas práticas essenciais: Segregação e privilégio mínimo

Para quem ainda utiliza EC2 no ECS, é essencial evitar a coabitação de tarefas de diferentes níveis de privilégio no mesmo host. Mantenha cargas sensíveis separadas e use grupos de instância distintos.

Além disso, siga o princípio do menor privilégio nas funções IAM atribuídas às tarefas e ao próprio agente ECS. Cada função deve ter acesso apenas ao que é estritamente necessário.

Monitoramento ativo: Detectando anomalias com CloudTrail

Configure alertas no AWS CloudTrail para monitorar o uso inesperado de funções IAM, especialmente quando tarefas que não deveriam ter certos acessos passam a usá-los.

A detecção antecipada de comportamentos incomuns pode permitir uma resposta rápida antes que o ataque comprometa o ambiente por completo.

Conclusão: A segurança na nuvem é um campo de batalha constante

A falha ECScape é um lembrete poderoso de que até mesmo os serviços mais confiáveis da nuvem podem conter vetores de ataque inesperados, muitas vezes escondidos nas camadas mais internas da abstração.

Como afirmou Naor Haziz, pesquisador que liderou a investigação da falha:

“A confiança cega no isolamento lógico de tarefas em ambientes compartilhados pode ser explorada — e foi.”

A responsabilidade pela segurança em nuvem é compartilhada, mas cabe aos administradores e desenvolvedores se manterem informados, atualizados e proativos.

Reveja hoje mesmo suas configurações de Amazon ECS, avalie a adoção de Fargate para cargas críticas, e audite suas permissões IAM com urgência. A próxima brecha pode não ser anunciada com antecedência.

Compartilhe este artigo