Introduction
DNS have been there for years now to help you find things normally you wouldn’t remember. In this guide, we will go through the following set of problems that a third party can find and take advantage of in negative terms:
- DNS Zone Transfer
- Subdomain Takeover
- DNS Zone Transfer
Subrake
The primary reason i wrote this blog post was this project i am working on: Subrake. It’s an automated DNS scanner to cover various issues in a single go. Let me know what you think about it in the comment section…
Explanation
Zone Transfer
Zone Transfer itself is not a vulnerability and is a procedure followed to transfer the records of a domain from one DNS server to another. For example, you need to replicate the records of your domain available in namecheap to AWS Route53.
In a Zone transfer, the dns server sends a complete dns records file to another server. The file contains everything the DNS server has regarding that domain including its A, AAAA, CNAME, and SOA records. This includes the information which publicly isn’t accessible.
For example, you can’t access the CNAME records of any domain without having to brute force your way into it. But if the DNS server itself is offering the service, kaboom.
Most of the pople in industry are already aware of Zone transfer, so lets directly jump to the part How to find it?. There are many tools available in the wild to find zone transfer. But the famous and the most simple one is dig:
bash
- The
-t AXFRoption is a type of query to request zone transfer details. - The
+nocookieoption would disable the use of DNS cookies. - And additionally, you can specify
@dns_serverwhich can be skipped to use default DNS servers. I would highly recommend this option if you a playing a CTF or inside a network where a private DNS server is accessible.
If successfull, this would list all the DNS records. This can also be accomplished using subrake -d zonetransfer.me and you would get:
Subdomain Takeover
Subdomain Takeover unlike it sounds is actually the takeover of the service that subdomain is pointing to. Lets say marketing.domain.tld was pointing to an Amazon S3 bucket or ELastic Beanstalk service which actually didn’t exist.
A third party can come and claim this service. Now what happens is that the party that claimed the service can host whatever they want on that subdomain but that ofcourse is limited to what the service has to offer.
Most of the people in industry have been creating their automations of this. Some use their own tools and some have sort of created a workflow.
You can go for a oneliner:
python
Or you can find the subdomains first using different tools and public sources and probably use a tool to check the takeover.
python
Checking the takeover:
python
The list of services that are currently known to vulnerable to Subdomain Takeover can be found at: Can I Takeover XYZ
DNS Zone Takeover
Zone Takeover is a term not too old right now and its actually is as it sounds unlike subdomain takeover. And it can be more severe as you have the control over the complete zone. In order words, you can host your own records and are not limited to the service being used like subdomain takeover.
The normal procedure that is being followed or atleast i follow this:
- I purchase the domain from namecheap or godaddy.
- I create a new
Hosted Zonein AWSRoute53service. - The hosted zone gives me a set of nameservers.
- I enter these nameservers into the Authoritative nameservers section in GoDaddy or namecheap.
- Then i use the
Route53service instead of GoDaddy or Namecheap to manage the records likeA,AAAA, orCNAME.
Infact, if you ever worked with Cloudflare, you would know that you create a new website in Cloudflare. In result you get the nameservers. You then set the nameservers with the domain you purchased.
After doing so, you add/edit/remove the records within the cloudflare panel. Lets suppose, after a year you plan to not use the Cloudflare service anymore. So, you delete your website from cloudflare but doesn’t actually remove the authoritative entries in your domain settings from godaddy.
Since the nameserver entries already exist and still pointing to the service (aka cloudflare in this case), a third party can claim the service which would lead to zone takeover.
If you understand the above scenario, you can relate it to the subdomain takeover where you claim the stale service. But here, its the stale zone.
Finding Zone Takeover
The good thing with zone takeover is you don’t have to brute force your way into it or find anything publicly. The information is already there, you just have to make sure its in the right condition.
The first step would be to get the nameservers of the domain. We can use dig for that:
bash
Or you can directly get the NS records and start looking from there.
The against each NS record, check if any of them fails to responsd. If it does, it can probably be vulnerable to zone takeover. The case it failes, you will have the status as REFUSED or SERVFAIL:
You can also check for SOA which is what i would like to do instead (to be more concise):
Well, if it doesn’t responsd, you can try to claim the service. As of now, the current vulnerable services are available at: Can I Takeover DNS
Well, with subrake, it first tries to resolve each nameserver and if it does then it tries to guess the service and tells if its vulnerable or not. Something like this:
Using Subrake
Subrake can help you pick all 3 above cases. The complete information and details can be found at the link i mentioned in the start of this blog. I am simply attaching a screenshot with the details.
Conclusion
First of all, i hope this guide was helpful 😅. We saw 3 different cases namely, Zone Transfer, Zone Takeover and Subdomain Takeover. The mitigation simply is to be aware of when you remove a service. Make sure the entries in your DNS gets updated as well. Or wrap the service completely.