Source: GK Images via Alamy Stock Photo

A one-click vulnerability in Amazon Web Services' (AWS) Managed Workflows for Apache Airflow (MWAA) could have allowed hackers to hijack 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 common to AWS, Microsoft Azure, and Google Cloud.

The issue affected 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.

Cookie Tossing in Cloud Services

The issue in MWAA was a glaring one: Its single sign-on (SSO) feature 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 hijack 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.

The Fix for Cookie Tossing

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."

Dark Reading is awaiting further comment from Google's cloud team.

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

"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."