DNS Vulnerability Notes, part 2

Looks like the details of the Kaminsky DNS vulnerability (intended to be released in mid August) have been discovered early. This was inadvertently confirmed on the Matasano blog yesterday but pulled a few hours later. Fortunately Google Reader cached it for me. I won’t repost it here, though a quick search online should find it. There are also additional details here.

If this is correct, it confirms that it was an issue based on being able to identify a DNS resolver’s source port, combined with the transaction ID, as well as being able to craft a packet to add an Additional Resource Record (this additional RR is where the malicious data is). In the testing I did on Microsoft DNS implementations, prior to the patch, a server’s resolver for recursive data used the same source port for queries. This is one of the fixes in the latest patches; resolvers are now using a random source port for each query.

Knowing the source port makes it moderately easy to spoof a DNS response. Using a slightly different variation of the example in my previous post on this subject, an attacker could use this exploit on an un-patched DNS server as follows:

1) An attacker wants to spoof a DNS response for http://www.youronlinebank.com.

2) The attacker continuously queries your recursive DNS server for xxxxx.youronlinebank.com (where xxxxx is a variable, resulting in a Non-Existent domain response).

3) During this time, the attacker submits a large number of DNS response queries to your DNS server, knowing the source port, all he needs to eventually get correct is the transaction ID. The majority of these packets will be dropped by your DNS server. However, when the attacker finally gets the correct query ID, as long as the malicious packet beats the actual recursive response, it will be accepted.

4) This packet will tell your DNS server that xxxxx.youronlinebank.com can be found at (a rogue IP), but will also contain an Additional RR for http://www.youronlinebank.com, directing it to a rogue IP. A patch to DNS some time ago, called bailiwick checking, specifies that Additional RR’s must match the domain in the DNS query, and in this case, it does.

5) Setting a high TTL on the RR means that your clients are vulnerable to this attack for as long as the record is cached.

So the patch for this at the very least addresses source port randomization, making this current exploit nearly impossible. I don’t know what other fixes are included, but I could see some sort of record name checking on the response being good, though I don’t know what affect that may have on DNS wild-carding (probably none). This is a difficult vulnerability to take advantage of, but still very possible, especially with the details now being out there. Now is a good time to patch this if you haven’t already.

Update (23-Jul): Check here or here for details on how to check your resolvers for this vulnerability. Confirmed that MS patch fixes this by “using strongly random DNS transaction IDs, using random sockets for UDP queries, and updating the logic used to manage the DNS cache“.


One Response

  1. Clay:

    Great post. I’ve assembled some more high level background on the DNS vulnerability plus links at: http://gregness.wordpress.com/2008/07/22/dns-vulnerability-now-in-the-wild/

    Kaminsky was just on a webcast with Cricket Liu talking about the vulnerability and implications.


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: