whoAMI: Discovering and exploiting a large-scale AMI name confusion attack

whoAMI: Discovering and exploiting a large-scale AMI name confusion attack

Speakers: Seth Art, Security Advocate and Researcher, DataDog

Conference: Cloud Village

YouTube: https://www.youtube.com/watch?v=-yjcRS4GhLo

Overview

In this compelling talk at Cloud Village, Seth Art, a Security Advocate and Researcher at DataDog, unveiled a significant security vulnerability dubbed "whoAMI" – a large-scale name confusion attack targeting Amazon Machine Images (AMIs). This attack, which leverages insecure configurations in Infrastructure-as-Code (IaC) tools and AWS SDKs, has the potential to grant attackers remote code execution (RCE) within victim AWS accounts. Art's research highlights a critical supply chain risk where automated EC2 deployments, if not properly secured, can inadvertently pull and execute malicious AMIs published by adversaries.

The core of the "whoAMI" attack lies in the optionality of the owners attribute when dynamically looking up AMIs by name. When users or automated systems fail to specify a trusted owner, an attacker can publish an AMI with a matching name, leading the victim's deployment process to select the malicious image instead of the legitimate one. Art's work not only demonstrates the exploitability of this flaw but also uncovers its widespread prevalence, estimating that thousands of AWS accounts globally are currently vulnerable. The talk culminates in practical detection and prevention strategies, including the newly released AWS Allowed AMIs feature and updates to the Terraform AWS provider, alongside the introduction of the open-source Cloud Image Investigator tool to enhance AMI scrutiny.

This research is particularly impactful because it shifts the focus from traditional perimeter defenses to the often-overlooked supply chain aspects of cloud infrastructure. By demonstrating how a seemingly innocuous configuration oversight can lead to full compromise, Art underscores the importance of the principle of least privilege and robust validation mechanisms for all cloud resources, especially those consumed from shared catalogs. The "whoAMI" attack serves as a stark reminder that even trusted cloud providers' ecosystems require diligent security practices from their users to prevent sophisticated forms of compromise.

Background

▶ Watch: Introduction to AMI Name Confusion Attack (0:00)

The foundation of the "whoAMI" attack lies in the mechanism by which Amazon Web Services (AWS) customers deploy EC2 instances using Amazon Machine Images (AMIs). An AMI serves as a template for the root volume of an instance, specifying the operating system, application server, and applications. In the AWS console, users can browse a catalog of AMIs, which includes a "Community AMI" section. A crucial warning in this section states, "Anybody can publish an AMI to this catalog. So use caution when picking which of these results you are going to use." AWS attempts to mitigate this risk by displaying a "verified provider" banner for AMIs published by accounts with the owner alias of "Amazon" or "AWS marketplace." However, this verification is at the account level, not the AMI level, leaving a gap for confusion.

The speaker's journey to discovering this vulnerability began during his time as a penetration tester, where he developed CloudFoxible, an open-source cloud Capture The Flag (CTF) environment. CloudFoxible uses Terraform to deploy intentionally vulnerable AWS infrastructure. When configuring EC2 instances in Terraform, a common pattern is to use the aws_ami data source to dynamically look up an AMI based on a name pattern, rather than hardcoding a region-specific AMI ID. For example, a configuration might search for name = "Amazon Linux 2023*". Crucially, CloudFoxible's configuration included the owners = ["Amazon"] attribute to ensure only verified AMIs were selected. This led to Art's "aha moment": what if the owners attribute was omitted? If it were optional, an attacker could publish a malicious AMI with a matching name, and a victim's Terraform deployment, seeking the "most recent" match, could inadvertently select the attacker's image.

This isn't the first time AMI name confusion has been explored. A historical precedent dates back to Defcon 17 in 2009, where Harun Mir and Marco Slavierro demonstrated a similar attack. They targeted AWS console users by exploiting the fact that community AMI search results were sorted by AMI ID in ascending order. By repeatedly creating and discarding AMIs to get a low AMI ID, they managed to get their malicious Fedora 11 AMI into the top five search results, leading to its adoption by unsuspecting users. While their technique relied on a smaller AMI ID namespace and fewer public AMIs—making it less viable today—it established the concept of AMI name confusion.

