WhoAMI or Name Confusion Attack Could Expose your AWS infrastructure!

Security researchers have recently uncovered a subtle yet significant security vulnerability in Amazon Web Services (AWS) that could expose your cloud infrastructure to unauthorized access. Dubbed "whoAMI," this name confusion attack leverages a loophole in how Amazon Machine Images (AMIs) are handled, potentially granting attackers access to your AWS accounts simply by publishing a cleverly named AMI.

Discovered by the team at DataDog in August 2024, the "whoAMI" attack highlights a critical flaw in how software projects often retrieve AMI IDs. DataDog researchers successfully demonstrated that by exploiting this vulnerability, attackers could achieve code execution within AWS accounts. While Amazon swiftly addressed the core vulnerability with a fix rolled out in September, the risk remains for organizations that haven't updated their configurations and infrastructure-as-code practices.

What is "whoAMI" Attack & Mechanism?

To grasp the "whoAMI" attack, it's crucial to understand AMIs. Amazon Machine Images are essentially pre-packaged virtual machine templates. They contain the operating system, application server, and applications needed to launch new virtual servers, known as EC2 (Elastic Compute Cloud) instances in AWS.

AMIs can be either public or private, each identified by a unique AMI ID. When users need to launch an EC2 instance from a public AMI, they typically search the AWS Marketplace catalog for the appropriate AMI ID.

Here's where the vulnerability lies: to ensure you're using a trusted AMI from the AWS Marketplace, your search must include the 'owners' attribute. Failing to specify the owner significantly increases the risk of falling victim to the "whoAMI" name confusion attack.

How Misconfiguration Opens the Door to "whoAMI"?

The "whoAMI" attack preys on common misconfigurations in AWS environments related to AMI selection. Specifically, the vulnerability is amplified by:

• Unsecured AMI Retrieval: Software retrieving AMIs using the ec2:DescribeImages API without specifying an owner. This is the primary attack vector.
• Wildcard Usage: Scripts employing wildcards instead of explicitly defined, secure AMI IDs during AMI selection.
• "Most Recent" Fallacy in Infrastructure-as-Code: Infrastructure-as-code (IaC) tools, like Terraform, sometimes utilize the "most_recent=true" parameter. While convenient, this setting can inadvertently select a malicious AMI if other security measures are lacking.

These conditions create an opportunity for attackers to inject malicious AMIs into the selection process. By naming their AMI to closely resemble a trusted AMI name, attackers can exploit the ambiguity when an owner isn't specified in the ec2:DescribeImages API call. AWS, in the absence of an owner, returns all AMIs matching the name, including the attacker's crafted, malicious AMI.

Furthermore, when "most_recent=true" is active, the system automatically picks the latest AMI matching the filter. If a malicious AMI with a similar name is recently published, it could be mistakenly selected as the "most recent" legitimate AMI.

In essence, attackers only need an AWS account to publish their backdoored AMI publicly in the Community AMI catalog. Strategic naming to mimic legitimate AMIs used by target organizations is the key to a successful "whoAMI" attack. No compromise of the target's AWS account is initially required; the attack relies on exploiting configuration weaknesses in AMI selection.

DataDog estimates, based on their monitoring telemetry, that approximately 1% of organizations they monitor are currently vulnerable to "whoAMI" attacks. However, they emphasize that "this vulnerability likely affects thousands of distinct AWS accounts" globally.

Amazon's Response and Proactive Defenses

Following DataDog's responsible disclosure, Amazon confirmed the vulnerability, acknowledging that even some of their internal non-production systems were susceptible. Amazon acted swiftly, deploying a fix to their systems by September 19th of last year.

Further strengthening defenses, on December 1st, AWS introduced a new security control: 'Allowed AMIs'. This feature empowers AWS customers to create explicit allow lists of trusted AMI providers.

AWS has stated that, to their knowledge, the "whoAMI" vulnerability was contained to security research testing and has not been exploited to compromise customer data in the wild.

To mitigate the risk of "whoAMI" attacks, Amazon strongly advises all customers to adopt the following security best practices:

• Always Specify AMI Owners: When using the ec2:DescribeImages API, diligently include the owners parameter to explicitly define trusted AMI sources.
• Enable 'Allowed AMIs': Leverage the new 'Allowed AMIs' security control to create and enforce allow lists of trusted AMI providers within your AWS accounts. This feature is accessible via the AWS Console under EC2 → Account Attributes → Allowed AMIs.

Leading infrastructure-as-code tools are also incorporating safeguards. Terraform, starting with version 0.15.4 (released November 2024), now issues warnings when "most_recent = true" is used without an owner filter. Future Terraform releases (version 1.0 and beyond) are expected to implement stricter enforcement to prevent this insecure configuration.

Actionable Steps for DevOps and Security Teams

To proactively defend against "whoAMI" attacks, system administrators and DevOps teams should immediately:

1. Audit AMI Configurations: Thoroughly review your infrastructure configurations, including Terraform code, AWS CLI scripts, Python Boto3 scripts, and Go AWS SDK code, to identify and update any instances of insecure AMI retrieval practices. Focus on ensuring the owners filter is consistently used.
2. Implement 'Allowed AMIs': Enable the 'Allowed AMIs' feature in your AWS accounts and create allow lists of trusted AMI providers.
3. Enable AWS Audit and Enforcement Modes: Utilize the 'Allowed AMIs' feature's 'Audit Mode' to identify any existing EC2 instances launched from untrusted AMIs. Subsequently, switch to 'Enforcement Mode' to actively block the use of unauthorized AMIs.
4. Utilize DataDog's Scanner: Leverage the scanner released by DataDog, available on [GitHub Repository (link to be inserted once available)](link to DataDog's GitHub repository if you can find it, otherwise remove this part or search for it). This scanner can help identify vulnerable AWS accounts and instances created from potentially untrusted AMIs.

By taking these proactive steps, organizations can significantly reduce their attack surface and protect their AWS environments from the "whoAMI" name confusion vulnerability. Cloud security requires vigilance and continuous adaptation to emerging threats, and addressing this AMI vulnerability is a critical step in securing your AWS infrastructure.