最近炒的比较火的一个漏洞是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俯卧撑。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
相关推荐
-
Badlock漏洞影响Samba、Windows 引争议
被称为Badlock的新漏洞引发专家漏洞披露的争论。对Windows和Samba中这个关键安全漏洞的修复今日才发布,而有关该漏洞的新闻三周前就被公布了……
-
Conficker蠕虫再闹英国牛津大学网络,早打补丁早安全
conficker这个蠕虫大量使用P2P技术进行传播,我相信这也是地球上的网络管理人员和安全人员比较关注这个蠕虫的原因。最近这只蠕虫又在蠢蠢欲动了。
-
谈谈系统重装后如何预防病毒二次侵袭
很多人认为,只要重新安装了操作系统,就可以彻底清除病毒。但却不知道在操作系统进行重新安装后,由于安全设置以及补丁未及时安装等问题,最容易导致病毒的入侵,因此……
-
如何修补Kaminsky提出的DNS漏洞
2008年的Black Hat大会上,安全研究员Dan Kaminsky揭示了DNS中”新”漏洞的详细信息。那么,Dan的攻击是怎么起作用的呢?又应该如和修复呢?