DNS漏洞解析

| 6 Comments | No TrackBacks |

最近炒的比较火的一个漏洞是 DNS 协议本身发现的一个严重问题(CERT VU#800113)。国内媒体对此的报道多数都语焉不详,因此我想有必要说说这个漏洞到底是怎么回事。

首先我们要明确的第一个问题是,DNS查询是如何进行的?对于绝大多数桌面系统来说,DNS的查询并不是由自己的机器完成的,DNS查询会提交给另一台DNS服务器(这台服务器通常是由ISP或者公司提供),然后这台服务器再去进行真正的查询操作。这样做的好处是DNS的查询结果可以由这台机器给缓存下来,从而提高查询效率并降低由DNS带来的流量开销(当然,在今天这种开销已经是可以忽略不计的了)。

我们可以看到的一个情况是,一台缓存DNS服务器(与权威DNS相对,这类系统提供的)下面的桌面系统可能有几百、几千、几万甚至几十万台,从攻击的有效性而言,如果能够影响这台服务器的话,相比攻陷其下的桌面系统而言,成本便会降低很多,这种攻击我们通常称之为杠杆式攻击。

针对缓存DNS服务器的杠杆式攻击其实从很早就有研究,除了希望通过劫持网站流量来牟利的骇客之外,还有一些人使用这种方法达到一些其他的目的,例如屏蔽存在安全问题的网站,以及在一些国家存在的互联网内容净化处理等等。

本次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的工作人员修正问题,通过安装适当的补丁,能够消除以上两种弱点。对于 FreeBSD 用户,减轻这类问题影响的办法是在 /etc/rc.conf 中加入 named_enable="YES",执行 /etc/rc.d/named restart 并在 /etc/resolv.conf 中将 127.0.0.1 配置为域名服务器,这样一来攻击缓存服务器一点便变成了攻击所有的桌面系统,从而大大提高攻击的成本,但缺点是这样做意味着无法利用上游 DNS 的缓存。

如果你是缓存DNS服务器的管理员,那么除了需要打补丁之外(如果你的系统中存在这个漏洞),还需要考虑部署DNSsec。DNS协议的漏洞通过随机化查询端口和TXID只能部分缓解,而DNSsec才是解决问题的根本。

如果你是权威DNS服务器的管理员,那么事实上你做不了什么,因为缓存DNS服务器并不受你控制。唯一可以做的事情就只剩下为自己的权威域名配置DNSsec了。遗憾的是,目前并不是所有的顶级域名,以及域名注册服务提供商都支持DNSsec。

========

一些常见的误解。

误解A:靠,又是那个破烂BIND的漏洞,我不用BIND所以没事。
错。除了BIND之外,也有很多其他DNS服务器作为缓存DNS使用时会遇到同样的问题。

误解B:我的Ubuntu系统第一时间修补了这个问题,所以我不受影响。
错。除非你在本地运行DNS缓存服务,并只使用它作为DNS。

误解C:我是打酱油的,DNS被攻击跟我没关系,顶多给人家增加点流量而已,不碍事。
错。通过DNS Cache投毒攻击可以将你引导到一些伪造的钓鱼站点来骗取敏感数据。

误解D:我的权威DNS服务器配置了DNSsec,所以客户一定会访问到正确的网站。
错。事实是,许多早期的DNSsec实现都引入了其他安全漏洞;另一方面,多数缓存DNS服务器并不进行DNSsec校验,因此你仍然需要其他一些手段来减轻这个问题的影响。

全球DNS系统需要来一次DNSsec俯卧撑。

No TrackBacks

TrackBack URL: https://blog.delphij.net/mt/mt-tb.cgi/1653

6 Comments

总体分析,blog趋向罢写状态,我还指望把AdSense给您调成作弊模式....总得说来,沙发!

漏洞天天有啊。。。

正解E: 说啥都没用,opera好!

有人在抄啊:
http://security.ctocio.com.cn/securitycomment/265/8236265.shtml

赞!就喜欢这样挖掘事情本质的!

这个问题的确比较麻烦呢,
就遇到过DNS被劫持的情况……

Leave a comment

Monthly Archives

Pages

OpenID accepted here Learn more about OpenID
Powered by Movable Type 5.2.3