Matthew Bryant's recent post, Respect My Authority – Hijacking Broken Nameservers to Compromise Your Target, describes attacks against authoritative name servers. These are the name servers that host DNS records for your domain name (A, NS, MX, CNAME, TXT...) and thus the definitive or authoritative sources for resolution, i.e., they host the database that applications use to resolve host names such as your web site name to an Internet address.
Name server hijack example
Bryant's post describes scenarios where domain name resolution for an organization's domain name can be hijacked by an attacker. In one scenario,
(a) an organization has assigned authoritative name server hostnames from several domain names. This is an accepted best practice for name service redundancy. For explanation purposes, let's assume that the organization's domain is example.COM and the organization has hosted authoritative name servers at ns1.example.NET and ns1.example.TOP.
(b) through an error or oversight, the example.TOP registration expires and the organization fails to renew.
(c) the attacker discovers that example.TOP is available, seizes the opportunity to exploit the organization's error, and registers the expired domain name, example.TOP.
The attacker completes the registration process and provides a public IP address for a name server for example.TOP. The TOP registry publishes this in the TOP TLD zone. The attacker also creates a zone file for example.TOP and in this zone file the attacker creates an address record for ns1.example.TOP, the authoritative name server that the targeted organization uses. The attacker can now arrange that ns1.example.TOP resolves to an IP address the attacker controls, or can mimic the address records from ns1.example.NET and wait for an appropriate time to begin its attack.
Next, the attacker publishes bogus zone data of his own composition at ns1.example.TOP; for example, attacker may publish a wild card record that says "send all connections to any host name in the victimized organization's domain to an IP address that I control", where he can now host opportunistic content (e.g., pay per click advertising) or malicious content (malware, phishing).
There are now two different authoritative zone data sets: one that the organization publishes and controls at ns1.example.NET and one that the attacker publishes and controls at ns1.example.TOP. When users query any name in this now vulnerable zone, the user's computer will randomly use ns1.example.NET or ns1.example.TOP for authoritative name resolution and thus some users will visit the host the organization intended and others will visit the attacker's host.
Renewal Considerations for Domain Names, Revisited
ICANN's SSAC wrote an advisory in 2006 to describe "incidents where, by choice or oversight, registrants allowed a domain name registration to expire, anticipating that no harm would come from allowing the registration to lapse". At that time, the committee considered the incidents that illustrated how commercial risk, reputational harm or potential asset loss might ensue following non-renewals of domain names.
Matthew Bryant's post reveals a more nefarious non-renewal threat landscape, a hijacking of name service that allows an attacker to impersonate, deface, spam, or perpetrate fraud using the victim organization's web or other Internet services.
Fortunately, domain name registration protection practices recommended by ICANN's SSAC can help you mitigate threats of this kind.
Protect your organization from threats of this kind!
Consider implementing these recommended practices to minimize name server hijacking threats of the kind Matthew Bryant has discovered:
- Create complete and accurate copies of the domain name registration data (Whois) for all of your domain names and for all of the domain names that you use to assign your authoritative name server names Make certain that you create copies of your intended bindings of authoritative name server names to IP addresses as well.
- Gather abuse point of contact information for the sponsoring registrars of all of these domains and for any DNS hosting provider you use. You'll need these contacts for immediate notification, investigation and correction should you see unexpected changes.
- Monitor Whois for all your domain names and and all the domain names that you use to assign your authoritative name server names. You can easily write and routinely execute a script using command line Whois executables and commands such as cron. Compare your routinely obtained Whois responses against your copies of the Whois you intended to publish. If they do not match, investigate immediately.
- Monitor the DNS to verify that the names of all of your authoritative name servers resolve to the IP addresses you expect to host your DNS information. Again, you can easily write and routinely execute a script to query NS resource records using command line executables such as dig or nslookup and commands such as cron. Compare your routinely obtained DNS responses against your copies of the responses you expect to receive. If they do not match, investigate immediately.
While you're mitigating this particular threat, consider adding domain name portfolio management as part of your organization's overall risk management program. Delegate the responsibility to manage all aspects of domain name registration to an individual or team, or choose from several DNS hosting or monitoring service providers who can do this for your organization. Whether in house or outsourced, staff assigned to this activity should manage approval, registration, brand protection, DNS hosting, monitoring and renewal for all domains you register directly. They should also monitor all domains that you depend upon for correct DNS operation of your domains as well.
Treat your DNS operations as a critical element of your online presence and you are likely to reduce your organization's threat landscape.
