whoAMI Attacks: Exploiting Amazon EC2 Instances for Code Execution

whoAMI attacks allow hackers to gain code execution on Amazon EC2 instances by exploiting flaws in AMI selection. Attackers publish malicious AMIs with names mimicking legitimate ones, tricking systems into launching them. AWS has issued a fix, but updates are crucial.
whoAMI Attacks: Exploiting Amazon EC2 Instances for Code Execution
Table of Contents
    Add a header to begin generating the table of contents

    Security researchers have uncovered a critical vulnerability, dubbed “whoAMI” attacks, allowing attackers to gain code execution on Amazon EC2 instances. This attack cleverly exploits a name confusion technique, targeting how software retrieves Amazon Machine Image (AMI) IDs.

    DataDog researchers, who initially discovered the flaw in August 2024, demonstrated how attackers can achieve code execution within AWS accounts. The vulnerability stems from insecure practices in how software retrieves AMIs.

    Specifically, the problem arises when software uses the ec2:DescribeImages API without specifying an owner, or uses wildcards instead of specific AMI IDs. This becomes even more problematic when infrastructure-as-code tools like Terraform use the “most_recent=true” parameter, automatically selecting the latest AMI matching the filter—which could easily be a malicious one.

    “The retrieval of AMIs by software using the ec2:DescribeImages API without specifying an owner,” explains the DataDog report, “The use of wildcards by scripts instead of specific AMI IDs…These conditions allow the attackers to insert malicious AMIs in the selection process by naming the resource similarly to a trusted one.”

    How the Attack Works and its Impact

    Essentially, an attacker only needs an AWS account to publish a backdoored AMI to the public Community AMI catalog. By choosing a name that mimics legitimate AMIs, they can trick systems into launching their malicious instance. This attack doesn’t require breaching the target’s AWS account.

    Amazon acknowledged the vulnerability and released a fix in September 2024. However, the threat persists in environments where organizations haven’t updated their code. According to DataDog’s telemetry, approximately 1% of the organizations they monitor remain vulnerable, potentially affecting thousands of AWS accounts.

    Amazon’s Response and Mitigation Strategies

    To address this, Amazon introduced a new security control called ‘Allowed AMIs,’ enabling customers to create an allow list of trusted AMI providers. This feature is accessible via the AWS Console: EC2 → Account Attributes → Allowed AMIs.

    Furthermore, Terraform version 5.77 began issuing warnings when “most_recent = true” is used without an owner filter. Stricter enforcement is planned for future releases.

    System administrators are urged to audit their configurations and update their code (Terraform, AWS CLI, Python Boto3, and Go AWS SDK) to ensure safe AMI retrieval. Enabling AWS Audit Mode and switching to ‘Enforcement Mode’ within ‘Allowed AMIs’ helps identify and block untrusted AMIs. DataDog has also released a scanner to help identify vulnerable instances, available on GitHub.

    While Amazon assures that the vulnerability wasn’t exploited beyond the researchers’ tests, proactive mitigation is crucial to prevent future whoAMI attacks on Amazon EC2 instances. The key to prevention lies in specifying AMI owners when using the ec2:DescribeImages API and enabling the ‘Allowed AMIs’ feature.

    Related Posts