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).
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!