DNS漏洞:很幸运地避开了第一颗子弹

      如果域名系统不能被信任的话，互联网将成为一个可怕的地方。是什么导致这样的情况出现了呢，专家们又在采取什么方法解决这个问题。在下面，我将就相关的情况进行说明。

　　在最近的一篇文章“域名系统：痛苦的回忆是多么重要”，我曾经提到丹·卡明斯基(网络安全产品和服务提供商IOActive和Doxpara的测试总监)发现的这个问题。在前段时间举行的黑帽2008年会上，卡明斯基终于披露了发现的缺陷的细节。这个设计上的缺陷，导致域名服务器很容易受到缓存攻击的威胁。为了真正了解这个缺陷的严重程度，我们需要从域名系统的查询原理开始了解。

　　域名系统(DNS)

　　人类很容易记住由FQDN等字母组成的名字，而象计算机一类的数字机器则使用数字(网络地址)进行存储。域名系统就象两者之间进行交流的桥梁一样，让我们在网络浏览器中输入网络地址或者电子邮件地址而不是一个隐藏的数字。举例来说，如果要访问security.zdnet.com.cn网站的时间，可以利用我的网络浏览器进行下列操作步骤以达到目的：

　　1. 在网络浏览器中输入security.zdnet.com.cn。

　　2. 网络浏览器要求解析器(将FQDN之类的字母信息转换为数字网络地址的域名系统后台客户端应用)将security.zdnet.com.cn转换为一个网络地址(数字形式)。

　　3. 解析器会首先检查系统的主机文件和本地缓存，看看是否有存在可用的字母信息转换为数字网络地址的组合。如果存在的话，解析器将通过网络地址进行连接。如果没有的话，解析器将连接我的互联网服务提供商的域名服务器，要求它提供security.zdnet.com.cn的网络地址。

　　4. 如果互联网服务提供商的域名服务器在缓存中找到相关数据的话，它会立即再建立一个连接，将网络地址返回给解析器。关于域名服务器，我们需要明白的关键一点是。它只是一台域名服务器，需要其它服务器提供官方的信息。

　　5. 如果没有找到的话，我的互联网服务提供商的域名服务器将连接官方的域名服务器查询techrepublic.com的网络地址。在这里解释一下，由字母组成的security.zdnet.com.cn有三个部分。在官方域名服务器进行查询的时间，首先是Com，接着是zdnet，最后是security。

　　6. 首先，我的互联网服务提供商的域名服务器将查询根域名服务器(官方的.com、 .net等)。根域名服务器将向我的互联网服务提供商的域名服务器返回.com域名服务器的信息。

　　7. 接下来，我的互联网服务提供商的域名服务器将查询.com域名服务器(.com域名的官方域名服务器)中techrepublic.com的网络地址。.com域名服务器就可以将实际的网络地址发送给我的互联网服务提供商的域名服务器。

　　8. 现在我的互联网服务提供商的域名服务器就可以查询zdnet.com.cn域名服务器上security.zdnet.com.cn的网络地址了。最后，我的互联网服务提供商的域名服务器将找到的网络地址发给我的计算机上的解析器，就可以建立连接了。

　　9. 一旦连接建立，网络服务器就会将指定的网页发送到我的计算机上，并显示在网络浏览器中。

　　为了获得网站的网络地址看起来好象要耗费大量反复的工作。但值得庆幸的是，由于域名系统协议包含了多项功能，所以这些工作只需要几毫秒就可以完成。我想对这些功能进行一下快速概要的说明，因为它们和讨论的域名系统缺陷有很重要的关系。

　　缓存

　　为了减少查询的次数，域名系统使用了缓存。举例来说，我的互联网服务提供商的域名服务器可能已经有最近和.com域名服务器查询的结果。这样的话，我的互联网服务提供商的域名服务器就可以将这些信息保存在专门分割出来的一块缓存区域中。如果一个网站受到欢迎经常被访问，对于我的互联网服务提供商的域名服务器来说，比较好的办法是将网站的网络地址保存在缓存中。

　　生存期(TTL)

