Re: [Full-disclosure] DNS Cache Dan Kamikaze (Actual Exploit Discussion)




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

On Sun, 13 Jul 2008 23:30:21 CDT, "eugaaa@xxxxxxxxx" 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 gettin
g
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 act
ual
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 an
d
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 ha
s
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 trus
t
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/

And the best solution to this attack is to deploy DNSSEC.
You don't care where the response comes from provide the
signatures are good.

Deploying BCP 38 as widely as possible will minimimize the
places where such a attack can be successfully launched
from.

Randomising the source port reduces the ability of the
attack to succeed. This however requires firewalls to keep
more state and doesn't interact well with other UDP
applications on the same machine.

Randomising the source address reduces the ability of the
attack to succeed. This also has the same negatives as
randomising the source port.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@xxxxxxx

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



Relevant Pages

  • The Art of Unspoofing
    ... stack allows anyone to send spoofed packets to a target host, ... the ability of its administrator to determine the origin of the attack. ... then can it inject the malicious packets. ... host of the attack or their nameserver. ...
    (Focus-IDS)
  • The Art of Unspoofing
    ... stack allows anyone to send spoofed packets to a target host, ... the ability of its administrator to determine the origin of the attack. ... then can it inject the malicious packets. ... host of the attack or their nameserver. ...
    (Bugtraq)
  • [NEWS] The Art of Unspoofing
    ... anyone to send spoofed packets to a target host, ... people to think of more intricate ways to attack servers on the net. ... In order to send the spoofed packets to target.com, ... the attack or their nameserver. ...
    (Securiteam)
  • Re: named recursive queries
    ... It seems clear that people who want to run a recursive nameserver will be able to change this if your proposed change is made. ... Yes, people can send queries with a spoofed sender to perform a DoS, and yes, permitting recursive queries lets the attacker choose a large response from any zone rather than having to tailor the attack to each nameserver. ... I'd be happier if named grew a mechanism to rate-limit queries made by foreign networks, rather than this change. ...
    (freebsd-current)
  • Re: [Full-disclosure] DNS Cache Dan Kamikaze (Actual Exploit Discussion)
    ... connections to query each nameserver it finds along the path to the ... There were so many avenues of exploitation for this I actually ... And in the case of recursion, ... become the authoritative nameserver. ...
    (Full-Disclosure)