Fast forward to 2018, the HashiCorp security team identified a vulnerability in Packer (another HashiCorp utility for image creation) where selecting a base AMI without specifying an owner could lead to a confusion attack. This was quickly corroborated by user reports, including one instance where a Ubuntu AMI was replaced with one containing a Monero miner. HashiCorp secured a CVE-2018-15747 and assigned it to the AWS CLI, arguing that the CLI allowed EC2 DescribeImages calls without an owner flag. AWS, however, deemed this a "won't fix," citing valid use cases for broad image listing. Despite this, both the Packer and Terraform aws_ami data sources were updated in 2018 to make the owners attribute required, seemingly closing the loophole.

However, the story took an unfortunate turn. In 2020, a user politely requested the owners attribute be made optional again, citing convenience for cases where the AMI ID was known but the owner ID was not readily available. The open-source community initially resisted, referencing the historical CVE. But in 2022, the request was made again, and this time, the Terraform AWS provider maintainers relented, making the owners attribute optional once more. This decision reopened the door for the "whoAMI" attack, making it possible for vulnerable Terraform configurations to exist from 2022 onwards, setting the stage for Art's research into its current prevalence and exploitability.

Key Findings

▶ Watch: Discovery of vulnerability: Terraform's optional 'owners' attribute (3:45)

Seth Art's "whoAMI" research yielded several critical findings, illuminating the prevalence and potential impact of this name confusion attack:

1. Widespread Vulnerability: Through extensive scanning of public GitHub repositories using specific search criteria (looking for name filters with most_recent = true but without owners or equivalent owner_alias filters), Art identified hundreds of potentially vulnerable Terraform configurations. Extrapolating this data to DataDog's customer base, where 2-4% of customers were found to be vulnerable in any given month, he estimates that thousands of AWS accounts worldwide are susceptible to the "whoAMI" attack. This highlights a significant, large-scale security blind spot.

1. AWS Internal Systems Compromise (Hypothetical & Remedied): In a coordinated experiment with AWS's Vulnerability Disclosure Program (VDP), Art and his team investigated whether any AWS internal systems were vulnerable. By publishing malicious AMIs and monitoring for sharedSnapshotVolumeCreated CloudTrail events where the user identity type was AWS service, they detected 70,000 such events. This led to the discovery of two internal, non-production AWS systems that were insecurely performing AMI lookups. AWS promptly fixed these systems and conducted further scans, demonstrating the severity of the issue even within AWS's own infrastructure. This collaboration underscores the importance of VDPs in identifying and addressing systemic vulnerabilities.

1. Third-Party CI/CD Platform Vulnerability (Cirrus CI): Art discovered a documented anti-pattern in Cirrus CI, a continuous integration platform. Their official documentation for self-hosted runners indicated an AMI lookup using a name filter without specifying an owner. Art successfully demonstrated a proof-of-concept where he created a Cirrus CI account, configured a self-hosted runner to assume a role into his AWS account, and then published a malicious AMI matching the documented name pattern. When Cirrus CI's backend executed the build task, it pulled the attacker's AMI, leading to RCE on the self-hosted runner. This exploit allowed Art to dump environment variables, revealing decrypted AWS secret access keys, access key IDs, and Docker passwords used by Cirrus CI customers. This finding exposes a critical supply chain risk through third-party services, where an attacker could backdoor build artifacts or upload malicious containers to repositories like DockerHub. Cirrus CI took the disclosure seriously and deployed a fix within 12 hours.

These findings collectively underscore that the "whoAMI" attack is not merely theoretical but a practical and widespread threat affecting a broad spectrum of AWS users, from individual developers to major cloud service providers and even internal AWS systems.

Technical Deep Dive

▶ Watch: Attacker publishes malicious AMI for name confusion (5:40)

The "whoAMI" attack fundamentally exploits a weakness in how Amazon Machine Images (AMIs) are resolved by name, particularly within automated deployment contexts like Terraform or custom scripts using the AWS SDK/CLI.

At its core, the vulnerability arises when an EC2 DescribeImages API call is made with a Name filter but without adequately restricting the Owners attribute. In Terraform, this manifests in the aws_ami data source. A typical vulnerable configuration might look like this:

Here, most_recent = true instructs Terraform to pick the newest AMI matching the Amazon Linux 2023* name pattern. Crucially, the owners attribute is omitted. By default, EC2 DescribeImages will return public AMIs, shared AMIs, and AMIs owned by the requesting account. If an attacker publishes a malicious AMI with a name like Amazon Linux 2023 - Malicious Edition (or even a subtly different name that still matches the wildcard) and ensures it's more recent than the legitimate one, the victim's Terraform plan or apply operation will dynamically resolve to the attacker's AMI ID.