　　如果TechRepublic网站的技术部门决定改变security.zdnet.com.cn网站的网络地址。在这种情况下，如何保证世界各地的域名服务器尽快得到security.zdnet.com.cn的新网络地址?这个时间，缓存中的一个叫做生存期(TTL)的部分就起作用了。生存期可以控制服务器更新缓存中的转换表的时间。这样可以保证新的信息被及时加入，以保证域名系统信息的准确性。

　　“越权”

　　“越权”是指不涉及到原始域名系统查询的其它信息。举例来说，一个互联网服务提供商的域名服务器要求提供security.zdnet.com.cn的信息，结果返回的是net.zdnet.com.cn的信息。这个信息就是越权。信息越权在早期版本的域名系统中出现过，但现在已经不是问题了。在这里提到是因为它涉及到卡明斯基域名系统错误的讨论。

　　现在我们对域名系统查询原理有了认识，也了解了相关的内容，不清楚的地方已经给予了解释。下面，我们就来了解一下域名系统的简单历史。

　　原始的域名系统协议

　　域名系统是以一个包含完全信任的应用形式诞生的。但随着互联网的成熟，利用域名系统的信任，将用户重定向到没有要求的网站的行为变得越来越普遍。刚开始，它没有什么害处，但后来的攻击者意识到，他们可以利用“域名系统缓存攻击”将用户重定向到冒牌网站以便窃取个人信息。

　　在原始的域名系统协议中，域名系统的查询包包含了一个十六位的数字(1-65535之间)，它被传之为传输ID(TID)，实际上是一个线性递增计数器。传输ID的目的是验证域名系统查询响应的情况，域名服务器必须返回相同的TID。

　　因此，如果攻击者知道受害人域名服务器使用的最新查询的传输ID数字，就可以发出恶意的域名系统查询响应传输ID。这样的话，查询响应将会递增。通过猜测，就可以完成攻击。了解这一点也很重要，掌握缓存攻击模式的攻击者可以耐心等待，直到受害人域名服务器发出生存期的指令，就可以开始工作了。

　　缓存攻击的唯一原因，是因为域名系统采用了用户数据报协议(UDP)，该协议在Wikipedia百科中是这样定义的：

　　“用户数据报协议是一个简单的面向数据报的传输层协议，它把数据分开分别发送而不验证对方是否收到。它只提供数据的不可靠传递，一旦把应用程序发给网络层的数据发送出去，就不保留数据备份。”

　　作为一种无连接的协议，用户数据报协议传输的时间不使用验证。因此，它可能利用伪造的网络地址和端口来发送欺骗性的查询响应。

　　域名系统的下一代

　　为了提高域名系统的安全性，新协议中增加了一个利用传输ID创建伪随机数发生器的部分。这样可以显著提高域名系统的安全性，迫使攻击者在65535个数字中进行猜测，而不是象原来那样，只要对增加的数字进行预测。现在：攻击者要成功地进行缓存攻击的话，需要解决两方面的问题：传输ID(非常困难)和网络地址/端口组合(不太困难) 。

　　十六位随机数仍不安全

　　包括丹·伯恩斯坦在内的几个域名系统方面的著名专家，曾经指出，相比今天处理器的能力，十六位随机数提供的传输ID不是足够安全的。作为一个参考，伯恩斯坦开发了自己的域名系统应用来对查询端口进行随机化(网络传输需要网络地址和端口)。

　　到目前为止，域名系统需要一个静态端口。通常情况下，53端口为查询端口，这就意味着，攻击者只要去猜测传输ID就可以了。由于65535个端口都可以应用，伯恩斯坦将随机查询端口增加一个十六位的平均有效值，这样难度的猜测将增加65535倍。

　　听起来很不错!但因为过于复杂，所以大部分的域名系统都没有使用随机查询端口。其中也包含了防火墙和NAT路由器等方面的原因，它们会让随机端口出问题。BIND、思科、微软的域名系统应用都是一些例子，它们最近才开始实施随机查询端口。

　　卡明斯基的错误

　　你还记得攻击者如何在生存期失效之前，才能尝试进行攻击的么?卡明斯基正在考虑怎么绕过这一点。如何进行说明的最好的办法就是来策划一次攻击。让我们来看，如果要对我的互联网服务提供商的域名服务器上security.zdnet.com.cn网站的信息进行攻击，应该怎么进行操作：

