Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion)

["eugaaa () gmail com" <eugaaa () gmail com>]

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 () gmail com <eugaaa () gmail 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 () tx rr com> wrote:
> > --On July 13, 2008 9:44:19 PM -0500 eugaaa () gmail 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/