The attacker's process involves:

1. Identifying a target name pattern: For instance, Amazon Linux 2023*.
2. Creating a malicious AMI: This AMI would contain a payload designed for remote code execution (RCE) upon instance startup. A common technique is to embed a command and control (C2) callback binary or script within the AMI's user data or as part of the operating system's boot sequence.
3. Publishing the AMI: The attacker registers their malicious AMI, potentially sharing it specifically with target victim accounts rather than making it fully public to avoid broader detection. The key is that the AMI's name matches the victim's search criteria and, if most_recent is used, is newer than legitimate alternatives.

Once the victim's EC2 instance is launched using this malicious AMI, the embedded payload executes, providing the attacker with RCE. The talk demonstrated this using the Sliver C2 framework (though Metasploit or similar could be used). With RCE, the attacker gains access to any IAM permissions assigned to the EC2 instance via its instance profile. This is where the principle of least privilege becomes paramount. If the instance profile is overly permissive, the attacker can escalate privileges, for example, by listing S3 buckets, viewing their contents, or interacting with other AWS services. The demonstration showed an attacker listing a "super secret stuff bucket" and retrieving sensitive objects.

The historical context of CVE-2018-15747 is important here. While assigned to the AWS CLI, it highlighted the underlying issue of DescribeImages being callable without an owner filter. Although AWS deemed it a "won't fix" for the CLI due to valid use cases, HashiCorp initially made the owners attribute mandatory in both Packer and Terraform's aws_ami data source. The subsequent decision in 2022 to make owners optional again in Terraform's AWS provider (versions 5.x and below) directly re-introduced this vulnerability window.

Beyond Terraform, the speaker emphasized that this anti-pattern can occur in any programming language with an AWS SDK or even in shell scripts using the AWS CLI. Any code that performs an EC2 DescribeImages call using a name filter (including name_regex) without specifying a trusted Owner or OwnerAlias is potentially vulnerable. The vulnerability summary is concise: "If you are insecurely searching for the AMI ID and then you use that ID to ultimately create an EC2 instance, you are vulnerable to this attack." This extends beyond direct EC2 instance creation to other services that consume AMI IDs, such as Auto Scaling Groups (ASG) launch configurations or CloudFormation templates.

The Cirrus CI exploitation provided a concrete example of this in a third-party service context. Cirrus CI's backend, when provisioning self-hosted runners, made an insecure EC2 DescribeImages call. By controlling the malicious AMI, the attacker gained RCE on the runner. A clever trick used in Kubernetes breakout research was applied: printing all environment variables. This revealed highly sensitive decrypted secrets, including AWS secret_access_key, access_key_id, and docker_password, directly demonstrating the critical impact of such a supply chain compromise on development pipelines and build artifacts.

Demo / Proof of Concept

▶ Watch: Victim unknowingly deploys attacker's AMI via Terraform (6:20)

Seth Art effectively demonstrated the "whoAMI" attack through two distinct proof-of-concept scenarios: a direct exploitation of a vulnerable Terraform configuration and a more sophisticated attack against the Cirrus CI platform.

1. Terraform Exploitation:

The first demo showcased the attack from both the victim's and attacker's perspectives, switching back and forth to illustrate the flow:

• Victim's Initial Vulnerable State: The victim uses a Terraform configuration that dynamically looks up an AMI by name (name = "Amazon Linux 2023*", most_recent = true) but critically omits the owners attribute. Initially, a terraform apply correctly provisions an EC2 instance using a legitimate Amazon Linux 2023 AMI from the AWS Marketplace, as it's the most recent and only matching legitimate option. The victim is vulnerable but hasn't been attacked yet.

• Attacker Stages the Attack: The attacker identifies the name pattern the victim is using. They then create a malicious AMI, embedding a command and control (C2) callback payload into it, designed to execute upon instance startup. To avoid public exposure, the attacker publishes this AMI and specifically shares it only with the victim's AWS account. The attacker ensures this malicious AMI is newer than any legitimate AMIs matching the victim's filter, making it the most_recent.

• Victim's Compromise: The victim, unaware of the staged attack, performs another terraform apply. This time, Terraform's dynamic lookup for Amazon Linux 2023* with most_recent = true resolves to the attacker's malicious AMI ID. Upon approval and instance instantiation, the attacker's C2 payload executes.

