DNS Vulnerability Notes

I’ve been experimenting with various DNS implementations this week since the release of the latest cache poisoning vulnerability discovered by Dan Kaminsky (http://www.kb.cert.org/vuls/id/800113). The Nemesis utility, included on the BackTrack 3 distribution, is great for crafting & injecting DNS packets onto the wire (and just about any other packet type) to do this type of testing.

The exact technical details won’t be released until early August, but it appears this DNS vulnerability is possible because a response to a DNS client request is typically considered valid if a minimum of 3 requirements are met: 1) the response must be sent to the port that the request originated from, 2) the DNS message transaction ID must match, and 3) the response should contain the correct resource record (RR) asked for in the request. Depending on the resolver, other conditions may need to be met, such as the source IP of the response matching the destination IP of the original request. Also I’ve found that #3, the response containing the correct RR, isn’t always required, depending on the client. RFC 1035 has all the technical details: http://www.faqs.org/rfcs/rfc1035.html

This weakness in DNS and the ability to exploit it have been known for several years, and somewhat addressed by various software updates. In the past, resolvers would start the source port and the DNS message transaction ID’s at a certain point, and then increment these in subsequent requests by one. This made it very easy to guess what these values would be in future DNS requests. Later versions of Microsoft OS’s randomized the transaction ID, but often used the same source port for requests, and the randomnization of the transaction ID’s was suspect. This vulnerability is such a big issue because it allows an attacker to spoof a response to a client’s name resolution request; when a request is made to a recursive DNS server that doesn’t hold the required zone info, that server then becomes a client itself. So not only is there potential to poison the cache of a single client, there is potential to poison a DNS server’s cache, potentially impacting all the clients of that server.

Consider the following: through several possible methods, an attacker is able to determine what the expected possible transaction ID and source port of the next DNS request will be on your DNS server. He then makes a query to your recursive DNS server for http://www.youronlinebank.com. Having previously configured Nemesis to respond to this request, he injects this packet into the network to respond to your DNS server’s request (or quickly injects multiple packets to increase chances of success). As long as the attacker’s response beats the valid response to the DNS server (and meets the RFC 1035 requirements), it will be accepted. The DNS answer will direct traffic to a rogue IP address, on which the attacker will have set up a website identical to youronlinebank.com. From there, passwords can be stolen from unexpecting users. This is a high level overview and there are several factors I won’t get into here that may decrease or increase the attacker’s chances of success, but this is just an example of one possible exploitation.

The bottom line is to make sure your DNS servers and clients are patched to address this (the CERT link above lists vulnerable systems). It is fairly easy with a little know-how (and patience to convert text to hex to binary) to exploit DNS with tools such as Nemesis. Those interested in trying this to see exactly how it works can still do so even on patched Microsoft systems, as long as the nslookup utility is used as the client. I’ve found this tool still increments source port and transaction ID by one, even on patched XP, 2003, and 2008 systems (I haven’t yet tested Vista or other OS’s). Hopefully this recent exploit and others like it will raise awareness of the need to secure DNS with something along the lines of DNSSEC.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: