前言
在前一篇研究中，我们探讨了当解析服务器的域名到期后，允许我们完全接管某些目标域名(这些域名由已经过期的解析服务器解析)的问题。在那个例子中，我们通过购买一个过期的权威解析服务器的域名，接管了需要权威解析服务器来解析的“maris.int”域名(建议先看一看这篇文章，同时最好有一些DNS详细协议的相关基础，否则下面的内容不太好理解，有基础的可以直接pass)。这个先前的例子基于两个有问题的域名服务器，一个配置有问题，另一个域名已经过期。由于存在这两个问题，导致了解析服务器的域名完全无法访问到(直到我买了该域名)。从而更容易控制这个域名上承载的域名系统(如果一个解析服务器有问题，客户端会自动去查询下一个工作的解析服务器)。这也引发了一个重要的问题：由于解析服务器的域名过期、或其他可以接管的漏洞，导致一些解析服务器无法工作，那么还有没有这样的域名和解析服务器呢？实际上，有很多方法，可以找到这样的解析服务器。
一些坏的解析服务器
如果某解析服务器的域名存在漏洞，我们如果能找到这样的域名，并控制该域名，那么，对于那些经过该域名所在的解析服务器解析的域名，我们都可以很容易的进行各种攻击。为了找到这样的域名，我可能不得不返回去扫描互联网，幸运的是，因为我们已经有了一个“.int”域名区域的复本(在前一篇研究文章中，我们已经得到了)，我们可以从这开始。在遍历了这个列表后，我发现了另一个有漏洞的“.int”域名:iom.int。实际上，这个网站的功能是齐全的，并且能正常工作，只是它的四个解析服务器中，有两个解析服务器的域名是过期的。非常有趣，除非你遍历了整个DNS树，否则你可能无法发现这个问题。例如，下面是iom.int域名的NS记录查询结果：
如上图所示，我们使用了GOOGLE的8.8.8.8公共DNS解析服务器，来查询iom.int的解析服务器，返回了两个域名，分别是“ns1.zrh1.ch.colt.net”和“ns1.gva.ch.colt.net”，状态码是“NOERROR”。“colt.net”域名当前已经被注册、处在工作中、并且返回了预期的DNS记录。如果是这样的情况，那么漏洞在哪呢？实地上，因为dig的工作方式，我们有一点被误导了。让我们来看一看运行dig时加上“+trace”参数，会发生什么：
如上所示，dig的进程在遍历DNS树。首先，我们看到它向根解析服务器(13台)查询了“.int”顶级域名的解析服务器，结果就是“ns.icann.org”、“ns1.cs.ucl.ac.uk”等5个域名，下一步，dig会随机向一个刚才返回的“.int”的解析服务器查询iom.int域名的解析服务器，如上图，可以看到，返回了多个iom.int域名的解析服务器。然而，dig会继续查询委托链，直到得到一个权威应答。此外，如果“.int”顶级域名的解析服务器不是iom.int区域的权威区域，因此DNS回应数据包中权威应答标志没有被设置。只有返回的解析服务器包含特定区域时，该字段才会被设置。此时域名系统会说：“停止遍历DNS树，你要找的区域属于我这里。”在dig的处理过程中，我们看到：从“.int”顶级解析务器中随机选出了一个解析服务器，然后再向该解析服务器查询iom.int的解析服务器，并找到了iom.int区域的权威解析服务器，并返回给我们。有趣的是，如果dig遇到一些非工作的解析服务器时，比如“ns1.iom.org.ph”和“ns2.iom.org.ph”，dig在这些域名对应的解析服务器上的查询会失败，但是进程不会终止，会自动跳到下一个工作的解析服务器上，并且不会通知我们。
域名的可用性、注册的真相、粗略的DNS配置
最初，当我使用我写的一些自定义软件扫描这个漏洞时，我收到一个警告信息：iom.org.ph可以被注册，也就是说该域名还没有被使用，是无效的。但是当我使用dig来进行查询时，我发现了一些奇怪的东西：
上图的查询显示出，当我们查询iom.org.ph域名的A记录(IP记录)时，我们得到了一个有效的IP地址。那么，等一下，iom.org.ph域名真的返回了一个有效的记录吗？如果这个域名不存在(可以被注册)，那怎么还能返回一个记录呢？当我查询这个域名的解析服务器时，事件变的更奇怪了：
从上图的dig结果看到，对于该域名，尽管刚才返回了一个A记录，但是并不存在它的解析服务器(NS记录)。怎么会这样呢？尝试此查询后，我甚至对该域名的可用性没有信心。因此，为了验证我的想法，我进行了以下查询：
好了，根据上图显示，很明显了，所有不存在的“.org.ph”域名都会返回一个A记录(IP)。那么这个IP上到底有什么东西呢？下面的截图是我们访问“ThisCantPossiblyExist.org.ph”域名的结果。
上图已经清楚告诉我们发生了什么。通常，一个域名如果没有被注册，是不会被解析的，但是，“.org.ph”顶级域名存在一个A记录，它被解析了，并将该顶级域名将访问域名的用户，引导到一个充满了可疑广告的页面中，包含一个通知信息：“这个域名可以被注册”。这可能是想从访问该域名(不存在的域名)的人那里赚更多的钱。我不想评论这个策略的道德性或模糊性，只想告诉大家，如何才能用dig探测到这种情况。下面的查询显示了DNS到底是怎么配置的：
在上面的查询中，我们用了通配符来查询任何与“*.org.ph”相匹配的结果，上面的结果很好的说明了事件的原因。
另外，需要做进一步健全性检查时，域名的历史数据是一个很有用的强大工具。我知道的最大的一个DNS历史数据、WHOIS信息、和常规互联网数据收集数据库，是“Domain Tools”，在联系他们后，他们伸出手来为我提供了一个研究者帐户，而后，我用这些数据得到了有关这个漏洞的所有信息。查询了这个资料库后，我知道了iom.org.ph域名第一次出现这个漏洞(或者第一次过期)的准确时间。
有趣的是，这个历史数据显示，该域名从2013年以后可能就已经过期。并且该问题(已经过期)可能已经存在了很长时间了，这个事实表明，这种类型的漏洞是足够微妙的，以至于在这么长时间都被忽略了。
接管域名
一旦我认识到iom.org.ph域名确实可用时，我可以注册这个域名，并将这个域名变成iom.int域名的权威解析服务器。这和我们上一篇文章中maris.int域名很相似，并且有一个有趣的问题。当一个人试图访问iom.int域名时，最终通过我们的解析服务器来查询的可能性是百分之50(根据前面“dig iom.int +trace”的结果，读者可以想想为什么是50%)。出现这个结果是因为DNS的轮询调度机制，这是一种利用多个服务器来分散DNS查询负载的技术。这个概念是相当简单的，在DNS系统中，如果你想利用多个服务器来分散DNS的查询负载，对于一个查询，就可能会得到多个结果(这个结果不是最后的IP，而是中间过程中查询到了解析服务器的结果，解析服务器会有多个)。因此，为了均匀的分配负载，你得到的返回结果将会是随机的，这样的话，查询客户端第次查询都会选择一个不同的解析服务器(NS记录)。在这个例子中，当我们查询DNS的A记录时，根据这个机制，有可能在三个IP中随机的返回一个，每个IP的可能性大约是33.33%。举个例子，假设我们要尝试向“.int”顶级域名的解析服务器查询iom.int域名的NS记录(解析服务器)。首先，我们通过下面的步骤得到“.int”顶级域名和解析服务器：
然后，我们随机选出一个(下面假如随机选出了ns.uu.net域名)，并多次向它查询iom.int域名的解析服务器：
正好上面看到的，我们每次查询得到的解析服务器的顺序都不一样。这就是DNS轮询调试机制的好处，每次得到不同的解析服务器会大致均衡DNS查询的负载。然而，这个让我们的攻击变的复杂，因为用户有50%的机会能得到合法的解析服务器。因此，现在的问题是我们如何才能颠覆这个概率，并对我们有利呢？
轮询调试的概率可以对我们永远有利
目前，我们无法控制“.int”顶级域名服务器的行为，我们只有大约50%的机会。作为一个攻击者，我们需要弄清楚如何才能使这个概率接近100%。幸运的是，因为DNS的结构，我们可以做的非常接近。
当你访问www.google.com时，你的电脑会进行DNS查询得到一个IP地址，从表面上看，得到这个结果时，它好像没有遍历整个DNS树。相反，它可能会使用一个DNS解析器，并以你的名义执行此过程，并缓存所有的结果。你的电脑在DHCP过程中，会被分配一个大型的DNS解析器(如8.8.8.8或8.8.8.4 DNS服务器)，或者你的本地路由器或电脑中的一个小型的解析器。在解析器后端，会有很多正在进行DNS查询的客户端，同时可以通过缓存结果加快查询速度。因此，当一个客户端在查询www.google.com域名的地址前，如果其它客户端已经查询过，那么这个客户端就不会遍历DNS树，因为该域名的查询结果在缓存中已经有了。在DNS结构中，缓存有优先权，要意识到这一点对我们很重要。这种架构的副作用是很明显的，比如类似Dyn公司遭受DDoS攻击的事件，造成了数百万用户在互联网下线。事实证明，当你把所有的鸡蛋放在一个篮子里，你最好确定篮子可以撑的住。
在完成一次DNS查询后，解析器会暂时保存查询结果，不论回应的TTL是否设置。意味着，例如，如果一个回应包的TTL设置为120，缓存解析器分服从这个设置，并在两分钟内给查询这个域名的其它客户端返回一样的记录。这个值是有上限的，但是它的设置依赖解析器本身，也许设置成长达一个星期也没有问题。
鉴于这种情况，我们可以通过设置TTLs的时间，达到我们的目的，情况基本上归结为：
1.用户访问iom.int域名所在的网站，会首先自动查找域名的A记录。
2.根据“.int”顶级域名的解析服务器(NS记录)的查询结果，查询进程会随机选择其中的一个解析服务器，选中我们染毒解析服务器的概率是50%。
3.如果用户的查询进程没有选中我们的染毒解析服务器，选择了一个合法的，那么解析器会将这个结果缓存下来，并将TTL时间定义为21745秒(大约6小时)。这是在写这篇文章的时候记录下的实际TTL值。
4.稍后，6个小时以后，用户再次访问网站时，解析器会再次遍历DNS树，如果这一次得到的结果是我们的恶意解析服务器，那么好了，成功了，解析服务器在我们手里，我们可以随便设置域名所对应的A记录(IP地址)。通过我们的恶意解析服务器，我们可以把回应的TTL值设置成604800秒(一周),也可以设置的更长，就看你的需要了。然后解析器在缓存中会保存这个记录，直到TTL时间结束。
5.现在，在接下来的一周中，所有访问这个域名的用户，解析器的客户端都会使用这个伪造的记录。
当你意识到有很多人或服务正在使用大型解析器时，如google的公共解析器(8.8.8.8、8.8.8.4)或Dyn的(216.146.35.35、216.146.36.36),你就可以想像到事件的严重性了。我们认为，概率问题只是一个小问题，只是一个时间问题，因为时间越长，解析的次数越多时，总会有一次解析选中我们的染毒解析服务器，然后，所有的解析客户端(潜在的数以百万计的)在相当长的一段时间中(TTL)，都会返回染毒的结果。更有甚者，对于大型解析器，我们可以很容易做一个测试，当我们知道已经使缓存中毒时，我们可以迅速采取行动。
DNS的力量
到这里，我们已经可以对目标进行DNS污染了，但是它给了我们什么能力呢？我们能用新获得的特权做什么呢？
1.为iom.int发行任意SSL/TLS证书：很多证书颁发机构在域名验证时允许使用DNS、HTTP、或电子邮件,基于这个事实，我们可以很容易的在我们控制的解析服务器上设置DNS记录，以证明我们拥有目标域名。即使CA选择了目标域名的实际解析服务器，只要等到缓存过期，我们只需要再次发起请求，直到它向我们的恶意解析服务器发起查询请求。这假定证书颁发机构的证书颁发系统确实执行了缓存数据--如果它没有，我们只需要立即再次尝试，直到我们的恶意服务器被选择。
2.目标邮件拦截：因为我们可以设置目标域名(通过我们控制的恶意解析服务器来解析)的MS记录，通过设置我们的恶意解析服务器，来监视从特定目标发来的DNS查询请求，如Gmail、Yahoo Mail，或IANA的邮件服务器，并选择性的导引邮件路由路径。这种方法非常隐秘，因为除了我们关心的目标之外，我们可以给任何查询请求返回一个合法的应答。
3.接管“.int”域名本身：就“.int”顶级域名而言，如果我们想在登记处更改该域名的拥有者或解析服务器，该域名的行政联系人和技术联系人都必须认可这种变化(假设更改策略和IANA的根解析服务器的策略是相同的)，修改才会生效，具体信息可以从IANA的网站上看到。通过查询WHOIS信息，我发现，行政联系人和技术联系人的两个电子邮件地址也在iom.int上(这是字面翻译，但是联系前后文，这里的实际意思应该是电子邮件地址的解析服务器和iom.int的解析服务器是一样的)。所以我们有拦截这两个邮件的能力。现在我们只需要等待，直到从IANA的IP段发来一个DNS MX查询请求时，对MX记录结果选择性的投毒，将电子邮件引导到我们的服务器上，这将允许我们以管理者的身份发送或接收电子邮件。为了测试能否实现污染IANA的邮件服务器，我们可以使用iom.int(因为该域名也是“.int”域名)来伪造邮件，并检查这个邮件是否被重定向到我们的恶意邮件服务器上。如果我们没有收到它，我们只需要等待合法的邮件服务器的TTL缓存时间结束，然后我们再一次尝试。
4.偷取用户凭证：因为我们可以更改域名系统，为了偷取用户的各种凭证或其它数据，我们可以重写A记录，将流量重定向到我们的钓鱼服务器上。
5.利用SRV欺骗的中间人设备：因为我们可以控制SRV记录，我们可以改变这个记录，强制嵌入设备连接到我们的服务器。包括那些在路由时会使用DNS的所有设备(假设协议中没有其他验证方法)。
6.和更多其它的
很明显，这是一个已经存在的漏洞，但是这种漏洞在现实中会很多吗？对于一个随机的“.int”网站可能存在这个漏洞，但是其它任何实际的重要网站会存在这个问题吗？
不是一个孤立的事件
下面是一个网站的截图，这个网站存在的漏洞和iom.int的一样。这一次是由一个错字符引发了解析服务器的解析：
存在漏洞的域名是sen.gov，美国参议院内部的一个网址缩短服务。这个域名的权威解析服务器有一个不存在的域名--“ns1-201-akam.net”。这可能是一个拼写错误的ns1-201.akam.net域名，ns1-201.akam.net域名是一个子域名，属于Akamai，这种轻微的错误造成了大量的安全问题，而这往往是你最不想看到的。这对于攻击者来讲，有可能是一个金矿，攻击者为了对目标进行钓鱼攻击或其它攻击，可以通过基于DNS的恶意重定向实现目的。由于这个漏洞的高危性和可利用性，我自己购买了这个域名，并封锁了这个域名上的所有DNS流量(这样做的结果是：在这个解析服务器上的所有查询都会失败，查询会自动跳转到其它正常工作中的解析服务器上，研究者的目的是保护这个域名，防止被坏人利用，所有就索性自己先把这个漏洞域名管理上。实际上，是为了保护这个网络不受攻击)。这个做法基本上暂时“堵住”了这个漏洞(暂时是安全的)，直到这个网站的管理员修复它。在此之后，我联系了“.gov”的注册机构，他们将我的担忧转发给了这个网站的管理员，这个管理员很快修复了该漏洞，他们的响应速度令人印象深刻。然而，这表明，这种类型的漏洞可以发生在任何人身上。除了这里列出的这两个例子，还有许多存在的，但并没有被列出来的例子，证明这不是一个孤立的问题。
Judas DNS--一个接管解析服务器的利用工具
为了使利用这种独特漏洞的过程更容易，我已经创建了一个利用恶意权威解析服务器的POC代码，当你已经接管了一个目标解析服务器时，你可以使用它。Judas服务会将所有的DNS请求代理到配置的权威解析服务器上，Judas的配置文件很神奇，它根据源IP、或DNS查询的类型，允许你配置DNS的响应数据。这允许一个攻击者配置一个恶意解析服务器，能做很多事件，比如选择性地重新路由来自指定源IP范围的入站电子邮件(通过修改MX记录)，设置TTL时间等。
最后的想法
这个漏洞包含所有危险漏洞的特征。不仅是因为它很容易通过一个拼写错误或一个解析服务器的过期域名，导致该漏洞，而且由于DNS客户端故障转移的特点，导致并不能一眼就识别出这个漏洞。这意味着，它不仅可以发生在任何人身上，而且可能在很长一段时间内都察觉不到。
关于如何修补这个问题，非常有趣，因为在TLD(顶级域名)这一级上，就有可能会减轻这个问题。实际上，TLD的操作者仅仅对DNS的健康状况做一些检查，就可以确定所有域名的解析服务器是否处在工作中(仅需要检查一下域名，看一看是否能返回一个IP，或查看是否返回NXDOMAIN)，就可能完全阻止这种劫持攻击。然而，我怀疑这个工作对TLDs来讲可能是一个非常繁重的工作，并且很有可能出现错误。毕竟，如果TLD自动移除那些可能存在域名漏洞的解析服务器，弄不好就会出现断网事件，肯定会掉入赔偿的地狱。因此，如何大规模修补这个漏洞仍然是一个有趣的问题。
参考链接
什么是解析服务器：
http://www.inmotionhosting.com/support/domain-names/dns-nameserver-changes/what-is-a-name-server
A记录与NS记录——DNS资源类型：
http://blog.chinaunix.net/uid-26404477-id-3432550.html
权威解析服务器：
http://www.cnblogs.com/Mr-Cheng/p/4366095.html
如何查看域名的NS记录：
http://www.dns0755.net/news/74.html
域名NS记录是什么：
http://www.51edu.com/it/wzjs/81389.html
DNS原理及解析过程：
http://www.cnblogs.com/vincently/p/4670597.html
https://msdn.microsoft.com/ZH-CN/library/dd197427
DNS基本操作详解：
http://www.cnblogs.com/cobbliu/archive/2013/03/24/2979521.html
本文由 安全客 翻译，作者：pwn_361