DNS Zone Transfer Vulnerability: Exploitation, Tools, and Prevention Guide

The DNS zone transfer vulnerability is essentially an information disclosure vulnerability. DNS servers are categorized into primary servers, secondary servers, and caching servers. Secondary servers rely on “zone transfers” to copy data from the primary server and update their own databases to achieve data synchronization. This redundancy ensures that if the primary server fails, the secondary server can take over. However, the “zone transfer” vulnerability arises from improper DNS configuration. Normally, only secondary servers should be able to obtain data from the primary server. Due to this vulnerability, any client can use “zone transfer” to retrieve data from the primary server (zone database information). This allows attackers to obtain all records of a domain, potentially exposing the entire network topology, while also saving time on information gathering. For system administrators, allowing untrusted internet users to perform DNS zone transfer operations is one of the most severe misconfigurations.

Since this vulnerability is relatively simple, I reproduced it directly using the Vulhub environment.

In the `dns-zone-transfer` directory, the primary focus is on the `named.conf.local` and `vulhub.db` files. The former is the configuration file, while the latter contains domain name resolution information. To exploit this vulnerability, three main tools can be used: `dig`, `nslookup`, and `nmap`. Note that the `dig` and `nslookup` commands can be installed using `yum install bind-utils`.

The environment is set up using Docker, which will listen on both TCP and UDP port 53. The DNS protocol supports data transmission over both ports. At this point, my VPS is functioning as a DNS server.

Here, I will demonstrate using the `dig` command.

The root cause of this vulnerability is that the DNS server administrator did not restrict the sources allowed to retrieve records, enabling any client to use “zone transfer” to obtain data from the primary server. Therefore, an AXFR-type DNS request is sent.

I successfully retrieved all subdomain records of vulhub.org, confirming the presence of the DNS zone transfer vulnerability. To make a comparison, we can test other domain name servers. Here, I use the commonly used public DNS server `114.114.114.114` as an example.

In this case, querying the resolution of `vulhub.org` was successful, but requesting the zone file from the primary domain server failed, indicating that this vulnerability does not exist.

We can also use an Nmap script to scan for this vulnerability: `nmap –script dns-zone-transfer.nse –script-args “dns-zone-transfer.domain=vulhub.org” -Pn -p 53 ip`

Although this vulnerability is simple, it is highly efficient and accurate for information gathering.

Post Views: 5,516 Appreciation