DNS漏洞解析CERT VU#800113释疑

最近炒的比较火的一个漏洞是
[url=javascript:;]DNS[/url]
协议本身发现的一个严重问题（
[url=javascript:;]CERT[/url]
VU#800113）。国内媒体对此的报道多数都语焉不详，因此我想有必要说说这个漏洞到底是怎么回事。
首先我们要明确的第一个问题是，DNS查询是如何进行的？对于绝大多数桌面系统来说，DNS的查询并不是由自己的机器完成的，DNS查询会提交给另一台DNS服务器（这台
[url=javascript:;]服务器[/url]
通常是由ISP或者公司提供），然后这台服务器再去进行真正的查询操作。这样做的好处是DNS的查询结果可以由这台机器给缓存下来，从而提高查询效率并降低由DNS带来的流量开销（当然，在今天这种开销已经是可以忽略不计的了）。
我们可以看到的一个情况是，一台缓存DNS服务器（与权威DNS相对，这类系统提供的）下面的桌面系统可能有几百、几千、几万甚至几十万台，从攻击的有效性而言，如果能够影响这台服务器的话，相比攻陷其下的桌面系统而言，成本便会降低很多，这种攻击我们通常称之为杠杆式攻击。
针对缓存DNS服务器的杠杆式攻击其实从很早就有研究，除了希望通过劫持网站流量来牟利的骇客之外，还有一些人使用这种方法达到一些其他的目的，例如屏蔽存在
[url=javascript:;]安全[/url]
问题的网站，以及在一些国家存在的互联网内容净化处理等等。
本次VU# 800113是一个足以引起人们重视的问题，尽管它采用的仍然是"Cache 投毒"（cache poisoning）的方法，但这种方法采用了一些新的技巧来使其更加有效。具体来说，DNS的查询过程是由客户端（无论是桌面计算机，或是缓存DNS服务器发起的查询）发出一个到权威DNS服务器（可能是根DNS，也可能是具体域名的权威DNS）一个UDP请求，然后等待其回应。
UDP是一种无连接的协议，为了能够识别来自不同服务器的回应，DNS协议利用端口和一个称为TXID的识别符（类似TCP的序号）来区分它们。事实上，早期的DNS协议实现甚至会使用固定的端口来发起DNS请求，这样一来，TXID就成了识别回应的唯一标识。由于DNS协议是在上世纪70年代设计的，因此TXID序号只有16个bit宽，而另一方面，伪造UDP包的来源地址又很容易（因为UDP并没有提供类似TCP那样内建的防止此类攻击的机制），因此，攻击者只需设法让DNS缓存服务器相信自己伪造的来自权威DNS的回应是真实的，就可以达到目的了。
具体地说这种攻击包括两个部分，其一是设法让缓存DNS服务器发起新的DNS查询请求（有很多方法），其二则是发出大量的伪造包并期待其命中，也就是在真实的权威DNS回应之前，将伪造的，但端口和TXID均能匹配的UDP回应发到缓存DNS服务器。
对于一些以线性递增方式来产生TXID的DNS客户端而言，攻击者可以自行架设一台DNS服务器、诱使对方发出DNS请求，从而大大提高攻击的效率。对于采用固定端口的DNS客户端来说，攻击者可以通过类似的手段来获取他关心的信息。攻击者可以用各种方式来达到这种目的，包括钓鱼邮件，也包括直接发起查询等等。
本次VU ＃800113所描述的问题是，多数DNS缓存服务器实现都存在这两种弱点之一或全部。
说完攻击的原理，我想更多的人关心的问题会是：我们能够做点什么？
如果你是一名桌面用户，那么最好的办法是等待公司或ISP的工作人员修正问题，通过
[url=javascript:;]安装[/url]
适当的补丁，能够消除以上两种弱点。对于
[url=javascript:;]FreeBSD

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有