Re: Exploit for DNS Cache Poisoning

* Joe Greco · * Wed Jul 23 21:44:33 2008

> Before, if you wanted to poison a cache for www.gmail.com, you get the  
> victim name server to try to look up www.gmail.com and spoof flood the  
> server trying to beat the real reply by guessing the correct ID. if  
> you fail, you may need to wait for the victim name server to expire  
> the cache before trying again.

That's why that crummy technique isn't used.

> The new way is slightly more sneaky. You get the victim to try to  
> resolve an otherwise invalid and uncached hostname like  
> 00001.gmail.com, and try to beat the real response with spoofed  
> replies.

That's the normal technique, as far as I was aware.

> Except this time your reply comes with an additional record  
> containing the IP for www.gmail.com to the one you want to redirect it  
> to. 

Thought that was the normal technique for cache poisoning.  I'm pretty 
sure that at some point, code was added to BIND to actually implement
this whole bailiwick system, rather than just accepting arbitrary out-
of-scope data, which it ... used to do (sigh, hi BIND4).

> If you win the race and the victim accepts your spoof for  
> 00001.gmail.com, it will also accept (and overwrite any cached value)  
> for your additional record for www.gmail.com as well. If you don't win  
> the race, you try again with 00002.gmail.com, and keep going until you  
> finally win one. By making up uncached hostnames, you get as many  
> tries as you want in winning the race.

Right.  To the best of my knowledge, that's neither a new nor a clever 
technique for generating additional DNS request transactions.

> By tacking on an additional  
> reply record to your response packet you can poison the cache for  
> anything the victim believes your name server should be authoritative  
> for.

And that's one standard form of poisoning.

Cache poisoning and sending extra data is an interesting topic.  I have
to admit that my experience with it is somewhat dated, and a lot of it is
as much as a decade out of date, when I was writing miniature authoritative
name servers for application load balancing purposes.  I did in fact do
a number of experiments against various implementations to see what sins I
could get away with, and I have to say, the protocol is remarkable in that
so many broken-seeming things that I deliberately inflicted while playing
around can be worked out by server implementations.  But, then again, the
beauty of DNS is that it hasn't really changed much over time ...

> This means DNS cache poisoning is possible even on very busy servers  
> that normally you wouldn't be able to predict when it was going expire  
> its cache, and if you fail the first time you can keep trying again  
> and again until you succeed with no wait.

This is disappointing, because Vixie specifically stated that this was a 
new attack, and I'm pretty sure he said it was one where the exploit could
not be determined merely by knowing the sort of change that was being made
to BIND.

Well, the change that was made to BIND was to randomize source ports,
which indicated it was a forged-response attack of some kind.

Knowing that there were further statements about the weakness of the PRNG
for the QID suggested that it was susceptible to a brute-force attack.

I guess there's a vague hint of novelty in it all if you want to be a tad
more clever about what you're corrupting.  I can think of a few examples,
which I will respectfully not discuss, just in case someone hasn't thought
of them, but basically it seems to me that this is neither a new nor a 
novel attack.

So I'm not super impressed.  Do I see the need for the patch?  Yes.  Do I
see the need to lie about the nature of the problem?  I guess, but this is
not any more of a problem today than it was a year (or ten!) ago, except 
maybe now someone is threatening to finally do something that might cause 
DNSSEC to get deployed, which seems like it would have been a better way
to scare people, IMHO.

I think a bunch of us saw the problem with spoofed DNS years ago, and I'm 
pretty sure a bunch of DNSSEC people have been predicting exactly this 
state of affairs for quite some time, and knowledge of the general problem 
predates even that.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Exploit for DNS Cache Poisoning - RELEASED