Blast Radius: Apache Airflow Vulnerabilities
Note: The audio version doesn't include code or commands. Those parts of the post can be seen in the text version. Apache Airflow is an open-source workflow management platform that started at Airbnb in 2014 as a solution to manage complex workflows. It allows organizations to programmatically author, schedule and monitor their workflows over their web-based interfaces that are connected to internet databases and many other systems. While starting at Airbnb, today many organizations use Airflow, with the majority of them in the software and financial services industry and of quite large revenues of over $100 million. A seemingly harmless and just another workflow platform but due to its architecture and number and size of companies using it, Apache Airflow offers a wide attack surface, with vulnerabilities in it leading to less than benign scenarios. Blastradius is a new series on our blog where security professionals, researchers and experts will deep dive into different attacks and vulnerabilities and explore how they can impact the whole internet ecosystem and what it means for organizations of all sizes, across all industries. In the first part of our BlastRadius series, we are joined by Ian Carroll. A security researcher Ian Carroll ran into an Airflow instance exposed to the internet during recon on a bug bounty program which piqued his interest to investigate its security further. He will go over finding older vulnerabilities in Airflow, exploiting and automating critical issues in it and finally, how to find affected companies and the impact of these CVEs to them. Understanding the Apache Airflow Vulnerabilities Earlier this year, I stumbled upon an Apache Airflow instance's web interface when looking through public assets on a bug bounty program. While it was behind authentication, I got curious and started looking into its security and past vulnerabilities, to see if it might be an interesting target. I quickly realized that not only did it have several prior security vulnerabilities, but that it was often connected to numerous systems within a company — a great target to easily cause a lot of damage. I was able to exploit these issues in over ten bug bounty programs, earning many P1s and over $13,000. Finding older vulnerabilities Faced with the Airflow login page on this target and never having seen it before, I decided to go dig through old CVEs on Snyk. I was surprised to find quite a few, most of which were in its web interface. However, I had no idea what version of Airflow my target was using, and many seemed to require me to already have logged in to the instance. Since I had no access at this point, I kept looking until I noticed a curious entry from December of 2020, rated as "medium" by Snyk: Given a default config, it allows a malicious airflow user on site A where they log in normally, to access unauthorized Airflow Webserver on Site B through the session from Site A. This is a weird way to phrase this issue, as it seems to imply something quite severe — the authentication system for a default Airflow instance is able to generate valid sessions for any other Airflow instance. This must mean that we can log into any instance that didn't change an otherwise obscure configuration value. Contrary to its CVSS rating, this is likely a critical vulnerability! Exploiting CVE-2020-17526 Looking through the Apache Airflow project, I noticed a pull request that changed the secret_key configuration setting mentioned in the advisory. It used to be a hardcoded value of temporary_key, and was moved to a random value around when the advisory was released. So it seems we know the session secret for most Airflow instances was accidentally hardcoded to temporary_key, but what does this mean for exploiting it? This seemed like a classic stateless session implementation, like a JSON Web Token (JW-T), where the session state is not stored on the server. Instead, the session state is encoded and stored inside a cookie, and ...