New “whoAMI” Attack Leverages AWS AMI Name Confusion for Remote Code Execution

New Cybersecurity Threat: “whoAMI” Name Confusion Attack Exposed

Cybersecurity researchers have uncovered a novel name confusion attack known as “whoAMI.” This vulnerability allows malicious actors to execute code within Amazon Web Services (AWS) accounts simply by publishing an Amazon Machine Image (AMI) with a specific name. This technique is particularly concerning because it has the potential to compromise multiple accounts if deployed at scale.

Seth Art, a researcher at Datadog Security Labs, highlighted the risks in a report shared with The Hacker News, stating that the improperly configured software found in numerous private and open-source repositories could fall victim to this attack. The foundation of this technique is similar to a supply chain attack, where attackers publish a harmful resource and deceive misconfigured applications into utilizing it instead of the legitimate resource.

The nature of the attack leverages the accessibility of AMIs, which are virtual machine images essential for booting Elastic Compute Cloud (EC2) instances on AWS. Attackers can exploit the ec2:DescribeImages API by omitting the “–owners” attribute when searching for AMIs. This oversight by developers creates a perfect storm: when a victim queries for an AMI ID using specific filters, they might inadvertently select an attacker’s malicious AMI, thus creating an EC2 instance that grants remote code execution (RCE) capabilities to the attacker.

To successfully execute the attack, three primary conditions must be satisfied during the victim’s retrieval of the AMI ID via the API: the use of a name filter, failure to specify ownership parameters, and attempting to retrieve the most recent image from the results. This combination allows the attacker to present a doppelgänger AMI that can then be utilized to initiate various malicious activities on the victim’s instance.

Attackers only require an AWS account to publish their compromised AMI to the public Community AMI catalog, making the attack accessible. Art drew comparisons to dependency confusion attacks, emphasizing that while both share similarities, the “whoAMI” attack specifically revolves around virtual machine images rather than software dependencies like pip packages.

Data from Datadog indicates that approximately 1% of the organizations they monitor fell victim to the whoAMI attack. Their research has identified public instances of several coding languages, including Python, Go, Java, Terraform, and Bash, that failed to implement adequate safeguards against this vulnerability.

Following a responsible disclosure made on September 16, 2024, by the researchers, AWS acted swiftly, addressing the vulnerability within three days. In their official response, AWS stated that thorough investigations revealed no evidence of the technique being exploited outside of the authorized researchers. They reassured their customer base that all AWS services were functioning as intended.

AWS pointed out that customers retrieving AMI IDs without specifying ownership values could be susceptible to this vulnerability. In December 2024, the introduction of “Allowed AMIs,” a new account-wide setting, aims to bolster governance over AMI usage in AWS. Clients are encouraged to evaluate and implement this new security control to mitigate exposure.

As an ongoing response to the threat, HashiCorp Terraform has begun issuing warnings to users who employ “most_recent = true” without an ownership filter. This warning is expected to be upgraded to an error in future versions, reinforcing the importance of stringent security practices among developers.

Overall, the whoAMI attack underscores the need for vigilant cybersecurity practices, particularly in cloud environments. By understanding the tactics and techniques outlined in the MITRE ATT&CK framework, business owners can better prepare against such vulnerabilities, enhancing their defensive strategies in an increasingly complex threat landscape.

Source link