Security researchers discovered six critical vulnerabilities in AWS services that could lead to remote code execution (RCE), data exfiltration, AI model manipulation, and even account takeover.
AWS has fixed the vulnerabilities, which were revealed at the Black Hat security conference today, but the researchers cautioned that the vulnerabilities may exist in other AWS and open source services so they offered general mitigation guidance.
AWS Investigating If Customers Affected by the Vulnerabilities
Aqua Security researchers, led by Yakir Kadkoda, Lead Security Researcher at Aqua’s Team Nautilus research team, discovered the AWS vulnerabilities in February 2024.
The affected AWS services were:
- CloudFormation
- Glue
- EMR
- SageMaker
- ServiceCatalog
- CodeStar
“These vulnerabilities could have impacted any organization in the world that has ever used any of these services,” the researchers said. They detailed a months-long process of working with AWS to resolve the issues, and noted that the cloud service provider is investigating whether attackers have ever used the attack vector previously to exploit the vulnerabilities, “and will contact customers directly in the event they are affected by any of the reported issues.”
Kadkoda told The Cyber Express that working with AWS on the disclosure and mitigation process was a good experience.
“The disclosure process with cloud security providers is very important, and we are always aiming to improve the process,” Kadkoda said. “Sometimes it can be challenging, but in this case we had a very good experience with AWS’s security team. They promptly replied to our disclosure requests and shared information about the gaps and fixes. The security team was professional and handled this diligently and with the proper sense of urgency.”
The research will be detailed in a lengthy blog post to be published later this week during the DEFCON conference; we will link to the post when it goes live.
AWS ‘Shadow Resources’ Attack Vector Detailed
The researchers dubbed the AWS attack vector they discovered “Shadow Resources,” which involves AWS S3 buckets created to support various services, and they found a technique they named “Bucket Monopoly” that “can significantly enhance the success rate of attacks exploiting Shadow S3 bucket resources.”
While using AWS CloudFormation, they noticed that when you use the service via the AWS Management Console for the first time in a new region to create a new stack, the service automatically triggers AWS to create an S3 bucket for storing CloudFormation templates, which users might not be aware of. The service uses the same bucket name across all AWS regions except for the region’s name.
They discovered that attackers could set up buckets in unused AWS regions and wait for a victim to use the CloudFormation service in a new region “to stealthily use the attacker-controlled S3 buckets as part of the CloudFormation service.” They then used that technique across other AWS services.
Attackers could escalate their attack by changing the configuration of the S3 bucket to be publicly accessible. Further, creating a permissive resource-based policy on the S3 bucket could explicitly grant permissions to another IAM principal, specifically the vulnerable AWS service, which would allow the victim’s vulnerable service to be able to read and write data to the attacker-controlled bucket.
After an attacker does all that, the CloudFormation service would find that the bucket already exists and will drop its template file into it, creating an information disclosure vulnerability.
By modifying CloudFormation templates before they are executed, “the technique will be on steroids, because many of the original conditions and prerequisites are no longer necessary for our attack vector to succeed.”
Attackers may be able to create an admin role in a target organization simply by knowing their CloudFormation unique hash, “the most severe outcome we can achieve in the cloud, as it allows us to take over the victim’s account.”
Fortunately, the hash values are random so not easily determined, but the researchers were able to identify numerous hashes used by different AWS accounts simply by utilizing GitHub regex searches, Sourcegraph, scraping open issues, and similar techniques.
“Based on our research, we strongly believe that account IDs should be considered secrets, since there may be other kinds of similar exploits that could be carried out based on knowing an account ID,” they said.
AWS Vulnerabilities Mitigations
The researchers cautioned that the attack vector may apply to other AWS services or to open-source projects, so they recommended three mitigation strategies:
aws:ResourceAccount Condition: To prevent a user or a service role from accessing an untrusted bucket, you can define a scoped policy for the role used or assumed by the service and include the Condition element in the JSON policy. For example, the default service role that EMR Studio creates for users is called AmazonEMRStudio_ServiceRole_{ID} and includes the necessary permissions for the service to operate. In this role, AWS enforces the aws:ResourceAccount condition in the policy to check that the AWS account ID of the S3 bucket used by EMR is owned by the user and not an attacker. Some AWS services require access to resources hosted in another AWS account, so that needs to be checked.
Verify the expected bucket owner: Verify the owner of the S3 bucket using the
Naming S3 buckets: Instead of using predictable or static identifiers in the bucket name, you should generate a unique hash or a random identifier for each region and account, incorporating this value into the S3 bucket name, to protect against attackers claiming your bucket prematurely.