查找漏洞的一个有用的工具（即使是你甚至都不知道已经存在的一些漏洞）是扫描常见的DNS错误和配置错误，并检查你发现的异常情况。可以使用一个非常有用的工具——ZoneMaster，它是一个通用的DNS配置扫描工具，它具有扫大量的名称服务器/ DNS配置错误的测试功能。我通过简单地脚本编写了公共域名后缀列表中列出的所有域名后缀，让ZoneMaster扫描来做处理。在分析扫描结果时，我发现了一些非常有趣的事情。之前的一篇博客文章（危地马拉的.gt 的TLD域名）中列出了其中的一个发现，另一个发现在下面进行描述。
发现漏洞中的漏洞
在使用ZoneMaster工具进行脚本自动扫描公共域名后缀列表中的所有TLD /域名后缀后，我发现一个特别有趣的结果。当分析结果时，我发现.co.ao域名后缀名的一个名称服务器在请求.co.ao区域的名称服务器时提供了DNS REFUSED错误代码：
用dig可以快速验证并确认这个事实：
$ dig NS co.ao @ns01.backupdns.com. ; <<>> DiG 9.8.3-P1 <<>> NS co.ao @ns01.backupdns.com. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 21693 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;co.ao. IN NS ;; Query time: 89 msec ;; SERVER: 199.242.242.199#53(199.242.242.199) ;; WHEN: Thu Feb 9 21:57:35 2017 ;; MSG SIZE rcvd: 23
有问题的名称服务器ns01.backupdns.com似乎由一个称为备份DNS的第三方DNS主机服务运行：
经过对本网站的一些检查，它似乎是一个相当老旧的DNS托管服务，重点是托管了备用DNS服务器，以防万一在主名称服务器发生故障时使用。最令我兴趣的是DNS错误代码REFUSED，当名称服务器根本没有为指定的域（在这种情况下是.co.ao域）留下存储区域时，则通常会响应这个错误。这是危险的一个问题，因为托管的DNS提供商通常会允许任何帐户设置DNS区域，而无需对域名所有权进行验证，这意味着任何人都可以为.co.ao创建一个帐户和一个区域来潜在地为全新的记录提供服务。
非常有兴趣能看看这种想法是否成为可能，我在网站上创建了一个帐户，并转到他们的文档页面：
给定站点名称的设置说明是非常有道理的。为了创建.co.ao的区域，我必须先通过域管理面板将该区域添加到我的帐户：
这一步的操作没有任何验证但现在还没有区域数据被加载到特定的区域。接下来的步骤是在远程主机上设置BIND服务器，并将其配置为.co.ao区域的权威名称服务器。另外，服务器必须配置为允许从BackupDNS名称服务器进行域传送，以便可以复制区域数据。以下图表显示了这一过程：
我们从我们的主DNS服务器（在这种情况下是在AWS中设置的BIND服务器）和目标BackupDNS名称服务器开始，我们希望我们的区域能够被复制。
在一段时间间隔后，BackupDNS名称服务器将发出区域传输请求（AXFR DNS查询）。这相当于名称服务器在问“ 我可以复制一份你所拥有的.co.ao域名的所有DNS数据吗？“。
由于我们配置了我们的主名称服务器，以允许通过BIND 中的allow-transfer配置从BackupDNS名称服务器进行区域传输，因此请求被授予并且区域数据也被复制了。现在我们在BackupDNS服务中创建了正确的.co.ao区域！
OK，到这我想暂停一下，同时我要指出，在这一点上，我真的没有想到会奏效。这不是我第一次用各种名称服务器测试这样的问题，以前的尝试都以失败告终了。也就是说，我复制的区域是有记录的，TTL为1秒，SOA记录只有60秒。这意味着记录将被快速扔进高速缓存，并且DNS请求将很快重新映射到另一个名称服务器，因为该域名服务器的后缀是合法的。如果你要进行任何此类测试，我强烈建议你执行和我相同的操作，以最大限度地减少对尝试正确访问目标的那些人的DNS响应缓存。
接下来，BackupDNS域名服务器会立即开始处理.co.ao 的DNS流量。当我看到服务确认执行后，我执行了dig命令以便可以快速查询确认：
$ dig NS google.co.ao @ns01.backupdns.com ; <<>> DiG 9.8.3-P1 <<>> NS google.com.ao @ns01.backupdns.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37564 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;google.co.ao. IN NS ;; AUTHORITY SECTION: co.ao. 60 IN SOA root.co.ao. root.co.ao. 147297980 900 900 1800 60 ;; Query time: 81 msec ;; SERVER: 199.242.242.199#53(199.242.242.199) ;; WHEN: Sun Feb 12 23:13:50 2017 ;; MSG SIZE rcvd: 83
呃哦，这看起来还有点问题。 我最初在BIND区域文件中放置了一些NS记录，目的是想将DNS查询委托给合法的名称服务器，但是我搞砸了BIND配置，没有正确返回DNS引用，服务器响应了NXDOMAIN的权威应答。这显然不是个很大的问题，所以我快速从BackupDNS服务中删除该区域。由于BackupDNS服务的一些比较烦人的缓存行为，导致这个操作花了好几分钟的时间，但很快该服务再次返回拒绝了所有.co.ao的查询。幸运的是，这一切都发生在安哥拉时间上午3点00分，结合了.co.ao TLD 的长TTL值，可能意味着有很少的用户实际上受到该事件的影响（如果有的话）。
从上述操作可以证实域名后缀确实是非常脆弱的。然后我重新检查了我收集的扫描结果，发现不仅如此。co.ao是脆弱的，但.it.ao，nic.ao和reg.it.ao也是脆弱的！it.ao是安哥拉国家的另一个域名后缀，通常用于国外域名。reg.it.ao是运行it.ao和.co.ao域名后缀的组织。
鉴于这些域名后缀被恶意劫持可能会发生巨大的影响，我决定阻止其他用户将这些区域添加到自己的BackupDNS帐户。我将所有域名后缀添加到我自己的帐户，但没有为他们创建任何区域数据，这确保了他们仍然可以返回常规的DNS错误，但是不会有结果，同时仍然要防止进一步的利用：
在防止漏洞可以被立即利用之后，我试图与.co.ao和.it.ao域名后缀的所有者联系。有关披露流程的更多信息，请参阅下面的“责任披露时间表”。
劫持TLD – 通过WHOIS入侵.na TLD
虽然劫持域名后缀名称服务器对于漏洞利用来说非常有用，但TLD可能会遭受到更高级别的入侵。TLD的所有权是保存在IANA根区域数据库上，可以列出托管的WHOIS记录中的持有者信息。作为攻击者，我们的主要兴趣是在于将名称服务器转换为我们自己的恶意域名服务器，以便我们可以为TLD提供备用的DNS记录。IANA有一个可以在这里找到的针对ccTLD启动这一变更的程序。以下是重要的摘录信息：
IANA工作人员将验证请求的授权/真实性，并从列出的TLD行政和技术联系人那里获取确认，这些联系人了解并符合所要求的更改。需要使用IANA注册的电子邮件地址进行电子邮件交换的作为认证。
要注意的是，如果WHOIS的管理员和技术联系人通过电子邮件确认他们希望进行更改，IANA将允许对TLD进行域名服务器更改（仅需完成此表单）。
为了测试这种做法的安全性，我列举了所有TLD 域名的WHOIS联系电子邮件地址，并使用我写的TrustTrees脚本来查找这些域的DNS配置中的任何错误。通过图表页的阅读后，我发现了一些在DNS中的有趣东西——.na*域名的联系人电子邮件地址域名（na-nic.com.na）。以下是该域的委派路径图：
该图的相关部分如下：
如上所述，域名的三个名称服务器在查询时都会返回致命错误。这些名称服务器，ns1.rapidswitch.com，ns2.rapidswitch.com和ns3.rapidswitch.com都属于托管DNS提供商RapidSwitch。如果我们在dig中进行查询，我们可以看到返回错误的具体细节：
$ dig NS na-nic.com.na @ns1.rapidswitch.com. ; <<>> DiG 9.8.3-P1 <<>> NS na-nic.com.na @ns1.rapidswitch.com. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 56285 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;na-nic.com.na. IN NS ;; Query time: 138 msec ;; SERVER: 2001:1b40:f000:41::4#53(2001:1b40:f000:41::4) ;; WHEN: Fri Jun 2 01:13:03 2017 ;; MSG SIZE rcvd: 31
名称服务器使用DNS REFUSED错误代码进行应答。正如安哥拉域名后缀一样，如果托管的DNS提供商在用户将其添加到其帐户之前未正确验证域名，则此错误代码可能表明该域容易受到攻击者的接管。为了检验这一想法，我创建了一个RapidSwitch帐户并导航到网站的“我的域名”部分：
“我的域名”部分包含一个“添加托管域”的按钮，这正是我正在寻找的东西。
完成此过程后，我可以将域添加到我的帐户，而无需任何所有权验证。看来，唯一的验证是进行检查，以确保RapidSwitch确实是指定域的名称服务器中列出的。
在我的帐户中的域名是有问题的，我不得不复制原始域名服务器的DNS设置，以防止中断域的DNS解析（该DNS为na-nic.com.na托管了电子邮件，网站等服务）。从我的帐户中删除域名会使该域名容易受到攻击者接管，因此我也必须克隆现有的记录。
创建记录之后，我为.na-nic.com.na添加了一些记录以证明我确实成功地劫持了这个域名的DNS。以下是dig查询显示的结果：
$ dig ANY proof.na-nic.com.na @ns2.rapidswitch.com ; <<>> DiG 9.8.3-P1 <<>> ANY proof.na-nic.com.na @ns2.rapidswitch.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49573 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;proof.na-nic.com.na. IN ANY ;; ANSWER SECTION: proof.na-nic.com.na. 300 IN A 23.92.52.47 proof.na-nic.com.na. 300 IN TXT "mandatory was here" ;; AUTHORITY SECTION: na-nic.com.na. 300 IN NS ns1.rapidswitch.com. na-nic.com.na. 300 IN NS ns3.rapidswitch.com. na-nic.com.na. 300 IN NS oshikoko.omadhina.net. na-nic.com.na. 300 IN NS ns2.rapidswitch.com. ;; ADDITIONAL SECTION: ns1.rapidswitch.com. 1200 IN A 87.117.237.205 ns3.rapidswitch.com. 1200 IN A 84.22.168.154 oshikoko.omadhina.net. 3600 IN A 196.216.41.11 ns2.rapidswitch.com. 1200 IN A 87.117.237.66 ;; Query time: 722 msec ;; SERVER: 2001:1b40:f000:42::4#53(2001:1b40:f000:42::4) ;; WHEN: Sat Jun 3 17:33:59 2017 ;; MSG SIZE rcvd: 252
如上所述，成功返回了TXT记录（和A记录），表名DNS确实被劫持了。在现实世界的攻击中，最后一步将是对其余的合法的名称服务器发起DDoS攻击，以消除DNS响应的竞争（我们显然不会采取这一步）*。
之后，我联系了.na TLD的持有者来报告漏洞，并尽快得到了解决。有关本披露时间表的更多信息，请参阅下面的“责任披露时间表”部分。
TLD /域名后缀被接管的影响
通用认证和国际域名
尽管这些漏洞影响到了安哥拉和纳米比亚国家的域名后缀，但这些影响远远不止这些国家。例如，许多流行的在线服务具有多个主页，其中包含了当地国家/地区的域名后缀，以使网站具有更多的本地化体验。许多这类网站将把所有这些主页与通用的认证流程结合在一起，自动将用户登录到任何主页，尽管它们实际上是单独的域名。
这方面的一个例子是Google，它具有许多域名后缀的搜索主页（这里聚合了相关内容）。其中的一个域名，当然是google.co.ao：
另一个是google.com.na：
为了提供更加无缝的用户体验，你可以轻松地将自己登录到任何Google首页（如果你已经通过其他主页向Google进了行身份验证），只需点击主页右上角的蓝色按钮即可。这个按钮只是一个类似于以下链接的链接：
HTTPS ：//accounts.google.com/ServiceLogin?hl=pt-PT&passive=true&continue=https://www.google.co.ao/%3Fgws_rd%3Dssl
访问此链接将导致302重定向到以下URL：
HTTPS ：//accounts.google.co.ao/accounts/SetSID?ssdc=1&sidt=[SESSION_TOKEN]&continue=https://www.google.co.ao/?gws_rd=ssl&pli=1
这会在sidt参数中传递一个会话令牌，它将你引导登录到google.co.ao域名，并允许跨越域名的身份验证。
这对漏洞利用来说意味着什么呢，就是如果你入侵了Google的任何Google首页域名后缀（Google域名后缀约为200个），那么你就可以利用该漏洞开始劫持任何地区的任何 Google帐户。这是一个奇怪的威胁模型，因为你很可能会利用200个域名后缀名称服务器或注册商中的一个，然后才能在其标准服务集合中获取有效的Google帐户进行漏洞利用。毕竟，Google拥有一个庞大的安全团队，会有人员不断的审计他们的基础设施，其中尽管TLD和域名后缀只是由随机的，通常是小型组织运行的。
为了实际的滥用这种类型的DNS劫持漏洞，你必须完成以下步骤（所有这些都是隐身的方式进行操作，以免被很快抓住）：
-
入侵域名后缀的名称服务器或注册商，就可以修改目标网站的名称服务器。
-
开始返回你控制的目标域的新的名称服务器并使用非常长的TTL进行应答（BIND的解析器默认支持长达一周）。这一点很重要，因为我们可以尽可能多的获取解析的缓存，我们也可以为google.co.ao/google.com.na子域名的A记录设置一个较小的TTL，以便我们可以在我们想要打击目标时，进行快速切换。
-
现在我们必须为我们的google.co.ao/google.com.na域名获得一个有效的SSL证书。这是最棘手的步骤之一，因为证书的透明度原因，这可以让我们很快被抓住。关于证书透明度的讨论，并且获得证书而不记录证书透明度日志是一个很复杂的事情，但足以说这么并不会那么容易实现。
-
我们现在设置了多台服务器来托管已启用了SSL 的恶意google.co.ao/google.com.na站点，并将所有A记录响应切换到我们的恶意服务器。然后，我们让尽可能多的Google用户访问上述链接，以给予我们他们的身份验证令牌，这取决于具体目标，这可能是一个更有针对性的活动等。这个攻击的有一个很好的部分是受害者甚至不需要必须访问指定的URL ，因为我们可以使用任何类似于<img>标签的请求（或者是能够发起GET请求的任何内容）都可以完成302重定向并产生我们正在寻找的内容。
影响的范围非常广泛
另一件要考虑的事情是，不仅仅只有* .co.ao， * .it.ao和* .na域名易受DNS劫持的影响，而且依赖于这些域名后缀的任何内容也可能变得脆弱不堪。例如，使用* .co.ao / * .it.ao / * .na名称服务器主机名的其他域名也可能会受到代理中毒的攻击（尽管胶水记录可能会使这种攻击方式比较棘手）。展示这些域名后缀的域名的相关WHOIS联系人也会面临危险，因为攻击者可以使用WHOIS来提取所有者拥有的域名并颁发SSL证书以及包含在网站上的HTTP资源。
结论和最后的想法
我希望我能有一个令人信服的论据，即域名后缀或 TLD的安全性并不是绝对的。请记住，即使使用了所有这些DNS攻击技巧，但最简单的攻击方法可能只是利用域名后缀名称服务器上运行的服务中的漏洞。在我看来，我认为互联网服务商和广大互联网社区应该采取以下措施来更好地保护DNS：
-
在涉及更改TLD重要设置时，除了 WHOIS联系人的电子邮件确认这个最低要求之外，还需要电话确认。
-
对TLD名称服务器设置更严格的要求 – 将端口的暴露限制为UDP / TCP的53端口。
-
执行TLD DNS的持续自动审核，并在检测到DNS错误时通知TLD运营商。
-
通知域名所有者，了解购买各种域名后缀/ TLD的风险，并记录过去的一些安全事件，以便人们在购买域名时能做出明智的决定。高度重视响应时间和解析时间来解决这些安全事件，这一点也很重要。
-
提高DNSSEC的意识，并推送DNS解析器来支持DNSSEC。DNSSEC的采用是非常糟糕的，如果使用域名和解析器来实现，它可以解决其中的一些劫持问题（假设攻击者还没有拿到密钥）。从个人经验来看，我甚至不会注意到DNSSEC的失败，因为我实际上没有使用任何网络（手机，家庭等）去执行它。我不会在整个DNSSEC上做更长的讨论和争议，但足以说明这肯定可以针对这些攻击进行额外的保护。
鉴于ccTLD涉及到多个国家的政治复杂性，一些执行政策无疑是非常棘手的。虽然我相信上述清单可以提高安全性，但我也明白，要确保这些事情发生也是非常困难的，特别是涉及到很多方面（总是比说起来容易）。话虽如此，重要的是衡量DNS的安全性与所涉各方的情况。鉴于这种攻击方式的攻击面非常大，我觉得TLD 或域名后缀被劫持入侵会是一件更加频繁的事件。