Full Report
Security researchers discovered a name confusion attack that allows access to an Amazon Web Services account to anyone that publishes an Amazon Machine Image (AMI) with a specific name. [...]
Analysis Summary
# Vulnerability: whoAMI Attack Allows Code Execution via Malicious Amazon Machine Images (AMIs)
## CVE Details
- CVE ID: Not explicitly provided in the text (Focus is on a configuration vulnerability/attack pattern)
- CVSS Score: Not provided
- CWE: Likely related to CWE-20 (Improper Input Validation) or CWE-284 (Improper Access Control) due to how system trust is leveraged.
## Affected Systems
- Products: Amazon EC2 instances utilizing community AMIs.
- Versions: Any configuration relying on default, unfiltered selection of publicly available AMIs, particularly when using `most_recent = true` without specifying AMI owner IDs.
- Configurations: AWS accounts publishing or launching EC2 instances from maliciously named, untrusted Community AMIs without applying owner filters during image retrieval (`ec2:DescribeImages`).
## Vulnerability Description
The "whoAMI" attack exploits the trust placed in Amazon Machine Images (AMIs) published to the public AWS Community AMI catalog. An adversary can publish a backdoored AMI using a name that closely mimics a legitimate, trusted AMI release from a known provider. When system administrators or automation tools (like Terraform, AWS CLI, SDKs) query for the "most recent" AMI without explicitly filtering by the trusted owner ID, they risk inadvertently selecting and launching the malicious image. Launching an instance from this backdoored AMI grants the attacker code execution within the resulting EC2 instance. This attack does not require compromising the target's AWS credentials.
## Exploitation
- Status: PoC available (Demonstrated by Datadog researchers).
- Complexity: Low (Requires only an AWS account to publish the malicious AMI and leveraging default API/tool behavior).
- Attack Vector: Network (via the AWS API/Console lookup mechanism).
## Impact
- Confidentiality: High (Attacker gains RCE leading to potential data exfiltration).
- Integrity: High (Attacker gains arbitrary code execution and full control over the compromised instance).
- Availability: High (Instance can be taken offline or used for further attacks).
## Remediation
### Patches
- AWS confirmed an internal fix applied on September 19th of the previous year.
### Workarounds
1. **Adopt 'Allowed AMIs' Control:** Customers should enable the 'Allowed AMIs' feature in their AWS account settings to create an explicit allow list of trusted AMI providers.
* Location: `AWS Console → EC2 → Account Attributes → Allowed AMIs`.
2. **AMI Owner Filtering:** Always specify required AMI owners when calling the `ec2:DescribeImages` API operation.
3. **Tool Configuration Audit:** Review and update configurations using Terraform, AWS CLI, Python Boto3, and Go AWS SDK to stop relying solely on `most_recent = true` without owner filtering.
* *Note: Terraform 5.77 began issuing warnings for unfiltered `most_recent = true` usage.*
## Detection
- **Indicators of Compromise (IOCs):** Running EC2 instances that do not map back to a known, verified, trusted AMI ID/Owner.
- **Detection Methods and Tools:**
* Enable AWS Audit Mode via 'Allowed AMIs' to immediately block launches from untrusted sources.
* Switch to 'Enforcement Mode' within 'Allowed AMIs' to prevent launches entirely.
* Utilize the scanner released by DataDog to check existing AWS accounts for instances created from untrusted AMIs.
## References
- Vendor Advisories: AWS internal fix confirmed December 1st introduction of 'Allowed AMIs'.
- Relevant links: bbleepingcomputer.com/news/security/whoami-attacks-give-hackers-code-execution-on-amazon-ec2-instances/ (Source link)
- Research/Tooling: htt ps://github.com/DataDog/whoami-ami-scanner (DataDog Scanner repository reference)