SecurityTrails Blog

Note: The audio version doesn't include code or commands. Those parts of the post can be seen in the text version.

Over the past few months, we’ve been perfecting our new SQL-like query language, one that will allow security teams to perform massive intelligence collection as well as automate their findings. Today, we're excited to announce the immediate availability of this powerful new product: Securitytrails SQL.

By contacting our Sales team, you will be able to use SecurityTrails SQL integrated as a Securitytrails API endpoint, inside Attack Surface Reduction, as well as in the Surfacebrowser SQL Explorer interface.

What does Securitytrails SQL look like?

Securitytrails SQL will empower you to collect data about any host, including domains, DNS records, Whois, SSL, HTTP, and the organization it belongs to, along with detailed IP data. For your convenience, this tool also supports a wide range of SQL operators and with it we provide full documentation complete with examples and technical assistance. Additionally, SurfaceBrowser SQL Explorer users can enjoy our SQL editor, which allows you to run queries, copy data from it, format and clear everything, as well as download results in JSON or CSV.

How can I use Securitytrails SQL?

You can use Securitytrails SQL to run different queries to get host, IP and SQL data. And how does the Securitytrails SQL look when used from SQL Explorer's visual editor? See it in action: Now let's look at some query examples you can run from your Securitytrails API. The following query will expose all subdomains from microsoft.com: In the same way, and by merely changing the SQL-query, you can fetch different data. To find all exposed development areas of subdomains ranked by Open PageRank, run: To locate self-signed SSL certificates, using GE.com for this example, run this query: You can find more SSL-based examples in the SQL Explorer: SSL Certificate Scraping Showcase blog post.

If you want to find domains that redirect to a certain host—and here we used Securitytrails.com—use: To find IPs with SSL certificates that contain a specific hostname in them, like Nike.com for instance, run: There is much more functionality to be discovered once you start playing with Securitytrails SQL. Security teams can use it to:

Automate detection of security issues. Map your entire digital infrastructure. Find critical SSL data. Detect open services. Improve phishing detection. Prevent data breaches. Find vulnerable operating systems and services.

Are you ready to explore Securitytrails SQL?

Find out how Securitytrails SQL can help you find critical data from any organizations within seconds—and take your recon and app automation to the next level!

Note: The audio version doesn't include code or commands. Those parts of the post can be seen in the text version.

Over the past few months, we’ve been perfecting our new SQL-like query language, one that will allow security teams to perform massive intelligence collection as well as automate their findings. Today, we're excited to announce the immediate availability of this powerful new product: Securitytrails SQL.

You'll be able to use Securitytrails SQL integrated as a Securitytrails API endpoint, inside Attack Surface Reduction, as well as in the Surfacebrowser SQL Explorer interface.

What does Securitytrails SQL look like?

Securitytrails SQL will empower you to collect data about any host, including domains, DNS records, Whois, SSL, HTTP, and the organization it belongs to, along with detailed IP data. For your convenience, this tool also supports a wide range of SQL operators and with it we provide full documentation complete with examples and technical assistance. Additionally, SurfaceBrowser SQL Explorer users can enjoy our SQL editor, which allows you to run queries, copy data from it, format and clear everything, as well as download results in JSON or CSV.

How can I use Securitytrails SQL?

You can use Securitytrails SQL to run different queries to get host, IP and SQL data. And how does the Securitytrails SQL look when used from SQL Explorer's visual editor? See it in action: Now let's look at some query examples you can run from your Securitytrails API. The following query will expose all subdomains from microsoft.com: In the same way, and by merely changing the SQL-query, you can fetch different data. To find all exposed development areas of subdomains ranked by Open PageRank, run: To locate self-signed SSL certificates, using GE.com for this example, run this query: You can find more SSL-based examples in the SQL Explorer: SSL Certificate Scraping Showcase blog post.

If you want to find domains that redirect to a certain host—and here we used Securitytrails.com—use: To find IPs with SSL certificates that contain a specific hostname in them, like Nike.com for instance, run: There is much more functionality to be discovered once you start playing with Securitytrails SQL. Security teams can use it to:

