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.
Comments
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
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
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.
i had to chancel my attendance at dimva :/
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. :)