Full Disclosure mailing list archives
Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion)
From: Mark Andrews <Mark_Andrews () isc org>
Date: Tue, 15 Jul 2008 09:14:39 +1000
--On Monday, July 14, 2008 01:01:16 -0400 Valdis.Kletnieks () vt edu wrote:On Sun, 13 Jul 2008 23:30:21 CDT, "eugaaa () gmail 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'sNote 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 gettingan 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 actualgoal 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 () isc org _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion), (continued)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) eugaaa () gmail com (Jul 13)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) coderman (Jul 13)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) eugaaa () gmail com (Jul 13)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) coderman (Jul 13)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) eugaaa () gmail com (Jul 13)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) Paul Schmehl (Jul 13)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) eugaaa () gmail com (Jul 13)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) eugaaa () gmail com (Jul 13)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) Valdis . Kletnieks (Jul 13)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) Paul Schmehl (Jul 14)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) Mark Andrews (Jul 14)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) Paul Schmehl (Jul 15)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) Mark Andrews (Jul 15)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) FRLinux (Jul 15)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) Mark Andrews (Jul 15)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) Paul Schmehl (Jul 15)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) Mark Andrews (Jul 15)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) Paul Schmehl (Jul 15)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) Mark Andrews (Jul 15)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) Valdis . Kletnieks (Jul 15)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) Paul Schmehl (Jul 15)
- Re: DNS Cache Dan Kamikaze (Actual Exploit Discussion) eugaaa () gmail com (Jul 13)