bugtraq - Re: Windows DNS Cache Poisoning by Forwarder DNS Spoofing

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 for Android: free password hash cracker in your pocket

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

Date: Tue, 17 Apr 2007 17:27:13 -0400
From: Tim <tim-security@...tinelchicken.org>
To: "Roger A. Grimes" <roger@...neretcs.com>
Cc: bugtraq@...urityfocus.com
Subject: Re: Windows DNS Cache Poisoning by Forwarder DNS Spoofing

Roger,

This is what I know about it, since no one else seems to be giving you
more info...

> As described above, Windows DNS is vulnerable to the cache poisoning
> attack through the forwarder DNS server. This seems because Windows DNS
> blindly trusts replies from forwarder DNS and caches every resource
> records regardless of their domain.

The original vulnerability was the issue that Windows DNS server accepts
records from unauthoritative sources.  This was partially fixed with
some registry setting (insanely off by default), but it turned out if
Windows was using an upstream resolver (i.e. not going directly to the
roots), then it was still vulnerable.  This is the vulnerability which
is specific to Windows DNS (though Symantec's also had it, I think).

For instance, if a Windows DNS cache asks for example.org, and receives
records for example.org and org (TLD), then it will blindly believe it,
under certain conditions.  BIND does not do this, AFAIK, and neither
does any correctly implemented DNS cache.

The attack described just now, is that this vulnerability combined with
the traditional "birthday" attack scenario allows another form of
attack.  The birthday attacks in general are still possible on any DNS
server which doesn't randomize source ports, but may be more difficult
to conduct than this new attack. (I'm not sure, I haven't run the
numbers.)

Hope this clears it up.  If you're interested in running a more secure
DNS cache, try djbdns' dnscache.  

tim

PS- Please correct me if I messed up any of the details on the Windows
    DNS vulnerability.  This is all straight from memory... didn't
    double-check my sources.