AWS fixes 1-click account takeover flaw exposing cloud services to XSS risk

Amazon Web Services (AWS) Managed Workflows for Apache Airflow (MWAA), a popular service for running Apache Airflow workflows on the cloud, was found to contain a vulnerability that would have allowed for one-click account takeover via session fixation.

The vulnerability, dubbed FlowFixation, was discovered by Tenable Research last year and has since been fixed by Amazon, according to a Tenable blog post published Thursday.

FlowFixation could have been used to gain control of another user’s AWS MWAA web panel session by an attacker hosting malicious code on their own AWS domain, such as an attacker-controlled Amazon API Gateway REST API instance.

To achieve this control, the attacker would need to lure the victim to their own domain, which would trigger the hosted script to insert a cookie with the attacker’s session ID into the victim’s browser.

One access to the victim’s web panel is gained, the attacker could view potentially sensitive workflow data, perform remote code execution (RCE) and potentially achieve lateral movement across other services.

Because many AWS services, including AWS MWAA and REST API, share the common “amazonaws.com” domain, this “cookie tossing” session hijack attack would not have been prevented by the user’s browser prior to the fix.

While investigating FlowFixation, the Tenable researchers uncovered a common misconfiguration across multiple AWS, Microsoft Azure and Google Cloud Platform (GCP) services that could allow for similar cross-site scripting (XSS) and session hijacking attacks.

The flaws lie in the domain architecture of such cloud services, in which different instances – run by different customers – share a common domain name, putting them at risk of same-site attacks such as cookie tossing.

For example, as stated above, many AWS services share the common “amazonaws.com” domain, and several GCP instances use the “googleusercontent.com” domain.

The risks associated with these shared domains are mitigated by a simple guardrail, the Tenable researchers explain. Domains registered in the Publix Suffix List (PSL), a community-driven initiative established and maintained by Mozilla, avoid same-site attack risks because the PSL prevents cookies from being shared across subdomains with a common suffix.

Browser developers use the list to recognize and isolate distinct subdomains sharing registered public suffixes. When a cloud service domain, such as “amazonaws.com” is not included in the PSL, cookies can be shared between different AWS instances, heightening the risk of session hijacking exploits like FlowFixation.

Tenable discovered that several AWS, Azure and GCP domains were not included in the PSL, and reported the issue and its risks to Amazon, Microsoft and Google.

Amazon, after receiving Tenable’s report about FlowFixation, conducted a thorough review of its AWS domains and added the domains for its API Gateway, Cognito, EMR, MWAA, S3, Sagemaker Notebook Instances, SageMake Studio, Analytics, Amplify, App Runner and Elastic Beanstalk to the PSL last October.

Microsoft was also informed of the Azure domain misconfigurations and registered the domains for its API Management, Edge, Front Door, Blob Storage, Cloud Services, Virtual Machines, Service Bus and Traffic Manager platforms to the PSL last month.  

Tenable says it also reported to Google that the “googleusercontent.com” domain, used for GCP services including Google Compute Engine Virtual Machines, Jupyterlab and Google Cloud Composer’s Apache Airflow web interface, was not included in the PSL. Google declined to register the domain and did not consider the issue “severe enough” to track as a security flaw, according to Tenable.

Tenable Senior Security Researcher Liv Matan, who authored the research blog post, noted that FlowFixation is not the only vulnerability that can be prevented by PSL registration, citing an AWS SageMaker Jupyter Notebook cross-account access vulnerability discovered by Lightspin in 2021 and cookie tossing and RCE exploit on Google Cloud JupyterLab reported by a bug hunter known as s1r1us in 2020.

“What’s striking is that none of these vulnerabilities could be exploited if the PSL guardrail were in place,” Matan wrote.

Leave a Reply

Your email address will not be published. Required fields are marked *