A sophisticated technique, termed ECScape, has been identified, allowing malicious containers operating within Amazon Elastic Container Service (ECS) to extract AWS credentials from other containers co-located on the same EC2 instance. This discovery underscores significant isolation vulnerabilities in multi-tenant ECS deployments and highlights the security benefits inherent in AWS Fargate’s micro-VM architecture.
Discovery and Mechanism of ECScape
Security researcher Naor Haziz unveiled ECScape, a method that exploits an undocumented internal protocol between ECS agents and AWS’s control plane to exfiltrate Identity and Access Management (IAM) credentials across container boundaries. Unlike traditional container escape techniques that necessitate host-level access, ECScape operates entirely within the container’s namespace, utilizing network manipulation to impersonate the ECS agent.
Step-by-Step Breakdown of the ECScape Attack
1. Accessing Instance Metadata Service (IMDS): The attack initiates when a compromised container accesses the IMDS at 169.254.169.254 to retrieve the EC2 instance’s IAM role credentials. These credentials, typically employed by the ECS agent for legitimate operations, serve as the foundation for the subsequent impersonation attack.
2. Discovering ECS Control Plane’s Polling Endpoint: With the stolen instance credentials, attackers can identify the ECS control plane’s polling endpoint via the `ecs:DiscoverPollEndpoint` API. This step allows them to gather essential identifiers, including cluster Amazon Resource Names (ARNs) and container instance ARNs.
3. Establishing a Forged WebSocket Connection: The malicious process then sets up a counterfeit WebSocket connection to AWS’s Agent Communication Service (ACS), the internal channel through which ECS delivers task credentials to agents. By including the parameter `sendCredentials=true` in the WebSocket handshake, attackers can receive all IAM credentials for every task running on the shared EC2 instance. This encompasses both application role credentials and task execution role credentials, which often contain sensitive permissions for accessing AWS Secrets Manager, Elastic Container Registry (ECR) repositories, and CloudWatch Logs.
Implications and Stealth Characteristics
ECScape exhibits particularly concerning stealth attributes, as the stolen credentials function identically to legitimate ones. AWS CloudTrail logs attribute API calls to the victim task’s role rather than the attacking container, rendering initial detection extremely challenging. This technique disrupts fundamental assumptions about container isolation in ECS environments, enabling low-privileged tasks to assume the permissions of high-privileged containers on the same host.
In demonstration environments, researchers demonstrated how a container with deny-all IAM policies could successfully delete S3 buckets using stolen credentials from a neighboring task with S3 full access. The attack also facilitated the extraction of sensitive secrets intended for other containers, effectively compromising the multi-tenant security model.
AWS’s Response and Recommendations
AWS reviewed the findings through their coordinated disclosure program but classified the behavior as a design consideration rather than a vulnerability. The company emphasized that containers sharing EC2 instances are implicitly part of the same trust domain unless users implement proper isolation measures.
Following the disclosure, AWS updated its documentation to explicitly warn that tasks running on the same EC2 instance may potentially access credentials belonging to other tasks on that instance. The company strongly recommends AWS Fargate for scenarios requiring stronger isolation guarantees.
Mitigation Strategies
Security experts recommend several mitigation strategies to address the risks posed by ECScape:
– Restricting IMDS Access: Disable or restrict IMDS access for containers through network controls or the `ECS_AWSVPC_BLOCK_IMDS` setting. This measure prevents containers from obtaining instance credentials necessary for the attack.
– Avoiding Co-Location of Tasks: Refrain from co-locating high-privilege and low-privilege tasks on shared instances. This practice minimizes the risk of credential theft between tasks.
– Implementing Least-Privilege IAM Policies: Adopt least-privilege IAM policies to limit the permissions granted to each task, reducing the potential impact of credential compromise.
– Transitioning to AWS Fargate: Consider migrating to AWS Fargate, which offers better task isolation by running each task in its own micro-VM with its own isolated IMDS and ECS agent. This architecture inherently mitigates the risks associated with ECScape.
Conclusion
The ECScape technique reveals critical isolation weaknesses in Amazon ECS when running on EC2 instances, allowing for cross-task credential theft without requiring host-level access. By understanding the mechanics of this attack and implementing recommended mitigation strategies, organizations can enhance the security of their containerized applications and protect sensitive credentials from unauthorized access.
