whoAMI attack could allow remote code execution within AWS account
Researchers warn that the whoAMI attack lets attackers publish an AMI with a specific name to execute code in an AWS account.
Cybersecurity researchers at Datadog Security Labs devised a new name confusion attack technique, called whoAMI, that allows threat actors to execute arbitrary code execution within the Amazon Web Services (AWS) account by publishing an Amazon Machine Image (AMI) with a specific name.
The researchers warn that, at scale, this attack could impact thousands of AWS accounts, with around 1% of organizations estimated to be vulnerable.
An Amazon Machine Image (AMI) is a virtual machine image used to launch Elastic Compute Cloud (EC2) instances. Users can specify an AMI by ID or search for the latest version via AWS’s API.
Datadog Security Labs pointed out that anyone can publish an AMI to the Community AMI catalog, for this to determine if searching the catalog for an AMI ID, users will get an official AMI and not one published by a malicious actor he can specify the owners
attribute.
Specifyng the owners
attribute when searching for AMIs could ensure results come from verified sources like Amazon or trusted providers.
If the owners
attribute is omitted in an AMI search, an attacker can publish a malicious AMI with a recent date, making it the top result in automated queries.
The attack occurs when a victim uses the name filter, fails to specify the owner, owner-alias, or owner-id parameters, and retrieves the most recently created image.
“To exploit this configuration, an attacker can create a malicious AMI with a name that matches the above pattern and that is newer than any other AMIs that also match the pattern. The attacker can then either make the AMI public or privately share it with the targeted AWS account.” reads the advisory published by the company. This is what the attack looks like if executed by a malicious actor:

“For example, to exploit the wildcard expansion pattern above, an attacker can publish a malicious AMI with the name ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-whoAMI
, and make it public. It’s that simple!””
The researchers published a video PoC of the attack, they created an AMI with a C2 backdoor preinstalled (Attacker AWS Account ID: 864899841852
, Victim AWS Account ID: 438465165216
).
“This research demonstrated the existence and potential impact of a name confusion attack targeting AWS’s community AMI catalog. Though the vulnerable components fall on the customer side of the shared responsibility model, there are now controls in place to help you prevent and/or detect this vulnerability in your environments and code.” concludes the report. “Since we initially shared our findings with AWS, they have released Allowed AMIs, an excellent new guardrail that can be used by all AWS customers to prevent the whoAMI attack from succeeding, and we strongly encourage adoption of this control. This is really great work by the EC2 team!”
As of last November, HashiCorp addressed the issue in terraform-aws-provider 5.77, issuing a warning when “most_recent=true” is used without an owner filter. This will become an error in version 6.0.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
Pierluigi Paganini
(SecurityAffairs – hacking, whoAMI)