在之前我写文章介绍了通过不同级别的DNS欺骗控制后缀为na,co.ao以及it.ao的域名，其中我们测试了顶级域名(TLD)的威胁模型，并且测试了攻击者实现这一攻击的方法。最简单的方法之一就是注册一个TLD权威名称服务器。攻击原理是TLD可以具有管理任意域名的名称服务器，可能因为某些原因，比如配置出现错误，或者域名过期，导致有人可以注册名称服务器的域名，并且达到对整个TLD区域的控制。

利用“域名后缀”的漏洞劫持国家顶级域名（一）

利用“域名后缀”的漏洞劫持国家顶级域名（二）

IO异常

周五晚上，我在使用自己写的脚本收集各种顶级域名的DNS代理情况时，发现后缀名为io的顶级域名有些不同：

这个脚本中有一个功能是你可以传递一个Gandi API密钥，然后它会自动检测在代理链中的名称服务器是否有可以被注册的域名。在上图中可以看到Gandi’s API返回了多个域名，不过这并不代表这些域名是可以进行购买的。因为之前遇到过这种情况，域名服务商显示此域名可用，不过并不可以进行购买，他会提示此域名处于保留状态。于是在它返回域名列表之后，以防万一，我对域名进行了访问，并且在NIC.IO中检测返回结果是否正确。在快速检测之后我惊讶的发现ns-a1.io是可以作为名称服务器进行注册的，注册费用是90美元，于是我对它进行购买，看看是否会成功，过了一会，我受到了一封邮件，显示域名购买服务正在进行：

不知道为什么我收到了域名为101domain.com的确认邮件，不过很显然io域名的注册甚至整个注册机制都是这个公司进行管理的。由于我购买的时候已经凌晨，下单之后就直接睡觉了，直到下一个周三下午我正准备去上班，一封邮件让我想起来我还在注册这个域名：

我发现已经注册成功，立刻检测了一下我是不是已经控制了io后缀的名称服务器中的一个，执行了dig命令，并且已经为ns-a1.io列出了我测试的DNS名称服务器：

bash-3.2$ dig NS ns-a1.io

; <<>> DiG 9.8.3-P1 <<>> NS ns-a1.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8052
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ns-a1.io.          IN  NS

;; ANSWER SECTION:
ns-a1.io.       86399   IN  NS  ns2.networkobservatory.com.
ns-a1.io.       86399   IN  NS  ns1.networkobservatory.com.

;; Query time: 4 msec
;; SERVER: 2604:5500:16:32f9:6238:e0ff:feb2:e7f8#53(2604:5500:16:32f9:6238:e0ff:feb2:e7f8)
;; WHEN: Wed Jul  5 08:46:44 2017
;; MSG SIZE  rcvd: 84

bash-3.2$

我查询了一个位于底层的DNS服务器，同样这个域名被列为io顶级域名的权威名称服务器，这就足够可以确定我们的猜想是正确的：

bash-3.2$ dig NS io. @k.root-servers.net.

; <<>> DiG 9.8.3-P1 <<>> NS io. @k.root-servers.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19611
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 12
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;io.                IN  NS

;; AUTHORITY SECTION:
io.         172800  IN  NS  ns-a1.io.
io.         172800  IN  NS  ns-a2.io.
io.         172800  IN  NS  ns-a3.io.
io.         172800  IN  NS  ns-a4.io.
io.         172800  IN  NS  a0.nic.io.
io.         172800  IN  NS  b0.nic.io.
io.         172800  IN  NS  c0.nic.io.

;; ADDITIONAL SECTION:
ns-a1.io.       172800  IN  AAAA    2001:678:4::1
ns-a2.io.       172800  IN  AAAA    2001:678:5::1
a0.nic.io.      172800  IN  AAAA    2a01:8840:9e::17
b0.nic.io.      172800  IN  AAAA    2a01:8840:9f::17
c0.nic.io.      172800  IN  AAAA    2a01:8840:a0::17
ns-a1.io.       172800  IN  A   194.0.1.1
ns-a2.io.       172800  IN  A   194.0.2.1
ns-a3.io.       172800  IN  A   74.116.178.1
ns-a4.io.       172800  IN  A   74.116.179.1
a0.nic.io.      172800  IN  A   65.22.160.17
b0.nic.io.      172800  IN  A   65.22.161.17
c0.nic.io.      172800  IN  A   65.22.162.17