Automate detection of security issues. Map your entire digital infrastructure. Find critical SSL data. Detect open services. Improve phishing detection. Prevent data breaches. Find vulnerable operating systems and services.

Are you ready to explore Securitytrails SQL?

Find out how Securitytrails SQL can help you find critical data from any organizations within seconds—and take your recon and app automation to the next level!

Vendors such as Datto, Geo Vision, Synology and others leverage and depend on self-registered services for their products. These devices frequently leak critical data or have insecure design, unintentional or even intentional design decisions and application flaws. Through insecure network design and installation practices, they can be easily mapped, discovered and attacked by cyber criminals via insecure vendor, software and integrator practices.

For our new blog series Blast Radius, security professionals, researchers and experts deep dive into different attacks and vulnerabilities, explore how they can impact the entire internet ecosystem, and examine what they mean for organizations of all sizes, across all industries. To talk about the emerging properties of self-registration services bundled with devices provided by major manufacturers and the implications of their insecure design, we are joined by Ken Pyle.

Ken Pyle is a partner of CYBIR, specializing in exploit development, penetration testing, reverse engineering, and enterprise risk management. As a highly rated and popular lecturer he's presented groundbreaking research at major industry events such as Defcon, ShmooCon, Secureworld, HTCIA International, and others. He's also discovered and published numerous critical software vulnerabilities in products from a wide range of companies that includes Cisco, Dell, Netgear, Sonicwall, HP, Datto, Kaseya, and ManageEngine, earning him multiple Hall of Fame acknowledgements for his work. Ken has been publishing DNS work and vulnerability research privately for a number of years. He began showing some of his work in the web application, DNS and IPv4 space at different cybersecurity conferences, with a focus on fixing sets of problems that had already been deemed unfixable.

For our latest installment of Blast Radius, Ken will share a continuation of his work, and will disclose how the entire PKI, non-repudiation and encryption design of entire vendor ecosystems is flawed, and how you can use popular IoT devices and services to de-anonymize anonymity networks and map internal networks via poorly managed cloud security features. Additionally, he'll reveal how he gained arbitrary control of firewall rules across millions of devices and multiple vendors.

The emergent properties of dynamic DNS scraping

At Defcon 29, I presented a number of new attacks, reconnaissance types, exploits, and emergent properties of Self-Registration Services that come with devices provided by major manufacturers such as Datto. In the lead up to Defcon, I have been publishing quietly on the subject and attempting to pre-empt and alert companies to the exposures. I have been a really big fan of Securitytrails all the way back to DNS Trails. I find the engine and dataset to be simple to carve, highly accurate, and many emergent properties can be easily identified using the site and tools.

In this write-up, we're going to discuss the emergent properties of passive, historical dynamic DNS registrations and how these can be easily exploited.

Mass mapping/arbitrary control of firewall rules

One of the many awesome features of Securitytrails is the ability to quickly and easily search data in weird ways no one has thought of. For example, a search for RFC 1918 addresses via ST will turn up some pretty interesting results:

Searching for RFC 1918 addresses, specifically those which MSPs, IT folks, or even your home routers distribute, will allow you to very quickly start identifying internal networks and their firewall rules. You'll notice I've highlighted a few interesting zones, remotewd.com, wd2go.com, duckdns.org, dattolical.net. We'll get back to those. In order for many of these devices to register or maintain a record on the manufacturer's dynamic DNS regime, they must consistently beacon or "check-in" every few minutes. This allows the manufacturer (and you) to find the device easily, track it over network changes, and allow it to update and license i...

Note: The audio version doesn't include code or commands. Those parts of the post can be seen in the text version.

Recognized as a leader in the container market, Kubernetes is an open source microservices cluster manager used by millions of companies worldwide. Bolstering its popularity is its considerable ability in managing container workloads, as it allows for the easy deployment of numerous servers with appropriate scaling as they grow.

