This article is more than 1 year old
Orca Security tells AWS fail tale with a happy ending
Those critical AWS flaws that exposed data and broke tenant separation? All fixed!
Two serious security vulnerabilities were recently found in AWS services, but because they were responsibly reported and the cloud biz responded quickly, no harm appears to have been done.
On Thursday, Orca Security published details about Superglue and BreakingFormation, vulnerabilities in AWS Glue and AWS Cloud Formation that allowed attackers to access data for other customers and to access files and make server-side requests to internal web services infrastructure.
AWS Glue is a serverless data integration service for preparing data for subsequent processing. But thanks to an internal misconfiguration, Orca Security researchers were able to obtain more information than should have been allowed.
"During our research, we were able to identify a feature in AWS Glue that could be exploited to obtain credentials to a role within the AWS service’s own account, which provided us full access to the internal service API," explained Yanir Tsarimi in a blog post.
"In combination with an internal misconfiguration in the Glue internal service API, we were able to further escalate privileges within the account to the point where we had unrestricted access to all resources for the service in the region, including full administrative privileges."
By interacting with the AWS command line interface, the researchers were able to see configuration data associated with the Glue default account – which can be delegated to perform actions on behalf of the AWS account holder – and from that were able to infer how to access data controlled by other AWS customers.
They could assume roles defined in AWS customer accounts that were tied to the Glue service and could also query and alter Glue services in a given region.
Then there was the flaw affecting Cloud Formation, which allows AWS customers to programmatically provision other AWS services.
Orca Security bug sleuth Tzah Pahima found an XML External Entity vulnerability that allowed the bypassing of tenant boundaries and conferred privileged access to AWS resources.
"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," explained Pahima. "The server contained multiple service binaries containing AWS server-side logic, as well as configuration files for connecting to internal AWS endpoints and services."
AWS, to its credit, responded quickly to Orca's security disclosures. Told of the Cloud Formation flaw on September 9th, 2021, AWS had it fixed within 25 hours and the fix propagated to all AWS regions within six days. The timeline was similar for repairing AWS Glue.
"We are aware of an issue related to AWS Glue ETL and can confirm that no AWS customer accounts or data were affected," an Amazon spokesperson told The Register in an email. "Upon learning of this matter from Orca Security, we took immediate action to mitigate it within hours and have added additional controls to the service to prevent any recurrence."
The sentiment is similar with regard to AWS Cloud Formation.
- AWS postmortem: Internal ops teams' own monitoring tools went down, had to comb through logs
- Log4j RCE latest: In case you hadn't noticed, this is Really Very Bad, exploited in the wild, needs urgent patching
- You need to shift millions of repos to AWS without any downtime. How? Bitbucket engineering chief tells all
- All your DNS were belong to us: AWS and Google Cloud shut down spying vulnerability
In a separate post, Orca Security CEO Avi Shua argues that the two vulnerabilities illustrate the advantage of the public cloud over software based on-premises.
"AWS patched their services within days – before the vulnerabilities were published in the wild," he argues, taking a position consistent with his company's focus on cloud security. "This is in stark contrast to vulnerabilities found in unmanaged software like Log4j – that boiled down to a race between attackers and defenders."
The comparison with Log4j omits a critical difference in the two scenarios: Log4j was privately disclosed to the Log4j developers by Alibaba researchers on November 24, 2021, and exploitation was detected in the wild on December 1st, prior to the Log4j 2.15.0 update on December 6th and the December 9th CVE publication.
Had either of those AWS bugs leaked to attackers and been exploited prior to AWS fixing things, the fact that the presumed data pilfering and account takeovers were happening in the cloud would not offer much solace. But those who maintained their software on-premises might be tempted to believe they were the architects of their random good fortune.
It might be fairer to say that AWS, and hopefully other public cloud providers, have a greater incentive to respond immediately to security reports than operating system vendors or volunteer open source project maintainers. ®