Research

Staying one step ahead of the ever changing threat landscape is a strategic imperative for Veracode. Whether it’s desktop apps, web apps or mobile, we’re constantly looking for software vulnerabilities. If we discover something interesting this is where you’ll read about it.

What Dan’s DNS Checker Doesn’t Do

Posted by Chris Eng in RESEARCH, July 10, 2008 | Comments (6)  

Despite what various commenters around the blogosphere think (I’ve read a few but can’t find the links now), Dan Kaminsky’s online “Check My Dns” utility doesn’t:

  • Poison anybody’s DNS cache
  • Expose how the actual exploit works

What it does is check whether your ISP’s DNS server is patched. Plain and simple. It looks for one thing — source port randomization. This does not give away the exploit, it checks for the existence of the sledgehammer fix that prevents the exploit from working.

More specifically, there’s some Javascript code that generates a random hex string which is used to create a URL, e.g. http://6313d97e498e.toorrr.com. Your OS then does a DNS lookup for that unique hostname. Your ISP’s DNS server asks toorrr.com’s DNS server (a server Dan controls) to resolve that funky DNS name to an IP address. It sends a few packets in the process. Dan’s server makes a note of the source port of each request and sends back the webserver’s IP address to your DNS server, which sends it back to you.

Now that you have the IP address, your browser can fetch the results page. The web page is generated dynamically by parsing the hex string out of the URL you requested, using Ajax to fetch the relevant port and TXID data stored on Dan’s server, and printing out a “safe” or “vulnerable” message such as:

Your name server, at 71.243.0.38, appears to be safe.
Requests seen for 6313d97e498e.toorrr.com:

71.243.0.38:45298 TXID=13926
71.243.0.38:45310 TXID=25412
71.243.0.38:45338 TXID=30829
71.243.0.38:45332 TXID=13934
71.243.0.38:45321 TXID=2701

That’s all. Nothing tricky. This particular DNS server is deemed safe because the source port varies from one request to the next.

Come to think of it, those source ports don’t really look that random, do they? For anybody “in the know”, is that amount of randomness sufficient to protect against the attack?

Veracode Security Solutions
Veracode Security Threat Guides
6 Comments »

*sighs*

There’s a bug in the code. Note that’s not very random.

Comment by Dan Kaminsky — July 10, 2008 @ 6:23 pm

@Dan:

Ah, so I’m not going crazy then. Thought that looked suspect.

Comment by Chris Eng — July 10, 2008 @ 9:02 pm

I’m also interested in the comments highlighted by Tom Cross from IBM/ISS X-force reiterating a comment sent to FD regarding DNS and NAT devices. You can find Tom’s post here: http://blogs.iss.net/archive/dnsnat.html

” I’m writing this blog post in order to draw more attention to that observation, as I’m not sure that the security industry has realized its full implications. As far as we know, this observation applies to any NAT device, not just the firewall imipack tested, and we think it has significant implications for network architecture.

When a host on a computer network selects a source port for a UDP request, it selects a port that is unique for that host. When a one-to-many hiding NAT device receives that request and translates it, it has to assign a new source port, because the NAT device has to assign unique ports for all of the hosts on the internal network. X-Force is not aware of any NAT device on the market that randomly selects UDP source ports. Therefore, when patched DNS clients and servers are used behind NAT, they are still vulnerable to attack. The source port entropy introduced by the recent patches is cancelled out by the NAT device.

It is our opinion that network administrators who have caching internal DNS servers behind NAT should plan to move those servers into a DMZ where they can be directly assigned a unique Internet IP address. Any servers that remain behind NAT devices will remain vulnerable after patches have been applied, and X-Force suspects that given the amount of media attention DNS Cache Poisoning has received this week that an increased frequency of attack is likely in the coming months.”

What say thee to that? Patching may not be enough if you physically have to move DNS servers to what amounts to DMZ’s and then expose them with 1-to-1 NAT’s instead of hides…oh the fun.

/Hoff

Comment by Christofer Hoff — July 10, 2008 @ 9:24 pm

@Hoff:

I’ve been waiting for someone to respond in an official capacity to the question you and Tom Cross raised.

I guess this is the closest thing so far:
http://www.circleid.com/posts/87143_dns_not_a_guessing_game/

Comment by Chris Eng — July 15, 2008 @ 8:41 pm

Information about working around the NAT issue just hit my website.

Comment by Dan Kaminsky — July 18, 2008 @ 7:18 pm

@Chris Eng
This is a pretty interesting take on it. I hadn’t even thought about it before, but you’re right… regarding the NAT issue, that has huge implications across the Internet and deep within the consumer-base itself.

Incidentally, theReformed was running a poll on Dan’s find posted the other day, so far Dan seems to be coming out on top with the people http://thereformed.org/2008/07/19/poll-dan-kaminskys-dns-poisoning-bug/ .

@Dan Kaminsky
How does this not effect DJBDNS? I know DJB has campaigned for years against BIND’s flawed existence, why hasn’t his product received wider adoption?

Comment by Jesse Cantu — July 20, 2008 @ 11:51 am

RSS feed for comments on this post. TrackBack URI

Leave a comment

Powered by WordPress