Jan 13, 2022
Orca Security’s vulnerability researcher, Tzah Pahima, discovered a vulnerability in AWS allowing file and credential disclosure of an AWS internal service. This zero-day, which AWS completely mitigated within 6 days of our submission, was an XXE (XML External Entity) vulnerability found in the CloudFormation service. This could have been used to leak sensitive files found on the vulnerable service machine and make server-side requests (SSRF) susceptible to the unauthorized disclosure of credentials of internal AWS infrastructure services.
At Orca Security, our customers are our priority in everything we do, including vulnerability research. Our primary goal is always to protect you and your cloud estate. Prior to this post, and before announcing the CloudFormation vulnerability publicly, our researchers worked with AWS to ensure that the issue was fixed to avoid putting our customers — and AWS’ customers — at risk.
If you use AWS, then you might be familiar with CloudFormation, the service that enables you to easily provision AWS resources (such as EC2 instances and S3 buckets) using templates. CloudFormation also allows you to use API calls to dynamically create and configure resources. The Orca Security Research Team discovered a zero-day vulnerability that allowed us to compromise a server within CloudFormation, which in turn, led to us running as an AWS infrastructure service.
Leveraging an anomaly in the way that CloudFormation renders templates allowed us to trigger an XXE vulnerability, which we used to read files and perform HTTP requests on behalf of the server. The server contained multiple service binaries containing AWS server-side logic, as well as configuration files for connecting to internal AWS endpoints and services.
Our research team believes, given the data found on the host (including credentials and data involving internal endpoints), that an attacker could abuse this vulnerability to bypass tenant boundaries, giving them privileged access to any resource in AWS.
This is what a file disclosure looks like (AWS employees’ information on the right side of the screen was redacted):
We didn’t want to interfere with the service’s operation. To ensure to whom these credentials belonged, but in a non-invasive way, we used the leaked credentials to presign an S3 URL and then used the SSRF to try and access our own S3 bucket to see which identity was involved. The resulting logs tell us who these credentials belong to. The result was an Access Denied CloudTrail log entry, with the identity shown below:
Note: The “userIdentity” field shows that an AWS service, not CloudFormation’s public principal but rather an internal service used by AWS, tried to access our storage bucket.
We immediately reported the issue to AWS, who acted quickly to fix it. The AWS security team coded a fix in less than 25 hours, and it reached all AWS regions within 6 days.
Orca Security researchers helped test the fix to ensure that this vulnerability was correctly resolved, and we were able to verify that it could no longer be exploited.
The Orca Security Research Team is dedicated to ethically advancing cloud security in close partnership with the cloud service platforms that we help protect.
If you’d like to learn more about Orca Security I invite you to experience our tech and talent first-hand with a no-obligation, free cloud risk assessment. You’ll get complete visibility into your public cloud, a detailed risk report with an executive summary, and time with our cloud security experts.
Discover Your Cloud Vulnerabilities In Minutes
Scan your entire AWS, Azure, and Google Cloud environments for vulnerabilities with Orca Security’s free, no obligation risk assessment.
AWS provides an array of documentation for its CloudFormation service. A helpful re is its CloudFormation Documentation home page, providing links to a user guide and corresponding GitHub repository. There are also several CloudFormation res and tutorials that cover in-depth topics and applications, including an API reference, the AWS CloudFormation in the AWS CLI reference, the AWS CloudFormation Guard User Guide, and a User Guide for Extension Development.
AWS provides an IAM web service; it can be used to administer identity and access management controls, helping users control secure access to their AWS res. Controls can be set to authenticate who is signed in, as well as who is authorized (by way of permissions) to use AWS res.
AWS provides sample CloudFormation templates that can be used as is, or referenced to create a customized template. A CloudFormation template has predefined CloudWatch metric filters and alarms so you receive email notifications when specific, security-related API calls are made in your AWS account.
Translated for international language users, sample templates quickly enable an administrator’s ability to directly launch an AWS CloudFormation stack and deploy res.
The CloudWatch Alarm type [AWS::CloudWatch::Alarm] defines an alarm and associates it with a specified metric or metric math expression. When you create such an alarm, its default state is set to INSUFFICIENT_DATA. Associated actions are correspondingly executed when you set its state.
Its state is left unchanged if you update an existing alarm, but the update completely overwrites the previous alarm configuration.
When configuring AWS CloudTrail to deliver log files to a CloudWatch log group, an admin can create CloudWatch metric filters and alarms to monitor events. So if an alarm is needed for an event (e.g., an Amazon EC2 RunInstances operation), CloudWatch can send notifications when that occurs in the configured account. An admin can create filters and alarms separately or use the AWS CloudFormation template to define them all at once.
Tzah Pahima is a Cloud Security Researcher at Orca Security. Follow him on Twitter @tzahpahima