whoAMI Attack Exploiting AWS EC2 Instances

The “whoAMI” attack is a sophisticated name confusion attack that targets Amazon Web Services (AWS) accounts, particularly those using EC2 instances. Discovered by researchers at Datadog Security Labs, this attack exploits the way software projects retrieve Amazon Machine Image (AMI) IDs to create EC2 instances.

Nature of the Attack

The “whoAMI” attack leverages the name confusion that occurs when developers use broad search criteria to retrieve AMI IDs. By publishing a malicious AMI with a carefully crafted name, attackers can trick infrastructure-as-code tools into selecting and launching their malicious AMIs instead of the intended ones. This leads to unauthorized remote code execution (RCE) capabilities on the compromised EC2 instances.

How the Attack Works

Step-by-Step Exploitation

1. Publishing a Malicious AMI: The attacker publishes a malicious AMI to AWS with a name that matches the pattern specified in the search criteria used by the victim.
2. Misconfigured Software: Developers or DevOps engineers may omit the “owners” attribute when searching for an AMI using the ec2:DescribeImages API call. This omission allows the attacker’s AMI to appear in the search results.
3. Automated Selection: Infrastructure-as-code tools like Terraform, AWS CloudFormation, or other automation scripts use these search results to select the most recent AMI that matches the filter criteria. If the malicious AMI is the most recent, it gets selected.
4. Instance Launch: The automation tools then launch EC2 instances using the malicious AMI, giving the attacker control over the instances.
5. Remote Code Execution: The attacker uses the compromised instance to execute arbitrary code, gain access to sensitive data, or further infiltrate the victim’s AWS environment.

Impact of the Attack

Potential Risks

The successful exploitation of the “whoAMI” attack can lead to several severe consequences, including:

• Unauthorized Access: Attackers can gain access to sensitive information and resources within the compromised AWS environment.
• Data Breach: The attack can lead to the exfiltration of sensitive data, including credentials, configuration files, and user data.
• Service Disruption: Attackers can disrupt services by shutting down or manipulating EC2 instances, leading to downtime and operational impacts.
• Further Attacks: The compromised instances can be used as a foothold for launching further attacks, such as lateral movement within the network, privilege escalation, and the deployment of additional malware.

Mitigation Measures

To protect against the “whoAMI” attack, organizations should implement the following best practices:

1. Specify AMI Owners

• Explicit Filtering: Always specify the “owners” attribute when using the ec2:DescribeImages API call. This ensures that only AMIs from trusted and verified sources are included in the search results.

{ "Filters": [ { "Name": "name", "Values": ["your-ami-name-pattern"] } ], "Owners": ["self", "123456789012"] // Replace with your AWS account ID or trusted sources }

2. Use Allowed AMIs

• AMI Allowlist: AWS provides a feature called Allowed AMIs which allows users to define a trusted allow list of AMIs that can be used within their environment. Implementing an allowlist ensures that only pre-approved AMIs are used for launching EC2 instances.

3. Enhance Security Practices

• Automation Code Review: Regularly review and audit infrastructure-as-code scripts to ensure they follow security best practices, including the use of explicit AMI owners.
• Monitoring and Alerts: Implement continuous monitoring and set up alerts for any suspicious activities, such as the creation of EC2 instances with unexpected AMIs.
• Least Privilege Principle: Apply the principle of least privilege to IAM roles and policies, ensuring that automation scripts and users have only the permissions necessary to perform their tasks.

Final Thoughts

The “whoAMI” attack highlights the importance of precise configuration and security practices when working with AWS EC2 instances. By understanding the mechanics of this attack and implementing the recommended mitigation measures, organizations can protect their AWS environments from potential exploitation and ensure the integrity and security of their cloud infrastructure.