The Orca Security Research Team has now identified a critical vulnerability in theWeb Services AWS Glue service discovered that could allow criminals to create resources and access data from AWS Glue customers. Exploitation was a complex, multi-step process and was ultimately made possible by an internal misconfiguration in AWS Glue. The Glue service has access to large amounts of data, making it an extremely attractive target.
The research team worked with AWS to resolve the issue and to confirm with AWS that there was no unauthorized access to customer accounts. Within hours of reporting the issue, the AWS Glue service team had reproduced and confirmed the findings. A partial fix was deployed globally the next morning, followed by a full fix a few days later.
Anthony Virtuoso, Principal Engineer at AWS, commented on our joint efforts to discover and quickly remediate this vulnerability: “At AWS, security is everyone’s responsibility and top priority – we take vulnerability reports seriously. We spend a lot of time thinking about and implementing security variants to protect our customers. We appreciate it if this work can be supported or improved through security research. Today our valued AWS partner has us [Orca Security] helped identify and mitigate a misconfiguration in our service before it could impact other customers. We greatly appreciate the skill and vigilance of the Orca team and want to thank them for a shared passion to protect AWS customers through their insights.”
AWS Glue is a serverless data integration service that makes it easy to discover, prepare, and combine data for analytics, machine learning, and application development. During their research, the researchers were able to identify a feature in AWS Glue that could be exploited to obtain credentials for a role within the AWS service’s own account, giving them full access to the internal service API. Combined with an internal misconfiguration in Glue’s internal service API, they were able to escalate permissions within the account to the point that we had full access to all resources for the service in the region, including full administrative permissions.
By looking closely at what data could be accessed in the service account, the researchers confirmed that they could access the data of other AWS Glue customers. They used accounts under their control to test and verify that this issue gave them the ability to access data from their other accounts without affecting other AWS customers’ data.
These are some of the things the orca researchers were able to do:
- Assuming roles in AWS customer accounts that are trusted by the Glue service. There is at least one role of this type in every account that uses Glue.
- Querying and modifying AWS Glue service-related resources in a region. This includes but is not limited to metadata for: glue jobs, dev endpoints, workflows, crawlers, triggers and database passwords.
As previously mentioned, all investigations related to this finding were conducted within AWS accounts owned by Orca Security. No other AWS customer accounts or data from other customers were accessed during the research.
The Orca Security Research Team continues to search for such zero-day vulnerabilities in various cloud products and cloud services. The aim is to discover these vulnerabilities before criminals do.
BreakingFormation: Vulnerability in AWS CloudFormation
Orca Security vulnerability researcher Tzah Pahima discovered a vulnerability in AWS that allows disclosure of files and credentials of an internal AWS service. This zero-day vulnerability, which AWS fully mitigated within six days of disclosure, was an XXE (XML External Entity) vulnerability found in the AWS CloudFormation service. This could have been used to sniff out sensitive files on the vulnerable service machine and expose server-side requests (SSRF) to unauthorized disclosure of credentials of internal AWS infrastructure services.
Prior to the public disclosure of the CloudFormation vulnerability, Orca researchers worked with AWS. The goal was to make sure the issue was fixed so businesses would not be compromised.
Findings on the BreakingFormation zero-day vulnerability
Businesses using AWS may be familiar with CloudFormation, the service that allows them to easily provision AWS resources (like EC2 instances and S3 buckets) using templates. With CloudFormation, you can also use API calls to dynamically create and configure resources. The Orca Security Research Team discovered a zero-day vulnerability that allowed a server within CloudFormation to be compromised, which in turn resulted in it running as an AWS infrastructure service.
By exploiting an anomaly in the way CloudFormation renders templates, the researchers were able to trigger an XXE vulnerability, which they used to read files and make HTTP requests on behalf of the server. The server contained several service binaries with server-side AWS logic, as well as configuration files for connecting to internal AWS endpoints and services.
The research team believes that given the data found on the host (including credentials and internal endpoint data), an attacker could exploit this vulnerability to breach tenant boundaries and gain privileged access to all resources in AWS.
Orca researchers did not want to interfere with the operation of the service. To be sure who those credentials belonged to, they used the leaked credentials to provide an S3 URL and then tried using the SSRF to access their own S3 bucket to see which identity was involved. The resulting logs reveal who owns those credentials. The result was an “Access Denied CloudTrail” log entry with the identity given below:
Note: The userIdentity field shows that an AWS service, and not the CloudFormation contracting authority, but an internal service used by AWS, attempted to access the storage bucket.
Fast fix of the vulnerability
Orca immediately reported the issue to AWS, which acted quickly to fix it. In less than 25 hours, the AWS security team coded a fix that reached all AWS Regions within six days.
Researchers from Orca Security helped test the fix to ensure this vulnerability was addressed correctly and were able to verify that it is no longer exploitable.