To show you just how dominant Kubernetes truly is, reports show that of the more than 109 tools used to manage containers, over 89% of companies use various Kubernetes versions. Not a bad statistic for a technology that's only eight years old! And as Kubernetes usage grows, so does interest about, and skepticism concerning, the security of the platform. Companies of many different types, from small developers to big-name brands, use Kubernetes to help deploy systems both easily and in a uniform fashion. And the most common cause of all Kubernetes-related security incidents by far is a familiar threat in the cybersecurity field, misconfigurations. Roughly seven out of ten companies report having detected a misconfiguration in their Kubernetes environment.

For our new blog series Blast Radius, security professionals, researchers and experts deep dive into different attacks and vulnerabilities, explore how they can impact the entire internet ecosystem, and examine what they mean for organizations of all sizes, across all industries. As Kubernetes grows in popularity, so do the security concerns around its usage. To talk more about the blast radius of misconfigured Kubernetes, we are joined by Robert Wiggins, better known as Random Robbie. Robbie was featured on our blog in the past when he showed us all the ProTips on Bug Bounty Hunting that he has up his sleeve. Active in the security and bug bounty community, Robbie shares with us his research and techniques for finding misconfigured Kubernetes, and elaborates on the different types of impact he's seen them have on various companies.

How many misconfigured Kubernetes are there?

On average, there are around 800 misconfigured Kubernetes servers around the world exposing secrets and other fun data. These systems are generally connected to a lot of internal cloud systems, so if they're misconfigured they can handily grant access to a lot of sensitive information to an attacker. Security incidents involving misconfigurations in Kubernetes are a serious matter. As cited by DivvyCloud in their 2020 Cloud Misconfigurations Report, 196 separate data breaches were a result of cloud misconfigurations between January 1, 2018 and December 31, 2019. More than 30 billion records were exposed in these data breaches, creating $5 trillion in losses over that period.

How to find misconfigured Kubernetes servers

Also on average are around 400 systems exposed via Shodan on port 443 and many more on port 8080. The ones on port 8080, however, generally seem to have been attacked and have an XMR miner on them. Many of the attacked or infected servers have been up for a while, with a large number of them appearing to be located in China. To find exposed Kubernetes systems, you can search via Shodan using the search term http.html:/apis/apiextensions.k8s.io for any HTTP 200 response. That response should give you a list of API endpoints and you can browse to /api/v1/secrets to uncover all of the server's secrets. Here's an example: By running the following bash command you can see which tokens have permission to gain access to the pods. You should now see an output showing you the pods. Once you've found the pod you wish to access, you can run the following command to gain access to that pod, then explore it. To confirm it has access to the pod, it should dump out something like this:

Impact of misconfigured Kubernetes

While scanning and learning about Kubernetes three years ago, I found a Kubernetes server that belonged to Snapchat. This server was so full of se...

Cybersecurity is a lucrative career, but knowing which path to follow to break into the industry can be daunting for fresh graduates, enthusiasts, and those switching careers.

Not to mention, actually taking the plunge and getting into the industry, especially when coming from a non-traditional background, is a discussion in itself. Fortunately, many inspiring cybersecurity professionals break the illusion that you need to follow a specific path to have a career in this industry. Phillip Wylie has one of the more interesting and inspiring stories of going into cybersecurity and becoming a valued professional, mentor, and teacher. He has been part of the industry since the late 1990s but, before then, he was actually a pro wrestler and even wrestled a bear! Today, Phillip wrestles with issues of accessibility of cybersecurity education by teaching ethical hacking and web app pentesting at Dallas College and running The Pwn School Project, in addition to working as a Senior Cloud Penetration Tester.

We jumped into the ring with Phillip to hear his backstory, which skills transferred from his pro wrestling career to cybersecurity, the importance of mentorship in the industry, and his advice to people that want to start on his path.

SecurityTrails: You've been in offensive security for over a decade now, but you had an interesting career prior to that. We need to ask about your wrestling career, especially bear wrestling! Can you tell us a little about that part of your life? What was it like to wrestle a bear?

