| Author | Messages | |
sbradcpa
Posts:320
 | | 07/18/2008 8:07 AM |
| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<div class="headline"><a href="diary.html?storyid=4687">Multiple
Vendors DNS Spoofing Vulnerability</a> </div>
<div class="diaryheader">Published: 2008-07-08,
Last Updated: 2008-07-08 23:09:39 UTC
by Johannes Ullrich (Version: 4) </div>
<a href="diary.html?storyid=4687#comment">0 comment(s)</a>
<script type="text/javascript">
digg_url = '<a class="moz-txt-link-freetext" href="http://isc.sans.org/diary.html?storyid=4687&rss">http://isc.sans.org/diary.html?storyid=4687&rss</a>';
digg_title = 'Multiple Vendors DNS Spoofing Vulnerability';
digg_skin='compact';
digg_topic = 'security';
</script>
<script src="http://digg.com/tools/diggthis.js" type="text/javascript"></script>
<iframe
src="http://digg.com/tools/diggthis.php?u=http%3A//isc.sans.org/diary.html%3Fstoryid%3D4687%26rss&t=Multiple%20Vendors%20DNS%20Spoofing%20Vulnerability&c=security&s=compact"
frameborder="0" height="18" scrolling="no" width="120"></iframe>
<div class="diarybody">
<p>Today, Microsoft was just one vendor releasing a patch for its DNS
server. The Internet Systems Consortium (<a class="moz-txt-link-abbreviated" href="http://www.isc.org">www.isc.org</a> published a very
similar patch for its own DNS server, BIND.</p>
<p>Many other DNS servers are derived either form BIND or Microsoft's
DNS server. Expect more similar announcements over the next couple days.</p>
<h3>The Problem</h3>
<p>The root cause is a fundamental, well known, weakness in the DNS
protocol. DNS uses UDP, a stateless protocol. A DNS server will send a
request in a single UDP packet, then wait for a response to come back.
In order to match request and response, a number of parameters are
checked:</p>
<ul>
<li>who sent the response? Was it the DNS server we sent the request
to? </li>
<li>for this particular response, do we have an outstanding request? </li>
<li>each request uses a unique and random query ID. The response has
to use the same query ID. </li>
<li>The response has to be sent to the same port from which the
request was sent. </li>
</ul>
<p>Only if all this matches, the response is accepted. The first valid
response wins. If an attacker is able to guess the query id and the
source port, the attacker is able to send a fake response, which will
be cached by the DNS server.</p>
<p>How likely is it to "guess" the query id and the source port? One
would think, its not that easy. The query ID is 16 bits long, allowing
for 65536 options. The source port could be anything above 1024 which
again would allow for another 64512 options. It is easy to guess which
DNS server is expected to reply, as it has to be a valid DNS server for
the respective domain. A reasonable DNS server should respond in less
then a second, allowing for about 1 second to send the spoofed response.</p>
<p>At least for BIND, the source port only changes whenever you restart
it. Once restarted it keeps using the same source port.</p>
<p>Ideally, one would think that it would take millions of packets per
second to successfully spoof the response. However, the problem is in
the details. A DNS server can not use any port to source the query. It
may not use a port commonly used by outbound connections, or a port
reserved by a server. This is an issue attacked by today's patches. As
of today, DNS servers used a rather small set of ports to source
requests. This is the actual new finding. The patch will increase the
pool of source ports available to DNS queries. To make things worse:
the real DNS server may be silenced using DDoS attacks.</p>
<p>Over the past few months, we had a couple patches (again both for
Microsoft as well as for BIND) addressing the randomness of the query
ID.</p>
<h3>How bad is it?</h3>
<p>If you run a caching DNS server, patch it soon. I wouldn't say
"today, while ignoring sane patch management". But check with your
vendor and follow their guidance. The world is not going to end today.
It will in fact end in 2 1/2 years from today (different story ;-) ).
But this is something you have to fix soon. Right now, the US-CERT
advisory lists a handful of vulnerable products and quite a few
"unknowns".</p>
<p>Eventually we all may have to break down and fix DNS. DNSSEC is an
extension to DNS asking for cryptographic authentication. However, it
requires a PKI infrastructure which at this point doesn't exist. There
is not much to be gained from implementing DNSSEC on your own (but by
all means: try it out and see how it works).</p>
<p>One thing to carefully test is your firewall. We already heard about
issues with Zonealarm and MS08-038. However, it is possible that other
firewalls will think that something is wrong if your DNS server all for
sudden keeps jumping ports.</p>
<h3>Where can I find out more?</h3>
<p>CERT: <a href="http://www.kb.cert.org/vuls/id/800113">www.kb.cert.org/vuls/id/800113</a>
Microsoft: <a
href="http://www.microsoft.com/technet/security/Bulletin/MS08-037.mspx">http://www.microsoft.com/technet/security/Bulletin/MS08-037.mspx</a>
Internet Software Consortium (BIND): <a
href="http://www.isc.org/sw/bind/bind-security.php">http://www.isc.org/sw/bind/bind-security.php</a>
Dan Kaminski on Martin McKeay's Podcast: <a
href="http://media.libsyn.com/media/mckeay/nsp-070808-ep111.mp3">http://media.libsyn.com/media/mckeay/nsp-070808-ep111.mp3</a></p>
<h3><strong>DNSSEC resources:</strong></h3>
<p>DNSSEC Overview: <a href="http://www.dnssec.org">http://www.dnssec.org</a>
DNSSEC Deployment Initiative: <a
href="http://www.dnssec-deployment.org">http://www.dnssec-deployment.org</a>
DNSSEC HowTo: <a href="http://www.nlnetlabs.nl/dnssec_howto">http://www.nlnetlabs.nl/dnssec_howto</a> </p>
<p>-----</p>
<p>UPDATE:</p>
<p> The CERT announcement implies strong randomization of the source
port and transaction id makes the attack improbable.
"Because attacks against these vulnerabilities all rely on an
attacker's ability to predictably spoof traffic, the implementation of
per-query source port randomization in the server presents a practical
mitigation"</p>
<p>isc.org warns busy DNS resovlers could be impacted by their patch so
they recommend the beta release version.</p>
<p>"The patches will have a noticeable impact on the performance of
BIND caching resolvers with query rates at or above 10,000 queries per
second. The beta releases include optimized code that will reduce the
impact in performance to non-significant levels."</p>
<p>Johannes B. Ullrich, Ph.D.
SANS Technology Institute - <a href="http://www.sans.edu">http://www.sans.edu</a></p>
</div>
</body>
</html>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
| | | |
|
|