Message-ID: <5de3c09b0807132202v6714767ci8e7188886b2eb225@mail.gmail.com>
Date: Mon, 14 Jul 2008 00:02:38 -0500
From: "eugaaa@...il.com" <eugaaa@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: DNS Cache Dan Kamikaze (Actual Exploit
	Discussion)

My analysis of the problem is now that the exploitation happens when a
recursive server goes looking for a record, and in doing so opens
connections to query each nameserver it finds along the path to the
authoritative namserver.

me -> my_dns(recursive)
my_dns -> root
my_dns -> almost_auth
my_dns -> auth_dns

During this period, an attacker floods the query port (or ports) of
my_dns with a valid response for the domain (this is made possible by
weak transaction ID's in most nameservers and the pseudo-randomness of
the query port) and in doing so manipulates the cache.

There were so many avenues of exploitation for this I actually
overlooked the glaringly obvious one.

On 7/13/08, eugaaa@...il.com <eugaaa@...il.com> wrote:
> Yes, the issue was side tracked a bit. And I'm sure I am
> misunderstanding the issue at this point (but I'm also reading
> accounts of multiple vulnerabilities so that cannot be avoided)
>
> But normally in DNS operations, slaves and their master are placed in
> an authority encapsulated domain for transfers. IE. the slaves will
> only axfr zones from the master.
>
> And in the case of recursion, assuming the nameservers are recursive
> it will hit the root and fly downward looking for the zone's
> authoritative nameserver. The exploitation must happen here - a way to
> become the authoritative nameserver. Am I wrong? Because it seems like
> the transferring of zones/records is accounted for. Are we
> manipulating root hints now? Any input is appreciated.
>
>
>
>
>
> On 7/13/08, Paul Schmehl <pschmehl_lists@...rr.com> wrote:
>> --On July 13, 2008 9:44:19 PM -0500 eugaaa@...il.com wrote:
>>
>>> If the nameserver is "down" most likely the resolver is going to try a
>>> different one. Meaning you're back to square one. Which is why I asked
>>> what happens if the resolver recv's a response after it's been told
>>> the nameserver is down. In any case, I'm not even sure how resolvers
>>> handle dest unreachables. And again, I think that avenue is moot.
>>>
>>> As for your question about theory versus practicality. 2^16 seems
>>> possible. This exact same problem exist with ASLR implementations as
>>> well as stack protection mechanisms (canary values etc). I think even
>>> vista's current address space randomization is 16-bits. However with
>>> these DNS transaction ID's you're not looking at a random number. It's
>>> scope is limited because you've seen the transaction ID's of each
>>> request you've made. IE my first request was 125, my second was 133,
>>> etc. Meaning you pick a number higher up (180) and try to win the
>>> race.
>>>
>>
>> I think you are fundamentally misunderstanding the problem.  The
>> vulnerability we're discussing allows you to *poison* a nameserver's
>> cache.  You *want* the nameserver to answer.  You don't want to answer on
>> its behalf.  You want it to answer - incorrectly - so that users are
>> fooled into thinking they've been taken to the real site when in fact they
>> been taken to a "mirror" of the real site, specially prepared for whatever
>> nefarious purpose you have in mind.
>>
>> Paul Schmehl
>> If it isn't already obvious,
>> my opinions are my own and not
>> those of my employer.
>>
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists