Do you know that it's possible that some of your subdomains may be taken over by somebody else? This is due to the fact, that for some of your DNS records (mainly CNAME) you enabled zone delegation. In this blog post we will dig deep into the matter of Subdomain Takeovers, to make you understand all you need to know in order to defend yourself. If that's not what you were looking for, then check out sweepatic.com for more comfortable solutions.
A subdomain takeover is considered a high severity threat and boils down to the registration of a domain by somebody else (with bad intentions) in order to gain control over one or more (sub)domains. This presents an interesting attack vector, which can even lead to several high severity risks, like this authentication bypass explained in a bug bounty report by Arne Swinnen.
Imagine (or maybe in fact you do) you work for a global business which uses example.com as their primary domain. Because it's the 21st century, one of your activities is to create and maintain an online e-commerce platform, in addition to the brick and mortar stores your company has been operating for many years.
There are some very popular cloud e-commerce providers (e.g. Shopify, BigCommerce, Magento, Yokart, Big Kartel), so you setup a new store in one of these available offerings. After you have done the setup and configuration, the cloud e-commerce provider assigns exampleshop.someecommerceplatform.com as a domain for your store. This doesn't look very compelling to share and communicate to your customers, so you want it to be present on your brand, under shop.example.com.
In order to achieve this, you have two configuration options:
A 301/302 redirect HTTP will take care of redirecting visitors of shop.example.com to the domain of the e-commerce provider. This approach is less appealing because it will completely replace the domain in the URL bar of the user's browser.
Configuration of a CNAME DNS record that will delegate the DNS resolution directly to e-commerce provider. Using this approach, the domain in the URL bar keeps unchanged. (Note: not all cloud providers support DNS delegation using CNAME)
Since the CNAME approach is more robust, you proceed with option 2.
Fast forward one year later, the e-commerce activities of your company turn out to be a total disaster. For several reasons, the revenue targets were not reached. The operational management instructs you to take the e-commerce shop offline until the strategy is redefined.
To save money, you cancel your company's subscription of the the 3rd party e-commerce platform supplier. So now comes the moment that the risk of a potential subdomain takeover is introduced: you can easily forget to update or simply remove the CNAME record in your DNS zone file.
Bottom line, when you don't remove the CNAME record from your DNS zone file, anybody can register a new store in the same e-commerce platform suppliers environment and therefore aim to takeover shop.example.com.
This scenario might seem new or unknown to some of you, but in fact a subdomain takeover is an emerging threat. For instance you recently probably saw the news about the defacement of the Trump administration website as an example.
As extra reading material on subdomain takeover, we refer to some additional bug bounty reports:
- Subdomain takeover report for vince.co
- Subdomain takeover report for greenhouse.io
- Subdomain takeover report for uber.com
Thanks to their knowhow, Sweepatic experts are able to hunt for subdomain takeovers revealing several multinationals to be vulnerable including banks, governmental institutions and many others. Sweepatic is currently in the process to inform these organization on the potential threat this introduces to their business activities.
Of course it is clear that this vulnerability is not limited to e-commerce platforms, but to a large industry of cloud providers.
Many CNAME records out there are pointing to large cloud providers like Amazon AWS or Microsoft Azure. In those examples, and when certain conditions are achieved, a subdomain takeover can be achieved quite easily.
Let's take Amazon Cloudfront as an example. This is a CDN service, which works with the concept of distributions. A distribution can be seen as a set of static files hosted on the Amazon Cloudfront Edge servers.
After creating a new distribution (see screenshot above), AWS generates a random domain name such as d2erlblaho6777.cloudfront.net. You can access the files in your distribution using this domain. Random generation of the subdomain might seem as a good prevention against subdomain takeover, however, it is not the case for CloudFront.
The problem is, that it doesn't use 1:1 mapping - there is no dedicated IPv4 address for every distribution. CloudFront uses m:n mapping, which means that domains are mapped (think A records) to a smaller set of Cloudfront Edge servers. Since this is some kind of virtual hosting, CloudFront internally uses the mapping table to translate distribution domain to the actual content of the distribution. If you are familiar with virtual hosting, you can tell that using CNAME records is not that straightforward. Web servers use the HTTP Host header field to determine, which domain they need to serve. If you would like to use static.example.com for your static files, it will have a CNAME record to your distribution domain as the syntax shows below:
static.example.com. 600 IN CNAME d2erlblaho6777.cloudfront.net.
However, if you use static.example.com directly, CloudFront servers will see it in an HTTP Host header. Therefore, CloudFront cannot map this domain to any distribution, because this domain is not in a mapping table! That's why CloudFront allows you to provide which CNAME records you will use with your distribution.
If a domain has a CNAME record to CloudFront, but the distribution with its associating CNAME was deleted, a cyber attacker can easily claim that domain to setup his attacker infrastructure. You generate a distribution, set the CNAME, and CloudFront's mapping mechanism will take care of the rest.
Organizations usually don't audit their DNS configuration on a regular basis. Many times, there is no standardized process for adding, changing or removing entries from their DNS zone file. Even logging changes to your DNS records, are not that common. Yeah, so we (and now you too) know it's a mess and organizations need to improve this before it's too late.
"Divide responsibility and nobody is responsible." - W. Edwards Deming
Consequences of a subdomain takeover as we introduce in this blog post can be pretty bad. This is a perfect way for cyber attackers to launch a phishing campaign leveraging your established (soon to be impacted) brand reputation. The victim has no way of telling, whether the content is served by the domain owner or the cyber attacker.
Attackers can also chain higher severity attacks to this. Many applications expose session cookies to a wildcard domain (*.example.com), so any subdomain can access them. An attacker can take a forgotten subdomain, trick the user to visit it, and extract cookies (even those with secure flag). This can be seen as an advanced version of XSS.
Preventing subdomain takeover starts with proper monitoring and analysis of the DNS records of your attack surface. An important step is to conduct subdomain enumeration as explained in the "The Art of Subdomain Enumeration". Building and maintaining visibility on your dynamic attack surface including the changes to your DNS configuration is key to address this problem before it's too late.
If you have little or no visibility on your attack surface and want confirmation if you are prone (or not) to subdomain takeover, check out our solutions at sweepatic.com.
Need our help or want to know more? We'd love to hear from you. Contact us to request your personalized demo with one of our Sweepatic experts.
On a side note, this subdomain takeover post will receive a follow-up post and will go in even more detail so connect with us on our LinkedIN company page to stay tuned or subscribe to our newsletter.
Until next time!