Today, I came across a blog post that once again showcases the importance of properly managing DNS through its entire lifecycle.
The article entitled “Respect My Authority – Hijacking Broken Nameservers to Compromise Your Target” (sic) was written by Matthew Bryant (
@IAmMandatory). It can be
found here. It’s a bit of long read but serves as a great reminder about the importance of understanding and managing your important DNS data from inception through final destruction.
The basic concept discussed deals with expired domain names that at one time had one or more authoritative name servers bound to that domain and served as authoritative name servers for other zones. Over time, domains fall out of use and their registration lapses. Many times, owners of those domains fail to remove authoritative name server registrations from the top-level domain servers, leaving the no-longer-functioning name servers in the expired domain listed as authoritative for one or more other zones or both. Incomplete or ineffective garbage collection over long periods of time can lead to big security holes.
Keep in mind that technically any name server that is acting as either a primary master or primary slave authoritative name server and providing data to name servers outside the local zone needs to be registered with the parent domain. For example, any name server that is listed as authoritative and listed with the registrar for TRIPWIRE.COM must be registered as a name server with the .COM domain.
This is typically done through an approved registrar with access to the appropriate TLD. Unfortunately, this requirement does not prevent the use of unregistered name servers being listed in NS records for publicly accessible authoritative
DNS. Also, there is no mechanism in the normal DNS lookup process that validates whether or not a name server is registered with the parent zone and nothing that checks the registration status of the domains used by listed name servers.
Name servers that are listed in NS records for a given zone but not listed as name servers for the zone with the zone’s registrar are referred to as stealth name servers. Stealth name servers may or may not be registered as authoritative name servers within the parent zone. You can read more on the technical requirements for authoritative name servers
on the IANA web site. The case described in the blog post is essentially the inverse of the stealth name server scenario. Name servers are listed with the registrar, but one or more of the domains associated with the name server have a lapsed registration.
The security concern described in Bryant’s post deals with the following case:
- One or more NS records listed with a zone are part of a different zone.
- One or more of the zones containing the NS hosts have an expired registration.
The example used in Bryant’s post is iom.int. He found that two of the four listed name servers were functional and two were not. The name servers in the org.ph zone failed to respond. Further investigation revealed that the org.ph domain was unregistered. All a malicious actor need do at this point is:
- Register the available domain though a supporting registrar (org.ph).
- Configure DNS on the zone (in this case the sub zone iom.org.ph).
- Set up the appropriate A records for the listed name servers (ns1.iom.org.ph & ns2.iom.org.ph).
- Set up a DNS service that listens on the IPs pointed to by the above A records.
- Configure desired DNS responses for original zone with the previously broken NS records.
In the example in Bryant’s post, there were four name servers. He was able to successfully hijack two of the four using the above process. This means that his name servers would respond to approximately 50% of all authoritative requests. This would continue until such time as the owner of ion.int removed the rouge name servers from the name server settings list at the registrar.
If the owners of ion.int did nothing, Bryant could – in theory – hijack 50% of all traffic destined to ion.int since most DNS lookups utilize round robin requests. By altering the TTL data for records served up by the rouge name servers and omitting the valid NS records from his bogus DNS zone, it is likely that over time, the amount of DNS traffic influenced by the bogus name servers could approach 100%. Additionally, he could also theoretically request SSL certificates, re-direct email, spoof SRV records, and ultimately permanently hijack the target domain. His post explains the methods involved in more detail.
Starting to see how inattention to details can come back to bite you if you mismanage your DNS?
So, if you don’t own any domains, this stuff doesn’t impact you, right? Wrong! As a normal user of the Internet, almost everything you do is dependent upon DNS and the accuracy and trustworthiness of that DNS data.
Bryant’s post also references a tool he developed called
Judas DNS. We all know Judas as the one who betrayed Christ so the name is fitting. Judas DNS is DNS proxy server that can take the place of a hijacked name server and perform targeted exploitation. It can be configured to target specific source IP ranges, particular zones, or a combination of both. TTLs are adjustable. This tool could also be deployed in a MITM attack to target a specific IP on the target network.
So, how can you protect yourself from these kinds of deceptive attacks?
First, know your network! Only connect using trusted devices connected to trusted networks. If you must use unfamiliar networks, invest in a quality VPN provider. Only send data over VPN connections. This will insure that your data is safe from prying eyes while in transit between your device and the
VPN provider. What happens after your data leaves the VPN end point is difficult to control.
Second, use only trusted DNS providers. On static networks, configure your firewalls to allow DNS response traffic only from trusted DNS sources. Make sure trusted DNS resolvers forward unknown queries to the root zones for resolution. It is not possible to verify the legitimacy of DNS requests unless DNSSEC is enforced on a particular zone. If you are concerned about a particular domain, use available tools to verify the DNS configuration. Compare zone data on all listed name servers. They should all match! DNS integrity has never been a priority. This will need to change.
If you are responsible for managing domain name registrations for your company, be sure to do regular audits of your DNS name server settings at the domain registrar making sure that all the listed name servers are correct, legitimate, and actually point to registered domains that are functioning. Also, check to make sure that all DNS records in your forward and reverse zones are valid, removing any that have expired or are no longer valid.
Take care of your DNS, and be safe out there!
About the Author: Jim Nitterauer, CISSP is currently a Senior Security Specialist at AppRiver, LLC. His team is responsible for global network deployments and manages the SecureSurf global DNS infrastructure and SecureTide global SPAM & Virus filtering infrastructure as well as all internal applications and helps manage security operations for the entire company. He is also well-versed in ethical hacking and penetration testing techniques and has been involved in technology for more than 20 years.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
