A newly discovered security vulnerability in Amazon Web Services (AWS) exposes customers to potential attacks simply through the way they retrieve Amazon Machine Images (AMIs). Dubbed “whoAMI,” this attack, first identified by researchers at DataDog, manipulates AMI selection mechanisms to allow attackers to execute malicious code within an AWS account—without breaching it.
Attack Exploits a Flaw in AMI Selection
AMIs are preconfigured virtual machines that power EC2 instances in AWS. They can be either public or private, with each having a unique identifier. Users rely on these images to spin up cloud-based virtual servers.
However, the “whoAMI” attack takes advantage of a common misconfiguration when retrieving AMIs. Some organizations fail to specify an AMI owner in their selection process, allowing attackers to insert malicious AMIs with names similar to trusted ones. The risk increases when automated scripts or infrastructure-as-code tools like Terraform select the most recently published AMI without verifying its source.
A few key vulnerabilities make this attack possible:
- Using the ec2:DescribeImages API without specifying an owner
- Relying on wildcards to select AMIs instead of specific IDs
- Terraform’s “most_recent=true” option automatically choosing the newest AMI that matches the filter criteria
If a system is configured this way, it could end up selecting an AMI published by an attacker instead of a legitimate one. The malicious AMI then executes unauthorized code, potentially compromising the entire cloud environment.
Attackers Don’t Need Access to Targeted AWS Accounts
This attack method is particularly dangerous because the attacker doesn’t need to breach an AWS account. Instead, they just need an AWS account of their own to upload a compromised AMI into the public AMI catalog.
Here’s how an attacker could take advantage of this loophole:
- Publish an AMI with a name similar to those used by trusted sources.
- Wait for automated scripts or infrastructure tools to select it based on name patterns.
- If the victim’s system is configured to retrieve the most recent AMI, it could unknowingly pick the attacker’s version.
DataDog estimates that around 1% of organizations they monitor are vulnerable to this attack, but the real number of affected AWS accounts is likely in the thousands.
Amazon’s Response and Security Fixes
Amazon confirmed the vulnerability in internal, non-production systems after being alerted by DataDog researchers. The company released a fix on September 19, 2024, but noted that customers still need to take action on their end to protect their accounts.
To mitigate the risk of a “whoAMI” attack, AWS introduced a new security feature called “Allowed AMIs” on December 1, 2024. This feature enables customers to create an allowlist of trusted AMI providers, preventing unapproved images from being used.
Amazon has also provided the following recommendations:
- Always specify AMI owners when using the “ec2:DescribeImages” API.
- Enable the “Allowed AMIs” feature to restrict AMI selection to trusted sources.
- Use AWS Audit Mode to identify untrusted AMIs and switch to Enforcement Mode to block them.
For Terraform users, version 5.77, released in November 2024, now issues warnings when “most_recent=true” is used without an owner filter. Stricter enforcement is planned for Terraform 6.0.
How to Check if Your AWS Account is at Risk
Security teams should immediately review their AWS configurations and update their scripts to ensure safe AMI retrieval. Key areas to audit include:
- Terraform configurations
- AWS CLI commands
- API calls made via Python Boto3 and Go AWS SDK
To make it easier for organizations to detect compromised AMIs, DataDog has also released an open-source scanner on GitHub. The tool scans AWS accounts for EC2 instances running from untrusted AMIs.
For customers relying on AMIs in production, the key takeaway is clear: don’t trust AMIs without verifying their source. AWS has provided the necessary security tools, but the final responsibility lies with customers to ensure their environments are properly configured.