　　1. 我可以从官方的域名服务器上获得security.zdnet.com.cn网站的网络地址。同样，我也可以获得我的互联网服务提供商的域名服务器的网络地址以及使用的域名系统查询端口。

　　2. 下面我就可以发送一个查询包，查询一台在security.zdnet.com.cn网站中不存在的机器，就叫它11.security.zdnet.com.cn。

　　3. 由于没有这台系统的信息，所以我的互联网服务提供商的域名服务器必须发送一个域名查询信息到security.zdnet.com.cn的域名服务器上。

　　4. 现在，我就可以从这批域名查询包中获得下面的信息：

　　·欺骗性的源网络地址(它看起来似乎象来自security.zdnet.com.cn网站 )

　　·正确的查询端口(我的互联网服务提供商的域名服务器在进行域名查询的时间使用的)

　　·传输ID(随机选择，足够的查询响应就可以找出)

　　·我选择的域名服务器的网络地址(请注意，这个是权限之内可以接受的)

　　现在，等待生存期失效就不再是必要的了。在我的例子中，我控制互联网服务提供商的域名服务器发出查询。如果11.security.zdnet.com.cn的查询没有起作用，所有要做的就是利用相同的方法尝试12.security.zdnet.com.cn，直到收到回复。因为可以获得我的互联网服务提供商提供的11或12.security.zdnet.com.cn的域名系统信息，我知道这种情况一定会发生。

　　在这里有几个观点可以让你对缓存攻击的认识更深刻，它们是：

　　·因为域名系统的查询回应是“有权”，所以我的互联网服务提供商的域名服务器认为我给它的网络地址在整个security.zdnet.com.cn域里。

　　·我还可以将转换表的生存期设置为一个极其巨大的三十二位数字。这样，虚假的域名系统信息不会过期。

　　·现在，我就可以建立钓鱼式攻击网站而不会引发任何警报系统或网络钓鱼式攻击过滤器。

　　·这种设计的缺陷是存在于每个递归域名服务器。

　　DNS缓存攻击的对策

　　你还记得丹·伯恩斯坦和他采用随机查询端口的构思?现在这个补丁已经使用了。它增加了大量的随机性，让攻击变得不再可行。问题的关键在于，需要所有的互联网服务供应商和公司的递归域名服务器安装这个补丁。如果你希望知道自己的互联网服务提供商的域名服务器是否安装了补丁，有两个网站可以作到。卡明斯基在自己的网站“doxpara.com”上提供了一个测试的应用，还有一个是我特别喜欢的“DNS-ORAC.net”。

　　如果你发现自己的互联网服务提供商的域名服务器没有使用随机查询端口，我建议你要求互联网服务提供商升级域名服务器。然后，切换到象OpenDNS之类的安全的域名系统服务上，直到互联网服务提供商的域名服务器完成升级。此外，了解安全套接层协议层连接的网站不会被这样攻击也是非常重要的。因此，为了确保安全，请确认证书是正确的并且来自安全超文本传输协议的地址。

　　最后的思考

　　如果你看到这里，我将真诚地感谢，毕竟这篇文章很长。我只是根据自己的认识对域名系统查询和攻击的重点进行了解释。试想，如果不知道你访问的网站并不是自己要求的，这将是多么恐怖的事情。我认为安全套接层协议层连接是最重要的，但是其中的一些也需要实际登入才能保证安全。在网站欺骗发生之前，事情不会变得更坏。

　　在这里，我将感谢丹·卡明斯基。我认为他相当的负责任。如果采用其它的方法可能严重影响我们互联网的体验。我同样希望感谢所有已经安装了修补程序的互联网服务供应商，毕竟它不是一个微不足道的问题。

　　最后一点：我给出了“微软Patch MS08-037”的连接，使用Windows 2000和2003操作系统的服务器可以用来它修复域名系统的错误。我怀疑许多组织内部的域名系统服务器，可能被作为递归域名系统服务器。

未经允许不得转载：DOIT » DNS漏洞:很幸运地避开了第一颗子弹