Domain Security & Solutions, Part 3: Stale DNS Records & Subdomain Takeover Attacks
Reading time: 10 minutesSince the beginning, the Internet has been powered by servers. Going back a few decades, most companies used bare metal servers. Then came VPS servers, which allowed people to run virtual operating systems in a single dedicated server with different applications, database technologies, and more.
If VPS technology changed the way we work, cloud services revolutionized it. Cloud services allow people to run serverless applications, create load balancing services within minutes, and auto-balance traffic depending on growth patterns, among other advancements.
Creating a cloud instance with your favorite operating system takes less than a minute. During that time, the cloud provider creates a virtual system based on a template, configures network settings, assigns a public IP, and there you go—your new cloud VM is ready to be used.
That's pretty awesome! You just allocated resources for $4/month, got your recycled public IP and enough processing power to start configuring your web-based services and upload your app.
With the incremental IPv4 shortage problem, assigning unused IPs to new customers has become pretty frequent among almost all cloud providers. While there's nothing really nothing wrong with this practice, if you combine it with a lack of DNS audits on your company's side, it has the potential to become a major cybersecurity problem.
According to Gartner's last 2018 cloud stats report¹, Worldwide Public Cloud Service Revenue will jump from $175.8 billion (2018) to $278.3 billion by the end of 2021. This leads us to believe that the problem isn't likely to decrease; on the contrary, it's bound to become more frequent than ever.
In this article we'll cover the stale DNS record concept, how remote attackers can abuse this unseen DNS area to perform subdomain takeover attacks, and most importantly, how you can prevent subdomain takeover attacks.
- What is a stale DNS record?
- Subdomain takeover attack
- Popular types of subdomain takeover attacks
- How can I prevent subdomain takeover attacks?
- Conclusion
What is a stale DNS record?
There are several types of cybercrime associated with DNS services. We've covered most of them in our popular blog post about DNS attacks, but one we've only covered superficially is the so-called subdomain takeover attack, which is directly tied to stale DNS records.
To explain what a stale DNS record is, we first need to know how DNS records normally work in a real-world scenario. Let's take a look:
Let's suppose you need to upload your new app into a VM for testing purposes. In order to do this, you choose your favorite cloud server provider, order a new VM instance, and your VM will be up and running in less than a minute.
Once that's done, you just upload your app using SSH, and create a DNS record in your DNS zone for a test subdomain. Here's an example:
test 3600 IN A 11.22.33.44
Once you've finished testing, there's no sense in keeping that VM turned on, so you turn it off and destroy the droplet.
That seems normal, right? Here's the catch: there's nothing inherently bad in that procedure, except that 99% of developers and DevOps actually forget to delete that DNS record.
And there you have it. This seemingly normal situation becomes a risk when an active or used DNS record becomes a stale DNS record, and potentially a new vulnerable point on your attack surface area.
To recap, a stale DNS record is merely an active DNS entry that points to a discontinued cloud VM.
Subdomain takeover attack
How can a stale DNS record become a cybersecurity issue for your company? We covered a bit of this topic in our interview with Patrik Hudak some time ago, but today we'll dig deeper into things related to subdomain takeovers.
As per the previous example, normal test subdomain usage becomes a problem as soon as someone scans your DNS infrastructure using popular OSINT tools, and starts analyzing each one of your subdomain records.
The issues only mount when somebody else creates a VM instance on the same cloud provider as you did initially. A second condition needs to be applied; that the provider assigns the same IP to the new cloud service, and that the provider doesn't use any advanced domain verification process.
Finding subdomains and domain names that are using stale DNS records isn't actually difficult, especially if you're using subdomain scanner tools.
A simple test can be performed by exploring rDNS entries of your new VM machine IP address. Bing is a useful resource thanks to its "ip:" search operator, but you can do even more if you decide to use the SecurityTrails IP exploration feature, as well as the rDNS discovery service, as you can see below:
These are just quick examples with any random Amazon IP address. However, if you find active records pointing to your new allocated IP, there's a big chance that those subdomains are vulnerable to subdomain takeover attacks.
The real question is whether the IP address allocation is random or if it follows a certain pattern that may lead others to exploit this type of vulnerability.
Another related question we should ask ourselves is: are all cloud providers vulnerable to this type of attack? Not all, but unfortunately, many are. There are publicly available resources³ that will let you check the exploitable signature of the sub-domains found.
Both of these factors can indicate a substantial attack surface point, one that invites attackers to perform malicious activities, such as:
- Setting up a web page and claiming to be an official service depending on the main domain name. This could be used in phishing attacks to steal your customer sensitive data. This problem becomes even more complicated when attackers impersonate your company by using free ssl certificates for the stale dns record.
- In the second most popular case, sending spoofed emails to drive traffic to the subdomain, then serving malware and viruses to all visitors with the goal of encrypting their computers, or controlling them as part of botnets.
Popular types of subdomain takeover attacks
There are a few types of subdomain takeover attacks that differ a little bit from the targeted DNS record. Let's look at some alternative forms of this stale DNS attack:
MX subdomain takeover
MX records are used to receive emails, therefore, if you're going to perform a subdomain takeover attack against this type of DNS record, you aren't going to do much, unless your goal is receiving emails from specific companies. MX subdomain takeover is one of the lowest-impact attacks as it usually doesn't cause as much chaos as NS and CNAME takeovers, and is often undervalued by security researchers and bug bounty hunters (although, this doesn't mean that if you find stale MX records you should keep them active in your DNS zone).
CNAME takeover
This is one of the most common forms of subdomain takeover. It happens when, for example, you own test.domain1.com and you create a CNAME pointing to another domain test2.domain2.com using a typical CNAME record.
The idea behind this is that you should be able to manipulate the content of test2.domain2.com if this is an expired domain and you buy it, or if this is hosted at any popular cloud/iaas/saas providers such as Github, Heroku, Shopify, etc.
In this scenario, if you're an attacker and provider allows you to create the same subdomain name as your victim, then you're set.
NS takeover
The NS subdomain takeover follows the same principles as the previous examples. However, due to the big role that NS records play Internet traffic, the results could be some of the worst you experience if you fall victim to this type of attack.
This type of DNS takeover is not as frequent as the CNAME takeover, as live NS records no longer point to a specific address by mistake. Also, if there's live traffic, system administrators will surely notice this immediately and correct the issue at the DNS zone.
If no one notices the change (especially with low-traffic websites) and you're able to take over at least one of the NS records (usually, the minimum is two, most big players use at least four, and in some cases we've even seen up to seven name servers), you'll be in control of the DNS server, able to serve results as you wish, set custom TTL timing, etc.
How can I prevent subdomain takeover attacks?
1. Perform scheduled DNS audits against your DNS zones
This is the best advice we can give you, and it's really fast and easy to do with our passive DNS database.
You don't even need root access to the DNS servers. You can inspect your DNS zones by using our DNS history features. This utility will enable you to inspect all the present records for your online domain names.
As shown below, it only takes a couple of seconds to pull up all your records:
- Move to https://securitytrails.com
- Type your domain name
- Explore all your subdomain DNS records
From there, click on the subdomain name and you'll be able to fetch the IP address by following its lead.
2. Change your project management policies
When a project becomes useless or unnecessary and requires a shutdown of all involved infrastructure, create a checklist. At the top of it, remind yourself with a big red message to: "Remove all the DNS records for each virtual host".
This is a simple a reminder that the human mind fails to remember basic things. Even for simple tasks like shutting down a project, you should always rely on checklists to make sure all the really important stuff is done properly.
3. Start using Google Search Console
Here's a lesson learned from PowerDNS² when they faced the same type of subdomain takeover as described in this article.
This is one of our top recommendations, and one that can literally save your company from a phishing campaign (or help you mitigate it quickly).
Nowadays, everybody has a Gmail account, and by adding your websites to Google Search Console you will become "protected" against malicious subdomain takeovers thanks to the detection of any consistent unusual activity across your domain names.
4. Use DNSSEC
This is especially recommended for preventing NS subdomain takeover attacks. As we've seen before, DNSSEC offers advanced ways to protect your domain names and DNS infrastructure.
It can also be used to avoid domain hijacking. This works if you're using a registrar that supports DNSSEC—basically you must upload a public/private key pair to your domain registrar as your DNSKEY. At the name server you sign up the zone file with your private key, and the end result will be that when you try to modify/add any of your records, it will be accepted due to the DNSSEC signatures.
If an unauthorized users tries to do it, his records won't be accepted due to the lack of the correct DNSSEC signed key.
Conclusion
Stale DNS records have been around for decades; sometimes they go unnoticed, and on other occasions they're used to create chaos among different organizations.
The upside of all this is that any subdomain takeover attack is a 100% avoidable security issue if you have well-trained system administrators performing DNS audits from time to time, and your dev team is using the correct project management procedures.
Are you ready for the fourth part? ➡️ Domain Security & Solutions, Part 4: How to Protect your Account at your Registrar
Do you want to prevent these types of DNS security issues in your online infrastructure? Book a demo with our sales team today to check out SurfaceBrowser™, our enterprise-grade product ready to help you discover the full attack surface of all your DNS infrastructure, including stale DNS records.
¹ https://www.gartner.com/en/newsroom/press-releases/2018-09-12-gartner-forecasts-worldwide-public-cloud-revenue-to-grow-17-percent-in-2019 ² https://twitter.com/powerdns/status/1046475956129603584 ³ https://github.com/EdOverflow/can-i-take-over-xyz
