Ancient But Important: DNS Zone Transfers
What are DNS Zone Transfers?
DNS Zone transfers. As ancient as the vulnerability may seem, it is imperative for cybersecurity professionals to maintain a vigilant watch for the simple yet compromising weakness in their systems. To be sure, most organizations have taken the necessary steps to mitigate zone transfers to unknown hosts since the 1990s. However, as cybersecurity news headlines have highlighted over and over again, organizations can be slow to implement the latest and best security practices.
For those who have either forgotten or never heard of DNS zone transfers, let us recap. A DNS zone transfer is when a portion of a Primary DNS server is copied to a Secondary DNS server. This portion is called the “zone” – hence, zone transfer. There is nothing inherently malicious about this process. In fact, this process is necessary for organizations to have functioning and updated DNS servers. However, a problem arises when the Primary DNS server is configured to respond to any host requesting a zone transfer. By default, DNS servers allow any host to request and receive zone transfers. Considering the valuable data a zone transfer can provide for a threat actor, implementing proper security measures is necessary. Attackers can enumerate for this vulnerability simply by using popular OSINT tools. But before we dive into the details of how to protect against a DNS zone transfer attack, what can a hacker do with a zone transfer?
A simple zone transfer will display more information than one might think. Considering zone transfers can be easily executed on the command line in a matter of seconds, the information output is surprisingly abundant. Using the dig command, an attacker can initiate a zone transfer using a command that looks like this:
# dig +short ns <target>
# dig axfr <target> @<name server>The axfr in the syntax is for making an AXFR request, which is the protocol that retrieves the zone information. If the DNS server being queried does not have any protective measures in place, the server will potentially respond with the all of the following information
- SOA (Start of Authority) record, which contains the name of the server, the name of the administrator of the zone, and the current version of the SOA record
- MX record, which contains the names of mail servers responsible for handling email messages for the organization
- TXT record, which can contain emails, names, phone numbers, or even the IP address of the server
The Dangers of DNS Zone Transfers
Although this collection of information may not immediately grant an attacker enough access to the internal network or sensitive data, it sure would be a valuable source of information for further enumerating the target. Given this information, an attacker can perform social engineer attacks against users found in the zone, password attacks against discovered emails, and further enumeration of hosts discovered through the zone transfer. Additionally, because a short request for the zone records results in such a lengthy response, this server can be used to perform Denial of Server (DoS) attacks against the organization or other outside organizations. This could lead to issues of liability, damage to reputation, or the server being blacklisted, causing connectivity issues for customers.
No organization wants this much information out and available to the public. From a security standpoint, an organization’s goal should be to limit information on internal systems as much as possible to the public. Fortunately, protecting DNS servers against foreign requests for zone transfers is not complicated.
Mitigation
The most common solution security professionals can find online is an IP-based access control list. An organization can practice the Rule of Least Privilege and only place the IPs of appropriate users on a whitelist for requesting axfr requests to the DNS servers. These seemingly simple solutions will provide much improved security, as foreign hosts will no longer be able to obtain telling internal information from unauthenticated DNS zone transfer. Finally, administrators can practice further security practices by keeping the DNS servers patched and performing routine audits of the DNS servers.
