regarding the critical DNS protocol vulnerability

[Doug Pearson <dodpears () INDIANA EDU>]

Regarding the recent critical DNS protocol vulnerability, I imagine
you've all seen and read a lot already. Here are few items that crossed
the REN-ISAC mailing list over the past couple of days. In chrono order:

==========

From the R-I Daily Watch Report, Tuesday 2008-07-08:

Multiple DNS implementations vulnerable to cache poisoning

Caching name servers should be patched in a timely manner. The issue
affects all platforms - it's not a specific implementation issue, but
a problem with the DNS protocol itself.

US-CERT: The general concept of cache poisoning has been known for
some time, and a number of inherent deficiencies in the DNS protocol
and defects in common DNS implementations that facilitate DNS cache
poisoning have previously been identified and described in public
literature. Recent research into these and other related
vulnerabilities has produced extremely effective exploitation methods
to achieve cache poisoning. As a result, the consensus of DNS
software implementers is to implement source port randomization in
their resolvers to mitigate this attack.

A coordinated public release of patches that implement this change
from a number of different vendors has occurred.

Dan Kaminsky of IOActive informed vendors of potential attack that
could exploit weaknesses in the DNS protocol leading to poisoning of
caching recursive resolvers with spoofed data. Dan has released a
widget that can allow users to check to see if their DNS servers are
vulnerable (see doxpara link for widget).

It's expected that Mr. Kaminsky will publish the details of the
vulnerability at the Black Hat security conference on August 6th, and
it's expected that by this point the details of the vulnerability
will be independently discovered, potentially by malicious
individuals.

BIND: All users running BIND as a caching resolver need to take
action; ISC has released BIND 9.5.0-P1 (view ISC link below for
patch) to help boost resilience to the attack however this not a
solution. DNSSEC is the only definitive solution but ISC understands
immediate deployment is not a realistic expectation. NOTE: The patch
will have a noticeable impact on the performance of BIND caching
resolvers with query rates at or above 10,000 queries per second. If
performance at this level is critical, please refer to the beta
releases of BIND.

MICROSOFT, CISCO, & OTHERS: Multiple big vendors plan to (or already
have) released security patches for this issue. Below are links to
different vendor advisories and/or patches (Microsoft's July 2008
bulletin includes this issue as MS08-37). If a patch is not available
from effected vendors, check back with their respective advisories
for more information.

NOTE that because the fix involves use of additional UDP ports,
firewall rules may be affected.

Please be aware that some of the reference web sites are experience
high demand and may occasionally fail to respond.

See:
http://www.kb.cert.org/vuls/id/800113
http://www.cisco.com/warp/public/707/cisco-sa-20080708-dns.shtml
http://www.microsoft.com/technet/security/Bulletin/MS08-jul.mspx
http://www.isc.org/index.pl?/sw/bind/view/?release=9.5.0-P1
http://www.doxpara.com/
http://securosis.com/2008/07/08/dan-kaminsky-discovers-fundamental-issue-in-dns-massive-multivendor-patch-released/
http://securosis.com/publications/DNS-Executive-Overview.pdf
http://isc.sans.org/diary.html?storyid=4684
http://isc.sans.org/diary.html?storyid=4687

==========

Wednesday, 2008-07-09:

Regarding ability to use the Doxpara tool in an automated fashion:

Someone on NANOG came up with a perl wrapper that can be directed
at a specified DNS server.

http://mailman.nanog.org/pipermail/nanog/2008-July/001966.html

==========

Thursday, 2008-07-10:

An anon REN-ISAC member submitted:

   So if you want to know if your DNS server is vulnerable to the
   recently announced DNS issue, you can easily test this via a
   clever test point that Duane Wessels (<wessels () dns-oarc net>)
   has made available for folks...

   From a unix shell prompt, do:

   dig +short porttest.dns-oarc.net TXT

   If you see something like:

   z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
   "<deleted> is POOR: 26 queries in 0.8 seconds from 1 ports with
   std dev 0.00"

   you're vulnerable and need to upgrade or otherwise mitigate that
   vulnerability.

A good result looks something like this:

   dig +short porttest.dns-oarc.net TXT
   z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
   "<deleted> is GOOD: 26 queries in 2.3 seconds from 26 ports with
   std dev 18629.46"

Note the port diversity.

Now, I'm not convinced that when this tool reports something as GOOD,
that the server is indeed good GOOD, e.g. what if a predictable set
of multiple ports is used?  BUT OTOH, if the tool reports POOR, you
do indeed know that it's POOR, and the tool effectively reports
whether known server types are patched for UDP port randomization.

see additional:
http://lists.oarci.net/pipermail/dns-operations/2008-July/002932.html

==========


Regards,

Doug Pearson
Technical Director, REN-ISAC
http://www.ren-isac.net
24x7 Watch Desk +1(317)278-6630