• Attacker Gains RCE and Escalates: From the attacker's perspective, using a C2 framework like Sliver, a shell immediately connects back from the victim's newly launched EC2 instance. The attacker now has remote code execution within the victim's AWS account. The demo proceeds to illustrate privilege escalation: the attacker checks for an instance profile, finds it, and then attempts to list S3 buckets. If the instance profile grants s3:ListBuckets and s3:GetObject permissions, the attacker can list sensitive buckets (e.g., "super secret stuff bucket") and retrieve their contents, demonstrating the full impact of the compromise.

2. Cirrus CI Exploitation:

The second demo highlighted a supply chain attack against a third-party CI/CD platform:

• Cirrus CI's Insecure Configuration: Art discovered that Cirrus CI's documentation for self-hosted runners indicated an AMI lookup using only a name filter, without specifying an owner, making it vulnerable to the "whoAMI" attack.

• Attacker's Setup: Art created a Cirrus CI account and a repository. He configured Cirrus CI's backend to assume an IAM role into his AWS account to provision a self-hosted runner. Crucially, the configuration specified a name filter for the runner's AMI. He also noted that Cirrus CI often handles encrypted secrets (e.g., AWS credentials, Docker passwords) that are decrypted on the self-hosted runner during task execution.

• Exploiting Cirrus CI: Art committed a change to his repository, triggering a CI task. As expected, Cirrus CI's backend, performing the insecure AMI lookup, selected the attacker's malicious AMI. This AMI was designed to provide a C2 callback.

• Secret Exfiltration: Once the attacker gained RCE on the self-hosted runner, instead of just exploring IAM permissions, Art used a technique learned from Kubernetes breakout research: he printed the environment variables associated with every process running on the self-hosted runner. This revealed the decrypted AWS secret access key, access key ID, and Docker password as environment variables. This demonstrated a direct exfiltration of sensitive credentials, proving that an attacker could use this vulnerability to compromise build pipelines, upload malicious containers to DockerHub, or otherwise tamper with build artifacts.

Both demos powerfully illustrated the ease and impact of the "whoAMI" attack, from direct AWS account compromise to critical supply chain vulnerabilities in third-party services.

Defensive Implications

▶ Watch: Post-exploitation: Accessing instance IAM permissions (7:50)

Defending against the "whoAMI" attack requires a multi-faceted approach, combining proactive prevention, robust detection, and thorough auditing. Seth Art outlined several key strategies for defenders:

1. AWS Allowed AMIs Feature (Prevention - AWS Native):

This is the most impactful and recommended defense. AWS recently released the Allowed AMIs feature, which enables organizations to create an explicit allow list of trusted accounts that can provision AMIs in their environment.

• Configuration: This feature can be configured per account and per region. It supports specifying explicit account IDs or using aliases like Amazon (which covers all AWS-verified accounts) and AWS marketplace.
• Declarative Policies for EC2: To scale this across an organization, AWS also provides declarative policies for EC2. This allows administrators to apply Allowed AMIs settings across an entire AWS Organization, Organizational Unit (OU), or specific accounts, similar to an AWS Service Control Policy (SCP).
• Audit Mode: Crucially, the Allowed AMIs feature supports an audit mode before full enforcement. This allows organizations to monitor for violations and identify legitimate usage patterns that might be blocked before enabling the feature, minimizing disruption. Art strongly recommends enabling this feature immediately in all managed AWS accounts.

1. Terraform AWS Provider Fix (Prevention - IaC Tooling):

The Terraform AWS provider team addressed the owners attribute optionality issue with a two-pronged approach:

• Version 5.77: Introduced a warning for users configuring aws_ami data sources with most_recent = true but without specifying owners or owner_alias.
• Version 6 (released ~1 month prior to the talk): Made this configuration a blocking error. Terraform apply operations will now fail if a vulnerable combination is detected. For legitimate, albeit less secure, use cases, a new attribute ignore_error can be explicitly set to bypass the block, effectively allowing users to "shoot themselves in the foot" if they choose. This intelligent logic ensures owners is still technically optional for advanced scenarios but defaults to secure behavior. Defenders should upgrade their Terraform AWS provider to version 6 or higher.

1. Detection in Code (IaC Scanning):

Organizations should proactively scan their Infrastructure-as-Code repositories for vulnerable patterns.