Phillip Wylie: When I graduated high school, I did not know what I wanted to do for a career. As a powerlifter and a big muscular guy, my friends said I should be a professional wrestler. I liked the idea and pursued a wrestling career. I attended two different wrestling schools and wrestled for a couple of years. I got to wrestle some very well known wrestlers, including Mick Folley, who wrestled in Texas as Cactus Jack. I also wrestled two of the three Fabulous Freebirds tag team trio, The Road Warriors, The Rock n Roll Express, The Midnight Express, and the Samoan SWAT Team, who happened to be related to Dwayne The Rock Johnson. I did not wrestle often enough to make a living, so my main job was working as a bouncer at a nightclub in my hometown of Denton, TX. The nightclub hosted special events on Sundays, and they decided to bring in a wrestling bear.

The nightclub manager asked me to wrestle the bear to help boost attendance of the event since I was a pro wrestler and known by the nightclub patrons. Wrestling the bear was open to anyone that wanted to. The bear was named Sampson and was a 750-pound brown bear. People always ask me who won, and the answer is the bear.

ST: There is an interesting parallel between professional wrestling and offensive security, are there any lessons you learned from wrestling and applied to your infosec career?

Phillip: The biggest parallel I can draw between pro wrestling and offensive security is the social engineering part of offensive security. Wrestling has become known as sports entertainment since wrestling federations shared that it was not real. With social engineering, you become who you portray during pretexting, much like acting in pro wrestling. Real wrestling and martial arts can also have parallels drawn between them and offensive security. Discovering an opponent's weaknesses and exploiting them is a great example, much like how you find vulnerabilities and exploit/hack them.

Focus on the learning. If you don't learn the subject, the certification or degree is not as useful. The degree or cert is nice to have, but if you don't know what you are doing, you will have a more difficult time.

ST: How did you discover information security and what did your early days look like?

Phillip: My first experience with information security was working for Intrusion, Inc. in early 2000s providing technical support for Linux-based firewall and VPN appliances and a vulnerability scannin...

Subdomain takeover remains a common vulnerability, and a destructive one at that. On one hand, there are types that practically don't exist anymore, such as C name takeovers, while there are still plenty of hanging DNS records, PoC creation is nearly impossible due to restrictions put in place by major cloud providers (mainly AWS).

On the other hand, and in terms of severity, DNS or NS takeovers are less common but create the highest impact. An NS subdomain takeover is similar in principle to other types of subdomain takeovers. And due to the major role that NS records play in internet traffic, and the possibility of attackers chaining multiple attack vectors, an NS takeover can lead to severe implications for the target organization. For our new blog series Blast Radius, security professionals, researchers and experts deep dive into different attacks and vulnerabilities, explore how they can impact the entire internet ecosystem, and examine what they mean for organizations of all sizes, across all industries. To talk about the growing danger of DNS takeovers, we are joined by Patrik Hudák. Patrik has been a regular on our blog, sharing about his latest research on subdomain takeovers, and has been a crucial resource for many in the bug bounty community.

He began his research by studying other takeover methods and the different tools used to execute them before discovering the impact of DNS takeovers. While not that common, he has achieved many successes in bug bounty hunting with this particular vulnerability.

How companies can be affected

When a company hosts its DNS zones on a third-party DNS provider (such as AWS Route 53), there is a possibility of DNS takeover (also known as NS takeover). Such a takeover happens when the DNS zone is removed from the DNS provider, but the DNS delegation link stays in play. If such an event happens, an attacker can register the same DNS zone on the same provider and host arbitrary records for such a zone. For more technical information, please refer to the following link:

Although this seems to be only a theoretical attack, there are numerous cases where this has actually occurred, even with large companies. Everybody who uses third-party DNS providers is affected if the process for the creation and removal of DNS zones is incorrect. Thus, companies of any size should audit their internal processes for such events. There are, however, more tricky scenarios. Since DNS uses multiple nameservers for DNS zones for redundancy, sometimes only a subset of such nameservers is affected by DNS takeover. Let's say that domain "example.com" uses two nameservers: "dns.existingdomain.com" and "dns.nonexistingdomain.com". The latter, as the name suggests, does not exist and thus cannot correctly serve requests for the "example.com" zone. From the usability perspective, there is no downtime. Every DNS request made for "example.com" is served by "dns.existingdomain.com" since DNS uses quiet fallback.

