Slashdot Mirror
BIND Still Susceptible To DNS Cache Poisoning
An anonymous reader writes "John Markoff of the NYTimes writes about a Russian hacker, Evgeniy Polyakov, who has successfully poisoned the latest, patched BIND with randomized ports. Originally, the randomized ports were never supposed to completely solve the problem, but just make it harder to do. It was thought that with port randomization, it would take roughly a week to get a hit. Using his own exploit code, two desktop computers and a GigE link, Polyakov reduced the time to 10 hours."
It seems that this only works so quickly because he had 2 machines connected to the server via GigE. Which I would guess means most DNS servers can't be poisoned like this.
Why can't the resolvers make sure to never have multiple outstanding requests that could potentially give the same answer? Check the cache for known zone boundaries and implied non-boundaries (if the server for foo.com also answers requests for x.y.z.foo.com, there's no zone boundary in between), and only send one request crossing a particular potential boundary at a time to a particular server (like a.c.foo.com and b.c.foo.com, we don't know yet that .c.foo.com is answered by the same server as .foo.com, since nothing under that domain is in the cache).
or when updating your cache, compare with your cached copy, and if different ask again to double check.
This has nothing to do with BIND vulnerabilities. DJdns, or whatever you feel is more secure, has exactly the same problem. It is a protocol weakness. The article mentions BIND only because it is the reference implementation for DNS.
The most interesting idea I've seen is to use IPv6 for DNS. The oldest idea is to start using DNSSEC.
You sir are wrong. DJBDNS and PowerDNS are both immune to this cache poising. Yes it is in the protocol, but the protocol is a minimum standard to follow. DJB put in features which allows the cache to only come from defined servers, etc. It is immune to this attack.
Isn't the real issue here our continued reliance on passwords that can be used more than once? When are we going to move wholeheartedly into a single-use password environment?
Incidentally, when is somebody going to throw the fact that US banks have completely ignored the two-factor authentication requirement (part of the Patriot Act, I believe; maybe we should start sending *bankers* to Gitmo and see if *that* gets their attention) back at the finance industry when they start to squeal?
It does not make the attack take "a little longer". It makes cache poisoning take as long as it took before the new attack method. If you only get a chance to poison the cache once whenever the cache purges the target record, then you have to guess the transaction ID correctly on the first try. The new thing about the current attack is that you get as many tries as you want at guessing transaction IDs and port numbers. That only works because servers allow glue to replace already cached records.
Port randomization makes it less probable that you guess right, but since you can guess hundreds of times per second, you'll eventually succeed at poisoning the cache. If the server only accepted glue records when it doesn't already have the information cached, then you could only guess once per TTL.
This isn't an attack one could run against a client out on a DSL line, but if you were able to take over one machine in a colo, you might be able, over time, to get traffic for other machines directed to yours.
True. On the other hand, if you are on the same network segment then there are many other options available to you if you want to do evil. Blasting about 4 terabytes (1 Gb/s for 10H) at a DNS server isn't exactly a quiet attack, so if you intend to stay below the radar you're probably a lot better off trying some good old arp spoofing or tcp hijacking instead.
If J.K.R wrote Windows: Puteulanus fenestra mortalis!