full-disclosure - Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 14 Jul 2008 10:47:47 -0500
From: Paul Schmehl <pschmehl_lists@...rr.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: DNS Cache Dan Kamikaze (Actual Exploit
 Discussion)

--On Monday, July 14, 2008 01:01:16 -0400 Valdis.Kletnieks@...edu wrote:

> On Sun, 13 Jul 2008 23:30:21 CDT, "eugaaa@...il.com" said:
>
>> And in the case of recursion, assuming the nameservers are recursive
>> it will hit the root and fly downward looking for the zone's
>
> Note that the TLD nameservers in general won't recurse - so if you're
> trying to look up www.example.com, all the .com server will return is
> an SOA/NS set and *your* nameserver then gets to chase the NS down and
> ask it, and so on.  For a "recursive" lookup, it's pretty damned iterative :)
>
> (Hint - If you're looking up www.foo.bar.example.com, and example.com
> sets its SOA's up right, the .com will give back a first NS saying where
> to find example.com - and then you can make it hit the *same* server getting
> an NS for bar.example.com, and then an NS foo.bar.example.com, and finally
> an A/MX/whatever for www.foo.bar.example.com.  Now make it a contrived name
> that has several hundred levels a.b.c.a.b.c.a.b.c and you have a nice way
> to introspect the sending nameserver's internal state. ;)
>
>> authoritative nameserver. The exploitation must happen here - a way to
>> become the authoritative nameserver. Am I wrong?
>
> You actually don't care if you become the authoritative nameserver. The actual
> goal is to have the victim nameserver accept poisoned data as if it came
> from the authoritative source.  The difference is subtle, but *very*
> important.
>

Precisely.  You query the actual nameserver that you would expect to query and 
you get a response that says www.foo.bar is x.x.x.x when in fact it *should* be 
y.y.y.y.  But you can't tell that, because the nameserver's cache has been 
poisoned and it is responding, as expected, with a "genuine" answer that 
reverses and resolves precisely as you would expect it to - and it's coming 
from the authoritative name server for that host.

The end result is that you get taken to a site that you *think* is legitimate, 
and, if the attacker has done his job, *looks* legitimate in every way but has 
malicious content buried in the returned pages.  And you are none the wiser. 
The only way you could *know* you're being fooled is if you knew in advance 
what the "real" IP was.  Even then you couldn't be certain, because IPs *do* 
change from time to time.

It's extremely insidious and, if "properly" exploited, would destroy all trust 
on the internet.  You could never know for certain whether the hosts you were 
contacting were the real hosts or not.

-- 
Paul Schmehl
As if it wasn'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/