Ask any security professional to name the most commonly exploited services and chances are the Domain Name Service...
(DNS) will be near the top of the list.
At the 2008 Black Hat briefings, security researcher Dan Kaminsky revealed the details of a "new" flaw in DNS (or, more accurately, the new combination of two old flaws in an effective vulnerability cocktail).
It's worth noting that Dan followed the responsible disclosure process; he informed major DNS software vendors of his discovery months before his Black Hat presentation. However, as often happens with major vulnerabilities, some details about the DNS flaw leaked in advance of Black Hat, leading to a whirlwind of speculation and panic as white hats scrambled to patch their servers before the black hats developed exploit code. As I write this, there is already DNS exploit code in the wild.
Kaminsky's DNS exploit explained
So how does Dan's attack work? It's based upon two well-known vulnerabilities in DNS: transaction ID guessing and referral records. When a server makes a DNS request, it identifies the request using a unique transaction ID that enables the server to validate responses and ensure that they're from the correct query.
The problem is the transaction ID range is limited to 65,535 possibilities, making a guessing attack possible. If an attacker knows a DNS query is being issued, he can attempt to forge a response to that query with a random transaction ID. In that case, he has a 1 in 65,535 chance of getting it right.
Either of these vulnerabilities by itself isn't really a big deal: they've both been documented for years. Odds like 1:65,535 aren't very appealing to hackers and all current versions of DNS support bailiwick protection. The intriguing twist in Kaminsky's attack is the way he combines the two. First, he points out that there's no limit on the number of incorrect transaction IDs you can guess, so it's basically a race between the hacker and the legitimate server. If an attacker can send 100 false responses before the legitimate server replies (a feat which Kaminsky claims is possible), the 1:65,535 odds can be improved to a much more favorable 1:655.
At this point, you may be asking yourself, what's the big deal? If a malicious hacker wins the race, he or she is only able to poison the DNS for that specific query. That's where the true danger of Kaminsky's attack comes into play. His second significant contribution is noting that, although bailiwicks apply for most DNS response data, they don't apply for referrals to other DNS servers. So, an attacker could respond to the evilmalware.com query with a response stating, effectively, "I don't know, but you can find it at searchsecurity.techtarget.com, which is located at 188.8.131.52." In accomplishing this, it's possible to direct traffic to arbitrary locations of an attacker's choice.
Patching the DNS flaw
Fortunately, Kaminsky also describes a response and has spent the last several months furiously spreading the news among DNS server vendors. The answer is to use source port randomization. This removes the currently predictable nature of DNS source ports and replaces it with a randomized selection technique. Now, the attacker needs to guess not only the correct transaction ID, but also the correct UDP port to flood with replies. This will result in a much more unwieldy 1:163,840,000 success rate, rendering the attack useless.
Security managers reading this should immediately determine whether the DNS servers covering their enterprises are vulnerable to the attack and, if they are, patch them immediately. As of today, patches are available for all major operating systems through normal support channels. To test servers for the vulnerability, Kaminsky provides a nifty DNS Checker tool that sends a bunch of queries to his own DNS server and then analyzes them for the use of predictable source ports.
Protect remote connections from DNS flaw
Once an organization has patched its own DNS servers, there's still more work to do. Users operating within the friendly confines of the corporate infrastructure are protected, but it's important to remember that this isn't the only place that users access the Internet. They work from home and travel, taking advantage of Internet access (and DNS services) offered by various commercial ISPs, hotels, restaurants, airports and other Wi-Fi hotspots.
That said, so far the DNS vulnerability has been a case study in security awareness and prompt patching. At Dan's talk, he cited statistics that more than 80% of DNS servers worldwide are already patched, including many of those used by major providers.
This means steps must be taken to protect enterprise users when they're away from the office. While it might be tempting to point them at the DNS Checker tool, that's not really a practical solution, since it requires both remembering to run the check and possessing the technical ability to interpret the results.
A better strategy is to ensure employees use the VPN to connect back to the enterprise infrastructure. Be sure that the configuration isn't using split tunneling and that the VPN pushes DNS configuration. This ensures that remote users will use their enterprise's DNS servers, rather than relying upon those provided by the access site. For the truly paranoid, configure the VPN client with a hard-coded IP address, eliminating the client's reliance on the local network's DNS server to find a path home.
Overall, Kaminsky outlined an extremely serious threat to the security of the Internet. Our shared infrastructure depends upon the proper functioning of DNS and a mutual trust that it properly resolves names. If you haven't already checked the patch status of your servers, do so immediately. Once the remaining 20% of servers are patched, we'll be safe from DNS exploits -- at least until Kaminsky's next Black Hat presentation!
About the author:
Mike Chapple, CISA, CISSP, is an IT security professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a frequent contributor to SearchSecurity, a technical editor for Information Security magazine and the author of several information security titles, including the CISSP Prep Guide and Information Security Illuminated. He also answers your questions on network security.