2nd Exploit for DNS Cache Poisoning - RELEASED

[Tuc at T-B-O-H.NET]

Hi,

Not sure if anyone has seen yet, but there is a 2nd
exploit being circulated. I just picked it up on metasploits
SVN trunk....

The first was called "baliwicked_host", and the
description was :

This exploit attacks a fairly ubiquitous flaw in DNS implementations which
Dan Kaminsky found and disclosed ~Jul 2008. This exploit caches a single
malicious host entry into the target nameserver by sending random hostname
queries to the target DNS server coupled with spoofed replies to those
queries from the authoritative nameservers for that domain. Eventually, a
guessed ID will match, the spoofed packet will get accepted, and due to the
additional hostname entry being within bailiwick constraints of the original
request the malicious host entry will get cached.

The new one is called "baliwicked_domain" and its described
as :

This exploit attacks a fairly ubiquitous flaw in DNS implementations which
Dan Kaminsky found and disclosed ~Jul 2008. This exploit replaces the target
domains nameserver entries in a vulnerable DNS cache server. This attack works
by sending random hostname queries to the target DNS server coupled with spoofed
replies to those queries from the authoritative nameservers for that domain.
Eventually, a guessed ID will match, the spoofed packet will get accepted, and
the nameserver entries for the target domain will be replaced by the server
specified in the NEWDNS option of this exploit.



Tuc/TBOH

[Paul Ferguson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Tuc at T-B-O-H.NET
Not sure if anyone has seen yet, but there is a 2nd
exploit being circulated. I just picked it up on metasploits
SVN trunk....

I haven't seen that one yet, but I just ran across this:

http://www.milw0rm.com/exploits/6123

- - ferg


-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.6.3 (Build 3017)

wj8DBQFIiNBFq1pz9mNUZTMRAozhAKD+IkD/HGywNFttPI6ilKreNGP0UQCeKZ98
u76UOCvKXD9+zvdlSR8S/oc=
=N5am
-----END PGP SIGNATURE-----

--
"Fergie", a.k.a. Paul Ferguson
Engineering Architecture for the Internet
fergdawg(at)netzero.net
ferg's tech blog: http://fergdawg.blogspot.com/

[Tuc at T-B-O-H.NET]

Post by Paul Ferguson

Post by Tuc at T-B-O-H.NET
Not sure if anyone has seen yet, but there is a 2nd
exploit being circulated. I just picked it up on metasploits
SVN trunk....

http://www.milw0rm.com/exploits/6123
- - ferg

Sorry, block from the new one :

===============/========================================================
Exploit ID: CAU-EX-2008-0003
Release Date: 2008.07.23
Title: bailiwicked_domain.rb
Description: Kaminsky DNS Cache Poisoning Flaw Exploit for Domains
Tested: BIND 9.4.1-9.4.2
Attributes: Remote, Poison, Resolver, Metasploit
Exploit URL: http://www.caughq.org/exploits/CAU-EX-2008-0003.txt
Author/Email: I)ruid <druid (@) caughq.org>
H D Moore <hdm (@) metasploit.com>
===============/========================================================

Tuc/TBOH

[Jack Bates]

Post by Tuc at T-B-O-H.NET
The new one is called "baliwicked_domain" and its described
This exploit attacks a fairly ubiquitous flaw in DNS implementations which
Dan Kaminsky found and disclosed ~Jul 2008. This exploit replaces the target
domains nameserver entries in a vulnerable DNS cache server. This attack works
by sending random hostname queries to the target DNS server coupled with spoofed
replies to those queries from the authoritative nameservers for that domain.
Eventually, a guessed ID will match, the spoofed packet will get accepted, and
the nameserver entries for the target domain will be replaced by the server
specified in the NEWDNS option of this exploit.

All this sounds good and dandy, but I'm not sure the guessing is the problem.
Why is a resolver replacing an existing cached entry with a new entry? If the
entry changes, at most, the resolver should be removing it from cache. In this
regards, the exploit would not only have to hit it once, but twice, and they'd
have to manage the exploit *BEFORE* the official server returned it's own
authority records for caching.

While I agree the source port is a good thing (and reduces poisoning issues even
when an authoritative server isn't responding), I question if it can actually
succeed at beating the authoritative domain's NS reliably, and if it is
overwriting a cache, if the more exploitable issue is the cache overwrite versus
staling the entry from cache early and letting the next query request from the
authoritative server.

I'm just curious. It doesn't make much sense.

Jack Bates