;; Query time: 70 msec
;; SERVER: 2001:7fd::1#53(2001:7fd::1)
;; WHEN: Wed Jul  5 08:46:14 2017
;; MSG SIZE  rcvd: 407

太棒了，现在我通过ssh连接上去在这个域名下的测试dns服务器，直接关掉了正在运行的BIND服务。如果我现在开始接受DNS流量的话，我当然不想让合法访问io域名的人察觉已经被攻击。关闭bind服务不再接收53端口的查询，并且使DNS查询会自动跳转到其他名称服务器上，所以并不会很大程度上干扰流量。为了看看我是否会接收到流量，我将所有DNS流量全部写入到一个文件当中，以便于查看我获得到多少条查询。我利用互联网上的数百个随机ip进行查询，结果看起来这个域名确实为整个io
TLD提供流量，可能这只是一开始，因为很多DNS客户端都可能存在缓存，如果缓存更新之后，可能攻击就不会起作用.

报告TLD中的安全问题

慢慢的服务器不再接受任何dns查询，我认为应该尽可能快的修复好这一缺陷。我主要的担心是目前还存在有很多名称服务器是可以被注册的，并且这种攻击任何人只要有钱和一定的基础就可以实现。我查找了io后缀域名的TLD的联系人：

然后我写了一个问题的总结，并通过电子邮件发送给了两个联系人，并传达了修复这个问题的紧迫性。我表示我会对其他TLD域名中可以注册的名称服务器进行关注，并表明如果我在几个小时内没有收到回复，我将继续注册并保护TLD。发送电子邮件后，我立即收到一条回复邮件，[email protected]邮件地址竟然不存在：

我相信这个域名的服务商迟早会看到这篇文章的，我接下来将所有的能够购买的域名全部买了下来，防止其他人劫持TLD。就像第一个域名一样，我设置了我的DNS服务器，不会影响入站通信。

这样至少不会被其他攻击者利用，我就可以安心的使用我的服务。

接下来几天里，我拨打了NCIO提供的电话号码，要求他们提供负责公司安全人员的电子邮件地址，以便我联系他们公司的安全团队。服务人员将[email protected]告诉我说这是问题的负责人，虽然我觉得不太可能能够解决问题，但是我还是将问题总结发送给了这个地址。并且希望通过这个邮件告知安全人员。在达成一定的共识之后，我就开始等待回复。

通过撤销购买域名进行修复

第二天中午，我收到了101Domains的通知，指出我的域名被停用，我的提出问题邮件已被回答，我的所有域名都被注册机构撤销：

震惊！abuse它竟然是问题反馈邮箱！在我登录到101Domain之后，我发现了101domain法律部门发来的消息：

很好，在我通知之后，很快时间就得到了响应，并且在我尝试重新注册这些域名时，没有成功，于是我确定已经把漏洞修补了。

漏洞影响

因为我们已经能够接管7个权威名称服务器中的4个，所以完全有能力对所有注册是io域名进行DNS投毒攻击。不仅如此，我们已经掌握了多数名称服务器，所以客户端可能选择到被劫持的名称服务器，甚至在使用长TTL响应之前，进一步提高我们攻击成功的可能性。

一种防止被攻击的方法是io TLD启用DNSSEC。启用之后，这种攻击不会对自己的服务奏效。话虽如此，不过很多场合都不知吃DNSSEC，除非专门设置一个DNSSEC解析器。

TLD安全方面防护

我已经写了一些关于如何从顶级域名（TLD）角度来解决这些问题的一些问题。在未来，我希望发布一个更广泛的指南，了解TLD和域名扩展运营商如何更好地监控并防止发生这样的问题。