Wednesday, July 09, 2008

Thoughts on Latest Kaminsky DNS Issue

It seems Dan Kaminsky has discovered a more effective way to poison the DNS cache of vulnerable name servers. This is not a new problem, but Dan's technique apparently makes it easier to accomplish.

One problem is we do not know exactly what Dan's technique is. He is saving the details for Black Hat. Instead of publishing the vulnerability details and the patches simultaneously, Dan is just notifying the world a problem exists while announcing coordinated patch notifications.

I would keep an eye on the following for details as they emerge:

I think this person figured out the server side:

"Allen Baranov Jul 9

Having read the comments and checked out the site mentioned in the blog I have the following theory:

1. I connect to vulnerable DNS Server and query my very own domain. I note what the UDP source port is.

2. I connect to the DNS Server again ASAP and query another of my very own domains. I note what that UDP source port is.

3. Assuming they are close together I do a query of “microsoft.com” or some such and send a UDP reply to the server with a bogus IP address. I could probably send 20 replies so that I get the correct port.

4. Cache is poisoned."

That is the server side of the equation. In other words, if your DNS server is vulnerable, and an intruder poisons the cache, then the intruder now effectively controls the responses sent by your DNS servers to anyone who queries it. As noted by Steve Pinkham's comment on a previously noted blog, "The patches for bind turn on query port randomization by default, and allow a larger range of source ports."

There is also a client side of the equation. Microsoft issued its own advisory in April for the client side: MS08-020.

That reveals how the client side works. Because the Microsoft (and other) DNS clients use insufficiently random transaction IDs, attackers can apparently issue their own responses directly to vulnerable clients issuing DNS requests, if the attacker can reach the host issuing the request.

If I am wrong about any of this please post a comment. When possible I will keep checking the two sources I noted above. I posted this note because I have been receiving questions about this, and it would be helpful to understand what is happening.

14 comments:

Anonymous said...

I think the correct spelling is "Dan Kaminsky."

Augusto Paes de Barros said...

Baranov would be right if there wasn't a Transaction ID that also needed to be spoofed. Trans IDs are usually randomized, so it seems that Dan found an effective way of finding the right TransID because of the lack of source port randomization. It's not just finding the right port number.

pr0j3kt m4yh3m said...

Augusto shut the fuck up you got owned hahahahaha

JL said...

It seems something like this has been written about before.

Anonymous said...

If I do not allow recursive queries from untrusted (read: my) IP addresses, doesn't that limit the attackers to those in my trusted IP's? No recursion, no cache?

Richard Bejtlich said...

Name fixed, thank you!

Phil said...

If you are running BIND, check your named.conf (or equivalent file) very carefully after updating it.

Any lines like

query-source port 53;
query-source-v6 port 53;

need to be commented out or deleted so that forwarded DNS queries come from random ports.

If you run selinux, make sure your selinux polices are updated to handle queries coming from BIND on ports other than 53.

Check that your firewall isn't allowing queries out to the net from port 53 only too.

Phil

Nick Diel said...
This comment has been removed by the author.
Nick Diel said...

Augusto is right. Dan most likely found a way to better guess the transaction ID. The source port has always been trivial, Phil even showed the configuration file which shows how a DNS server can be configured to always use source port 53.

Most likely it will be shown the transaction ID isn't sufficient at 16 bits and a random source port will add the randomness needed...for now. We really needs DNSSec.

The SANS paper referenced by the Register really doesn't shed any light on this subject. DNS Poisoning is just mentioned as an attack vector and doesn't claim the transaction ID increases by one.

DNS Poisoning and the randomness of transaction IDs have been discussed for a long time (see the 2002 paper, "DNS Cache Poisoning - The Next Generation by Joe Stewart"). Now we probably have a model that shows 16 bits is not big enough.

Nick
DNS Poisoning

Nick Diel said...

Anonymous- The UDP packets that trigger the poisoning can be spoofed to be coming from your allowed IPs.

Now if the allowed IPs are just a local subnet then you can use a firewall to prevent those spoofed packets from even getting in the network in the first place.

shopping cart said...

Certainly a fascinating black-hat method. Thanks very much for the information... I wouldn't have heard of this otherwise.

Anonymous said...

richard, could you please find out tomorrow how the countermeasures influnce detection of fast-flux networks?
i had to chancel my attendance at dimva :/

LonerVamp said...

The best theory I've seen running around the full-disclosure and DailyDave lists has to do with ICMP unreachable responses to DNS server queries. I'm sure I'lll massacre the details, so I won't try to explain them here, but I'm sure the archives on seclists.org and elsewhere for the last couple days will have good info.

Unfortunately, Dan otherwise left us in the dark for a month, so we can only guess at the details for now. I don't think it would detract from his talk if he had given details along with the patch/vuln release, nor sell any less tickets to BH. But hey, it's his discovery, he can do what he wants with it, especially as big as it seems to be. :)

dghnfgj said...
This comment has been removed by a blog administrator.