In this scenario, an attacker can exploit the non-existing nameserver simply by registering the domain name (if it is available) which would lead to becoming an authoritative nameserver for "example.com". During the DNS request, the round-robin mechanism for choosing a nameserver is used, in other words, there is a 50% chance that while requesting DNS info for the "example.com" zone, it would hit the malicious nameserver. If it does, an attacker can serve arbitrary DNS results with the high TTL which would sit quietly in a cache for a long time.

Implications of DNS takeover

Firstly, DNS takeover is not that different from other types of takeover such as C name. One difference is that DNS takeover can cover multiple subdomains with different domain names. Since the attacker controls the DNS zone, she can create great FQDNs for phishing or other malicious activity. Let's say that "sub.example.com" is affected by the DNS takeover. An attacker might take it further and create a new subdomain called "login.sub.e...

Note: The audio version doesn't include code or commands. Those parts of the post can be seen in the text version.

A while back, Securitytrails announced that they would be running a contest dubbed "Recon Master", the aim of which is to find hostnames that resolve to an IP-v4 address that haven't already been found by Securitytrails. As it had been a while since I flexed my recon muscles, that sounded very interesting to me. These days, the majority of my asset discovery phase is spent literally just using Securitytrails, so this would force me to think outside of the box and stop being so lazy. Also, the whopping $5,000 prize for first place was pretty appealing. At the beginning of the contest, I was in first place by a wide margin for quite some time. Now, the game is in full swing, I'm in seventh place, and I've given up on winning. Frankly, I've spent too much time on it, but during that time I've come up with a few interesting ideas that I believe are useful enough to share in a blog post, so here we are. Much like bug bounties, winning this contest is all about creativity.

SecurityTrails is already extremely good at finding hostnames because that is a huge part of their core business. In order to defy the odds and discover hostnames that the SecurityTrails team hasn't, a big chunk of creativity will need to be applied. Let's jump into the techniques I tried, from failures and successes to successes that ended up failing, you'll see what I mean.

Streamlining the submission process

Amass is great and all, but currently it's the only DN-S enumeration tool I'm aware of that has the Securitytrails submit endpoint built right into it. The contest page actually advertised this, which means that a whole lot of people will simply be using Amass to discover hostnames. I figured that if I wanted to discover hostnames that nobody else has discovered, it would be wise for me to avoid using the same methods and tools.

Upgrading haktrails

The first thing I did was build the submit endpoint into haktrails, a tool I had already written to query Securitytrails data. I didn't add the submit endpoint to any of the documentation because I thought that this would give me a slight advantage in the contest. Actually, I still haven't added the documentation, but I'll show you how to use it right here:

This will take each line in subdomains.txt and submit it in chunks of 1 million lines until there are no lines left to submit. Now that I had an easy way to submit data, I could literally just pipe the output of any subdomain enumeration tool, or any list of hostnames directly into haktrails to submit it.

Generating gzip files

I figured that there would be times when it would be more efficient to submit gzip files due to the sheer amount of data to upload, so I wrote another quick Golang tool which takes lines of text as input and gzips them into multiple gzip files with x lines each. I called it gzipsplit. Usage is something like this:

This command would create multiple gzip files with one million subdomains in each. Note that this is different from splitting a gzip file into multiple files using the split command. If you use the split command, you end up with smaller split files, but they aren't valid gzip files unless you join them back together, so you can't extract the text from them.

Submitting bug bounty recon (or not)

My guess is that every bug bounty hunter and their dog will be submitting their bug bounty recon data to win this contest. That means that every bug bounty hunter and their dog will be submitting the same data.

The ideas

I started thinking about things to submit. In particular I wanted to find hostnames that were most likely to be fresh, so that I might beat SecurityTrails to it. The first thing that came to mind was Certstream.

Certstream

What is Certstream? Their website says it best:

Certstream is an intelligence feed that gives you real-time updates from the Certificate Transparency Log network, allowing you to use it ...

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

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

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