[conspire] DNS vulnerability details

[Rick Moen]

I wrote:

> This is not the hop where the problem occurs.  Remember, as I explained, 
> even to the (questionable) extent that you can flood a client resolver
> library with faked responses to such requests, that doesn't buy the
> attacker very much, because client resolver libraries _don't cache results_.

Here's a particularly good explanation of DNS "spoofing" in general:
http://www.securesphere.net/download/papers/dnsspoof.htm

Here's a Debian Security Advisory giving advice for the aforementioned
"I'm just a desktop user" people:  http://lwn.net/Articles/289277/

  Dan Kaminsky discovered that properties inherent to the DNS protocol
  lead to practical DNS spoofing and cache poisoning attacks.  Among
  other things, successful attacks can lead to misdirected web traffic
  and email rerouting.

  At this time, it is not possible to implement the recommended
  countermeasures in the GNU libc stub resolver.  The following
  workarounds are available:

  1. Install a local BIND 9 resoler on the host, possibly in
  forward-only mode.  BIND 9 will then use source port randomization
  when sending queries over the network.  (Other caching resolvers can
  be used instead.)

  2. Rely on IP address spoofing protection if available.  Successful
  attacks must spoof the address of one of the resolvers, which may not
  be possible if the network is guarded properly against IP spoofing
  attacks (both from internal and external sources).

  This DSA will be updated when patches for hardening the stub resolver
  are available.

Recommendation #1, you will note, is precisely, exactly what I've been
suggesting (particularly) to the desktop / DHCP crowd, here.

Last, here is one fo the above-cited "other caching resolvers":

http://blog.netherlabs.nl/articles/2006/04/20/powerdns-recursor-3-0-released-challenging-existing-nameservers
http://doc.powerdns.com/changelog.html#CHANGELOG-RECURSOR-3-0

To explain, the "PowerDNS" package has been a most impressive suite of
DNS server software for quite some time, and it went open source last
year (if memory serves).  The new development of interest is that
they've made the recursive-resolver _component_ of PowerDNS available
separately -- as PowerDNS Recursor.  And, as I said, a bulletproof,
simple recursive-resolver server with caching is what the world needs.

Users now have several reasonable choices for a nice little caching
recursive-resolver nameserver:  

o  BIND9  (which ain't exactly "little" **grumble**)
o  MaraDNS
o  dnscache (by Dan Bernstein, part of djbdns)
o  PowerDNS Recursor
o  Unbound

Some might add to that list:
o  dnsjava
o  Eddieware Enhanced DNS Server aka lbdns
o  Oak DNS Server
o  Posadis 
o  Twisted Names 
o  Yaku-NS

I track DNS server software of all types available for Linux on 
"DNS Servers" on http://linuxmafia.com/kb/Network_Other/ .  I'll be
adding an entry for PowerDNS Recursor, soonish.


> As Ryan said, the point of vulnerability occurs when DNS.myserver.com
> receives the query (which arrives with the recursion bit set).
> DNS.myserver.com consults its cache, figuratively shrugs "Dunno",
> notices the recursive bit set, and sends the query _onwards_ to somewhere 
> -- some additional nameserver, say, DNS.other.com -- that will
> eventually result in a response being forwarded back, the requested RR
> whose attached TTL value still has some life in it.
> 
> When DNS.myserver.com lobs its outbound copy of the original client's
> request, if it's a dumb, _tradition_-style nameserver, it will use some
> highly predictable source port, e.g., locked to port 53.  All BIND8,
> BIND9 before the current P1 patches, pdnsd, dnsmasq (used in _many_
> embedded appliances!), and Microsoft Windows DNS Server all do the dumb
> thing.  PowerDNS, Dan Bernstein's dnscache (part of djbdns), Unbound,
> and MaraDNS do not:  Those all originate the second-hop request from a
> properly randomised source port.
> 
> There are several obvious ways to induce the original DNS client (the
> one that handed off the request to DNS.myserver.com) to ask about a
> domain that's firmly under the control of the bad guys, e.g., embedding
> references to that domain in Web pages that users of the original client
> machine then are induced to browse.  Let's say that domain is
> evilco.com.  
> 
> 1.  Original DNS client asks DNS.myserver.com "Where's images.evilco.com?"
> 2.  DNS.myserver.com doesn't know, sends outbound query onwards to 
>     DNS.other.com.
> 
> At the same time, the evilco.com guys, alerted to the outbound query to
> evilco.com's Web site, start flooding DNS.myserver.com's LAN with forged
> DNS-response packets that purport to be from DNS.other.com, with a
> variety of QID (transaction ID) numbers, attempting to race back to
> DNS.myserver.com before the genuine response from DNS.other.com does.
> The forged response contains a perfectly serviceable response to the
> "Where's images.evilco.com?" question, but also bears data in the
> "ADDITIONAL SECTION" portion designed to lodge in DNS.myserver.com's
> cache, concerning some other domain entirely.
> 
> With only 65536 possible QIDs, evilco.com has a good chance of
> succeeding.  If DNS.myserver.com's query came from a fixed port, then 
> that's all evilco.com need do.  OTOH, if DNS.myserver.com has also sent
> the query from a randomly selected source port (on which the reply must
> also arrive), then that makes it a significantly more difficult target.
> 
> > I can't help but feel that until of criticle systems services are
> > using cryptography, that we just continue to go in circles.
> 
> There's a saying about crypto not making very good magic pixie dust.
>