A bug exposed users of an AWS workflow management service to cookie tossing, but behind the scenes lies an even deeper issue that runs across all of the top cloud services.

4 Min Read
AWS and Azure logos on a digital background of a cloud
Source: GK Images via Alamy Stock Photo

A vulnerability in Amazon Web Services' (AWS) Managed Workflows for Apache Airflow (MWAA) could have allowed hackers to access users' sessions, perform remote code execution (RCE), move laterally within enterprise cloud environments, and more. But all that is just a manifestation of a much deeper-rooted misconfiguration threat researchers identified across AWS, Microsoft Azure, and Google Cloud.

The issue potentially exposed a wide swath of businesses. Apache Airflow, invented at Airbnb in 2014, is an open source workflow management platform with around 12 million downloads per month according to most estimates. More than half of Airflow's users are data engineers — the rest include architects, developers, DevOps specialists, and data engineers — and two-thirds work at companies with at least 200 employees.

In a statement to Dark Reading, Patrick Neighorn, an AWS spokesperson, emphasized that “AWS deployed a fix for these findings in September 2023, so customers running the current version of Amazon Managed Workflows for Apache Airflow (MWAA) are not impacted. We informed affected customers last year and encouraged them to update their environments through the AWS Console, API, or the AWS Command Line Interface. Before we resolved the matter, taking advantage of the findings was a complex process that would have required social engineering.”

The issue in MWAA began with its single sign-on (SSO) feature, which didn't refresh session cookies upon authentication, allowing any attacker waltzing by to intercept the session without authenticating.

Different services offered by major cloud providers often share a domain. In AWS, for example, the Simple Storage Service (S3), API Gateway, and more share the same parent. The problem is that some assets allow for client-side code execution.

"For example, the attacker’s domain is 'attacker.shared.com' and the victim’s domain is 'victim.shared.com,'" explains Liv Matan, senior security researcher at Tenable and author of the report. "Both websites are hosted under a shared parent domain named 'shared'. With that in mind, an attacker that obviously controls their own website can run JavaScript code and lure victims to that dangerous website. The victim will visit the attacker’s website, and the JavaScript code will set a cookie which is scoped to the shared parent domain, 'shared.com.' The cookie will then be available for both of the domains."

Scoping the cookie to the shared parent domain is called "cookie tossing." Here, it enables our hypothetical attacker to access a victim's Airflow Web panel and, among other things, potentially execute code on the underlying instance. This is especially concerning, Matan notes, since "Apache Airflow is often used to orchestrate data pipelines that process sensitive corporate data. Inputs to these pipelines may include customer information, financial data, or proprietary business data. Likewise, the outputs of data pipelines may contain processed data that is sensitive or confidential."

This latest discovery isn't just about MWAA, though. Such an attacker could use this cookie-tossing exploit to pivot to parallel cloud services in the victim's environment, leading to further data breaches and abuse of corporate resources. So at a more fundamental level, this could be an issue across Amazon, Google, and Microsoft's cloud platforms.

Amazon has since addressed its vulnerability, and it and Microsoft have implemented a structural fix for the underlying shared domain issue. Google has not, however. Dark Reading is awaiting further comment from Google's cloud team.

Originally created by Mozilla to support security and privacy in Firefox, the Public Suffix List (PSL) has quickly developed into a ubiquitous, community-managed list of rules for all the domain name suffixes with which one can register a website. This includes the general .com, but also .co.uk, .info, and so on, plus private suffixes like github.io. A copy of the list is integrated into all modern browsers.

Cloud service providers can thus solve their parent domain issue with some domain architecture restructuring, or they can just add domains of cloud services that share a site and involve different customers to the PSL. After that, browsers are able to recognize them as a public suffix and account for cookie tossing.

AWS and Azure have recently done just that, though as mentioned, Google Cloud has not. According to Tenable, Google said that "it doesn’t consider the issue 'severe enough' to track it as a security bug."

Matan laments, "Cloud customers are at the mercy of their cloud provider to act on this preventive approach. At the same time, cloud customers have the responsibility of securing their Web applications in the cloud to minimize risks."

Further, "check if the service domain you are using is present in the PSL," he advises. "If not, for AppSec engineers: Note the risks mentioned and take care by assuming every same-site request is untrustworthy."

About the Author(s)

Nate Nelson, Contributing Writer

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes "Malicious Life" -- an award-winning Top 20 tech podcast on Apple and Spotify -- and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts "The Industrial Security Podcast," the most popular show in its field.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights