DNS漏洞危机:补丁并没有完全解决问题

ZDNet安全频道原创翻译 转载请以文字链形式注明出处

作者：迈克尔·卡思勒

域名系统依旧处于危险的状态；对于域名系统服务器来说，进行全面修补以防止缓存攻击是必须的。为了引起大家的重视，我将介绍一些攻击方式和相关补丁的情况。
--------------------------------------------------------------------------------------------

在早先的文章“域名系统：幸运地避开了一颗子弹”中，我曾经描述了在域名系统协议中存在的非常严重的一个设计缺陷。这个漏洞很简单，可以容许攻击者在短短几分钟的时间内控制域名系统服务器。之后，攻击者就可以重定向不知情的互联网用户到恶意网站，以便收集个人信息或隐蔽下载恶意软件到系统中。

幸运的是，域名系统开发者迅速发布了相关的补丁，并安装到包括思科、BIND和微软在内的所有主要域名系统上。该补丁增加了对欺骗性查询的防范，并将端口设定为随机，这样攻击域名系统缓存的难度就增加了65535倍。

新的攻击方式

不过，看上去似乎这并不足够，一名来自俄罗斯的物理学家叶夫根·玻利雅可夫博士发现可以通过不正确的网络IP地址查询来欺骗完全修补过的BIND域名服务器。玻利雅可夫博士发表了“对最新的完全随机端口BIND服务器的成功攻击”一文，对详细的攻击过程进行了介绍。主要内容如下：

“BIND充分利用了大约六万四千个端口。如果采用通过一吉比特以太网连接的两台服务器进行攻击的话，每台利用全部范围进行猜测。只要经过四万到五万次的查询就可以返回正确的端口。这样话，攻击的成功率可以达到百分之六十以上。

攻击耗时大概少于十小时，也就是不到半天的时间。因此，如果拥有吉比特以太网连接的局域网的话，任何被植入木马程式的机器都可以在一夜之内成功攻击域名系统。”

相比不到一分钟就可以成功攻击一个没有安装补丁的域名服务器，十小时已经是一个巨大的改善。一些安全专家认为补丁是足够了。另一些认为博玻利雅可夫士的测试是不现实的。拥有一吉比特以太网连接的两台服务器不是典型的网络连接方式，也不可能即时进行大部分的攻击。

玻利雅可夫博士的答复令人信服。他指出，可以通过使用木马以获得必要的带宽，为了避开检测，还可以选择在晚间或周末进行。还有一种可能是利用僵尸网络的综合带宽，这样也足够进行攻击。

我认为即使玻利雅可夫博士的概念证明型测试可能是不切合实际的，但一个域名服务器可能被成功攻击这种可能也是事实，这样的后果是非常令人不安的。正如我多次说国的，即使有丝毫的机会成功攻击域名服务器，造成的后果也是不堪设想的。我感觉，大部分域名系统的专家也是同意这一点的，因为从新的补丁来看，加强保护以防止缓存攻击几乎是不可能的。

如果补丁无效的话

如果你看过玻利雅可夫博士文章的回复，会发现很多可能的解决方案，其中的一些非常有趣，因为他们从域名系统协议有可能发生变化的方面给出了解决方法。我想先从补丁不工作的状态开始说明：

Debouncing命令可以用来对域名服务器进行两次相同的查询。这样可以用来检测服务器的有效性。如果两次返回的信息是不匹配的，说明域名服务器可能已经被攻击了。在这一点上，其它的进程命令可以用来进行辅助工作。

利用传输控制协议/网间协议（TCP/IP）和三次握手，可以轻松地清除缓存攻击。握手需要对连接进行验证，不象域名系统使用的用户数据报协议（UDP）会接受任何质疑的回应，它只接受具有正确的网络IP地址和端口返回的数据包。

表面上，两种解决方案听起来都不错，也不难操作。但真这样操作的话，会有什么后果发生呢？丹·卡明斯基和其他域名系统研究人员给出了答案：