• SEPG Rules: Custom SEPG rules (or similar static analysis tools) can be written to identify Terraform aws_ami data sources that use name filters and most_recent = true but lack the owners or owner_alias attributes.
• GitHub/Sourcegraph Searches: The same search criteria used by Art (e.g., name filter, most_recent, no owners) can be adapted to scan private GitHub or Sourcegraph instances. This helps identify existing vulnerable configurations that need remediation.

1. Detection via CloudTrail (Runtime Detection):

For runtime detection of exploitation attempts or vulnerable behavior, AWS CloudTrail is the source of truth.

• High-Fidelity Detection: Art proposed a high-fidelity detection rule: look for insecure DescribeImages events (i.e., those without an owners filter) followed by an RunInstances or CreateLaunchConfiguration event by the same principal within a short timeframe (e.g., 5-10 minutes). This pattern strongly suggests a dynamic lookup leading to instance creation, and if the lookup was insecure, it warrants immediate investigation.

1. Cloud Image Investigator (Threat Intelligence & Auditing Tool):

Seth Art developed and open-sourced Cloud Image Investigator (investigator.cloud) as a "VirusTotal or URLScan for community AMIs." This tool helps defenders make informed decisions about AMIs:

• Historical View: Unlike EC2 DescribeImages, it provides a historical view of community AMIs, showing when they were available.
• Owner Vetting: It provides more context about AMI owners, such as the number of AMIs they host, their naming conventions, and publication history, helping to build trust or identify suspicious activity.
• Parent Lineage: It leverages AWS's parent_ami attribute (exposed since 2024) to trace the lineage of an AMI back to its source, even if modified.
• File Hashing & Difference Analysis: By integrating with Edward and Mate's CloudQuarry tool, Cloud Image Investigator can hash every file on scanned AMIs. This allows for a "diff" functionality, showing exactly what files have changed between a child AMI and its parent. The demo showed how this could quickly reveal suspicious additions like Tidecoin miner scripts and binaries, providing crucial intelligence without ever executing the AMI.
• Hash/Filename Lookup: The tool also allows searching for specific file hashes or filenames across its database of scanned AMIs, aiding in threat intelligence and incident response.

1. Principle of Least Privilege (IAM):

Beyond preventing the initial RCE, it is critical to adhere to the principle of least privilege for IAM roles assigned to EC2 instances. Even if an attacker gains RCE, tightly scoped permissions can severely limit their ability to escalate privileges, access sensitive data, or move laterally within the AWS environment. This serves as a crucial secondary defense layer.

By implementing these comprehensive defenses, organizations can significantly reduce their exposure to AMI name confusion attacks and bolster their overall cloud supply chain security.

Key Takeaways

• Widespread Vulnerability: The "whoAMI" attack, exploiting insecure AMI lookups by name without owner validation, is a current and widespread threat, potentially affecting thousands of AWS accounts globally due to historical changes in IaC tool behavior.
• Prioritize AWS Allowed AMIs: Immediately implement the AWS Allowed AMIs feature using declarative policies for EC2. Utilize audit mode first to identify legitimate usage patterns before full enforcement, significantly thwarting this attack vector.
• Update Terraform AWS Provider: Ensure your Terraform AWS provider is updated to version 6.x or higher to benefit from the blocking error for vulnerable aws_ami data source configurations. For older versions, explicitly specify the owners attribute.
• Scan IaC and Monitor CloudTrail: Proactively scan all Infrastructure-as-Code repositories for vulnerable AMI lookup patterns. Implement CloudTrail detections for insecure DescribeImages events followed by instance creation from the same principal within a short timeframe.
• Vet Community AMIs: Utilize tools like the open-source Cloud Image Investigator to gain deeper insights into community AMIs, including their lineage, owner history, and file differences, before deployment. This helps identify malicious modifications or suspicious origins.
• Embrace Least Privilege for All Workloads: The attack underscores that supply chain risks mean any workload, not just publicly exposed ones, can be compromised. Strictly apply the principle of least privilege to IAM roles associated with EC2 instances to limit the impact of successful RCE.

About the Speaker(s)

Seth Art is a Security Advocate and Researcher at DataDog. With a distinguished career spanning 15 years in penetration testing, he spent five of those years spearheading the cloud penetration testing practice at Bishop Fox. His deep expertise in cloud security led him to create CloudFoxible, an open-source cloud Capture The Flag (CTF) environment designed to educate and train individuals in the art of cloud penetration testing. Art's research often focuses on uncovering novel attack techniques and developing practical defensive strategies for cloud environments, as exemplified by his work on the "whoAMI" attack.