Since researcher Dan Kaminsky notified the world about an amazing DNS exploit, numerous tools and attack techniques have emerged to take advantage of the flaw. While many organizations have done an outstanding job patching their external servers, many are dragging their feet on patching their internal ones. This is a tragic mistake. This tip details why the DNS flaw is so dangerous, and why enterprises that continue to ignore it are putting themselves at risk.
History: Kaminsky's DNS vulnerability
Prior to 1997, the DNS system was set up in such a way that an attacker could poison the cache of a network simply by asking the DNS server of a target organization to resolve the IP address of a site that the attacker had control over, i.e. www.evil.com.
The security community solved this problem by forcing DNS servers to only receive answers that were "in-bailiwick." "In-bailiwick" means that the response from the evil.com DNS server can only answer with records that end in "evil.com": mail.evil.com, ftp.evil.com and www.evil.com, for example. Further, DNS records now have a time to live (TTL), a value that establishes how long a particular record will be active before it can be overwritten.
Following that change, an attacker wishing to poison the cache of a DNS server would need to not only make a request for a site, like www.yourbank.com, but also send a spoofed response to that request from yourbank.com's DNS server. So, prior to Dan Kaminsky's discovery, an attacker had a 1 in 65,536 chance to guess the 16-bit transaction ID (TXID) and poison the cache of a remote DNS server. Additionally, if the attacker was not able to guess the proper TXID before the true yourbank.com server responded, the real answer would be cached, and the TTL for that answer would force the attacker to wait an hour, day or two days (depending on the DNS server's settings) before trying again.
Kaminsky discovered that it's possible to start thousa
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
nds of races to resolve mostly bogus records. The attacker's goal is for one of his or her spoofed responses to beat the real one and have the correct TXID. For example, an attacker could query for 1.yourbank.com, 2.yourbank.com, 3.yourbank.com, and so on. Let's say an attacker's spoofed response for 57.bank.com has the proper TXID. The target's DNS server would process the response, saying the IP address for 57.yourbank.com was at the name server www.yourbank.com. However, the IP address for www.yourbank.com could be an IP address that the attacker owned. This attack works because the record for www.yourbank.com is in bailiwick with 57.yourbank.com.
Weaponizing the vulnerability
If attackers can poison the cache of a DNS server, they can redirect legitimate traffic anywhere they want. There are a staggering number of services that rely on DNS to resolve IP addresses. Electronic mail, for example, relies on DNS to find the IP addresses of additional mail servers on the Internet. In fact, many spam filter implementations use Sender Policy Framework (SPF) to identify the proper IP addresses of an email's originating location, and SPF uses DNS to identify those "proper" IP addresses.
It should also be noted that there are now modules incorporated into the Metasploit framework that allow this vulnerability to be easily exploited. When tools like the new Metasploit Auxiliary modules are coupled with tools like evilgrade, which exploit insecure updates in applications like Winamp, QuickTime, Java and Notepad++, it can lead to devastating consequences for internal network segments.
Defense considerations
Kaminsky's DNS flaw is not only high-risk to enterprises, but it's also relatively easy for attackers to exploit to hijack traffic for applications like mail, SSL-encrypted sessions and standard websites -- almost transparently to the end user.
For detection of these attacks, enterprises should review the cached IP addresses for the clients and the DNS servers that may be compromised. Then check any suspicious IP addresses against an external source like the American Registry for Internet Numbers (ARIN) or DNSTools.com. Most IDS vendors have signatures to detect this attack. Check your organization's signatures to verify they are up to date. It is possible to review the IP addresses with DNS servers other than your own, using tools like nslookup and the Web-based DNS Dig tool. If there are indications that a client or DNS server has been compromised, immediately check to see if the proper patches have been installed.
Even though the flaw has been disclosed and vendors have released patches, the DNS vulnerability problem has not been completely solved yet. The patch that vendors have been applying randomizes the source port of the DNS request. So now an attacker must guess the TXID and the source port of the request. This is not a perfect fix, but it is sufficient in the short term. Worse yet, there have been some instances of environments utilizing port address translation (PAT), which may undo the effects of the DNS patches. For these reasons, it is critical that enterprises do everything they can to protect themselves.
The DNS vulnerability can be actively exploited by a threat from outside of and within our networks. Unfortunately, many organizations have not patched their internal DNS servers. With the ease of use now incorporated into tools like Metasploit and evilgrade, it is even more important for organizations to patch their internal servers. The belief that the threat is only outside of our network has been consistently wrong and will continue to be so well into the future.
When patching internal systems please keep in mind that the new overhead in generating "random" source ports for DNS requests will incur an additional burden on an organization's DNS servers, meaning a hardware upgrade may be necessary in addition to any needed patches. The problem seems to be particularly prevalent in older Solaris servers. Also, if a DNS server sits behind a port address translation (PAT) device, it may not keep the source ports random, thus reintroducing the problem even if the DNS server has been patched. As always, and if possible, test before patching.
About the author:
John Strand currently is a Senior Security Researcher with his company Black Hills Information Security, and a consultant with Argotek, Inc for TS/SCI programs. He teaches the SANS 504 "Hacker Techniques, Exploits and Incident Handling," 517, "Cutting Edge Hacking Techniques," and 560 "Network Penetration Testing" classes as a Certified SANS Instructor. Strand also answers your questions on information security threats.
