A vulnerability in Amazon Web Services (AWS) managed workflows for Apache Airflow (MWAA) could have allowed attackers to access user sessions, perform remote code execution (RCE), move laterally into of enterprise cloud environments and more. But all of this is just the manifestation of a much more entrenched misconfiguration threat that researchers have identified in AWS, Microsoft Azure and Google Cloud.
The issue has potentially highlighted a broad swath of businesses. Apache Airflow, invented by Airbnb in 2014, is an open-source workflow management platform with around 12 million downloads per month by most estimates. More than half of Airflow users are data engineers – the rest include architects, developers, DevOps specialists and data engineers – and two-thirds work in companies with at least 200 employees.
In a statement to Dark Reading, Patrick Neighorn, a spokesperson for AWS, pointed out 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 interested. We notified affected customers last year and encouraged them to update their environments via the AWS Console, API, or AWS CLI. Before the issue was resolved, exploiting the findings was a complex process that would require social engineering.”
Launching cookies in cloud services
The problem in MWAA started with its Single Sign-On (SSO) feature, which did not update session cookies upon authentication, allowing any attacker to bypass intercept the session without authenticating.
Different services offered by major cloud providers often share a domain. In AWS, for example, Simple Storage Service (S3), API Gateway, and others share the same parent. The problem is that some resources allow execution of client-side code.
“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 called ‘shared’. With this in mind, an attacker who obviously controls your website can execute JavaScript code and lure victims to that malicious website. The JavaScript code will set a cookie that is scoped to the shared root domain, “shared.com”. The cookie will then be available to both domains.”
The cookie scope in the shared root domain is called “cookie throwing”. In this case, it allows our hypothetical attacker to access a victim’s Airflow web panel and, among other things, potentially execute code on the underlying instance. This is particularly concerning, notes Matan, since “Apache Airflow is often used to orchestrate data pipelines that process sensitive business data. Inputs to these pipelines can include customer information, financial data, or proprietary business data. Likewise, outputs data pipelines may contain sensitive or confidential processed data.”
This latest discovery, however, does not only concern the MWAA. Such an attacker could use this cookie-throwing exploit to switch to parallel cloud services in the victim’s environment, leading to further data breaches and abuse of company resources. So, on a more fundamental level, this could be a cross-cutting issue Amazon, Google and Microsoft’s cloud platforms.
Amazon has since patched its vulnerability and together with Microsoft has implemented a structural fix for the underlying shared domain issue. Google, however, did not do this. Dark Reading is awaiting further comment from Google’s cloud team.
The cookie throwing solution
Originally created by Mozilla to support security and privacy in Firefox, the Public Suffix List (PSL) quickly developed into a ubiquitous, community-maintained list of rules for all domain name suffixes with which you can register a website . This includes the general .com, but also .co.uk, .info, and so on, as well as private suffixes like github.io. A copy of the list is integrated into all modern browsers.
Cloud providers can then solve the root domain problem with a domain architecture restructuring, or they can simply add cloud service domains that share a site and involve several customers to the PSL. Subsequently, browsers are able to recognize them as a public suffix and take into account the launching of cookies.
AWS and Azure have recently done just that, although, as mentioned, Google Cloud has not. According to Tenable, Google said it “does not consider the issue ‘serious enough’ to track as a security bug.”
Matan laments: “Cloud customers are at the mercy of their cloud service provider when it comes to adopting this preventative approach. At the same time, cloud customers have a responsibility to secure their web applications in the cloud to minimize minimal risks.”
Also, “check whether the service domain you’re using is in the PSL,” he advises. “Otherwise, to AppSec engineers: Take note of the risks mentioned and be careful about assuming that every request on the same site is untrustworthy.”