“Debouncing类似‘通过传输控制协议（TCP）运行所有域名系统数据’的方式，看上去似乎很好，但最后你会发现域名系统将崩溃。因为所有的域名系统的备份都是有限的。所有的系统都不可能支持在一个月内数据增加百分之百。”

他接着解释说，现在全球范围的域名系统网络（用户数据报协议只需要两个包进行查询和响应）已经使用了百分之五十以上的可用带宽。debounce的方法（数据包数目增加一倍）将导致网络立即饱和，结果就是让整个网络停顿下来。如果debounce的方法有影响，那有没有可能利用传输控制协议呢？答案是否定的，它需要多达七个包来进行查询和响应。这些解决方案将会对网络带来拥堵，特别是在目前用户数量继续增长的情况下。

如果补丁有效的话

域名系统安全扩展（DNSSEC）是互联网工程任务组（IETF）提出的一系列标准，可以添加到原来的域名系统协议中以增加安全性。域名系统安全扩展使用以公共密钥为基础，可以支持数字证书在查询时间的应用。域名服务器可以检查数字签名的有效性，以确定是否响应。

域名系统安全扩展还包括了其它几个方面安全性的增强，可以让域名系统变得更安全。你可能会很惊讶地得知，域名系统安全扩展已经出现了近十年了，因此，可能会质问为什么没有实施？答案其实很简单，人是存在惰性的。域名系统安全扩展非常复杂，在全球进行部署也需要耗费大量的时间。大多数域名系统方面的专家都认为，域名系统安全扩展或者修订版本最终将投入使用。但对于迫在眉睫的缓存攻击威胁来说，域名系统安全扩展测试和部署的速度是不足够的。

0×20的建议

我分析了一下来自丹·卡明斯基和史蒂夫·吉布森的0×20的建议（非常耐人寻味的想法）。他们都提到了0×20的建议会大大增加域名系统查询和响应的压力。如果你还记得的话，域名系统最近的变化就是增加有效负载以及对查询和响应进行随机端口连接。这样可以更有效地防范攻击。

0×20的建议对“在域名系统标签中使用0×20位以改善传输质量”的草案存在价值。丹·卡明斯基是这样解释存在的可能性的：

“基本上，这个来自戴维·达贡和保罗·维谢（我认为）的想法提醒的是，域名系统是不区分大小写（大写小写是一样的）但这样（作为一个请求回应包含相同的上限）。因此，我们可以在这个基础上，只回复来自wWw.DOXpaRA.cOM的请求，而忽略来自包括www.DOXPARA.com、WWW.doxpara.COM在内的类似的请求。”

这就意味着域名系统查询中的三个组成部分存在了随机性：传输ID（十六位）、端口（十六位） ，以及全域名（主机名加上全路径，全路径中列出了序列中所有域成员：FQDN ） 。使用全域名作为补充的话，由于随机性完全是依赖于名称的长度，因此，平均信息量是独一无二的。这样的话，较长的域名将会有更多的平均信息量。举例来说，使用www和.com的全域名将新增六位的平均信息量，其中三位来自www，三位来自.com。

0×20的建议最有吸引力的部分是，它不需要对核心域名服务器做任何改变。核心域名服务器已经包含了全域名的信息，只要在收到查询请求的时间直接返回全域名就可以了。只有（已经修复过一次）的递归名称服务器将必须更新，以增加对发送和收到的全域名信息的检验。除了一个简单的修正， 0×20的建议，不会占用任何额外的带宽，它只是一个有效的补丁。

最后的思考

我将继续研究域名系统和基本流程，域名系统协议的薄弱性将越来越明显，对于依赖网络进行工作的人们来说，这是令人震惊的。最后，域名系统的专家们似乎找到了一个利用域名系统安全扩展来确保域名系统协议正常工作的办法。但我对0×20的建议能否在象玻利雅可夫博士成功地攻击经过修补的BIND域名服务器这种事件发生前就有效地保护域名系统的安全持悲观态度。