翻译：WisFree
预估稿费：200RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
传送门
【技术分享】劫持一个国家的顶级域名之旅：域名后缀的隐藏威胁（上）
检测过期的TLD/后缀NS的域名
这种方法是我比较有信心成功的，所以我花了不少的时间开发出了一款能够检测这种漏洞的工具。
首先，我们要枚举出给定域名后缀所对应的全部域名服务器的主机名，然后查看是否存在可以进行注册的基域名（Base-Domain）。但现在的问题在于，很多域名注册商虽然告诉你这个域名可以注册，但当你真正尝试购买这个域名时又会遇到各种问题。而且在某些情况下，虽然域名解析服务器对应的域名过期了，但这个域名仍然无法再次购买或注册，而且也没有被标记为“已被预订”。因此，我们可以通过扫描给定TLD或域名后缀空间来了解域名的购买情况。
检查托管TLD／后缀NS的DNS错误
另一种寻找漏洞的方式就是扫描常见的DNS错误以及服务器的错误配置，并分析你所发现的异常情况。此时我们可以使用这款名叫ZoneMaster的工具，它不仅是一款通用DNS配置扫描工具，而且还可以扫描大量域名解析服务器／DNS的错误配置。为了方便起见，我使用了简单的脚本并配合ZoneMaster的强大功能来扫描公共后缀列表中所有的域名后缀，扫描结果非常的有趣，其中一项分析结果我在之前的文章中已经介绍过了【参考资料】，另一项分析结果请大家接着往下看。
在错误中发现了漏洞
在上一章节中，我使用了脚本并配合ZoneMaster工具实现了针对公开后缀列表中TLD和域名后缀的自动化扫描，并得到了一个非常有趣的扫描结果。在分析扫描结果时，我发现当我尝试向NS请求.co.ao域名时，.co.ao后缀所对应的其中一个域名解析服务器返回了一个DNS REFUSED错误码：
存在问题的域名解析服务器ns01.backupdns.com似乎是由一个名叫Backup DNS的第三方DNS主机服务商托管的：
在对这个网站进行了分析之后，我发现这是一个非常老的DNS托管服务商，它主要托管的是备用DNS服务器（以防止主NS无法响应）。不过，让我感兴趣的是DNS错误码REFUSED，一般来说只有域名解析服务器没有空间存储特定域名时才会返回这个错误码。这是非常危险的，因为DNS提供商通常都允许任意账户设置DNS空间，而且不会对域名所有权进行验证。这也就意味着，任何人都可以创建一个账号以及.co.ao的域名空间来更新DNS记录。
为了验证我的观点，我在该网站创建了一个新的账号，然后访问她们的文档页面：
为了创建.co.ao的域名空间，我首先要将域名空间通过域名管理面板添加到我的账号中：
这一步在没有任何验证的情况下顺利完成了，但是我们还没有加载任何空间数据。接下来就是在远程主机中设置一个BIND服务器，然后将其配制成.co.ao空间的权威域名解析服务器。除此之外，服务器还得允许从BackupDNS域名解析服务器进行DNS区域传送，这样域名空间数据才可以被拷贝过来。下面的几张图片显示的是完整的操作过程：
我们从主DNS服务器开始（BIND服务器设置在AWS），我们要将目标BackupDNS域名解析服务器的数据拷贝进去。
BackupDNS的域名解析服务器会在一定时间间隔内发送DNS区域传送请求（AXFR DNS查询），这就相当于域名解析服务器询问“可以给我一份.co.ao所有的DNS数据吗？”
在BIND服务器中配置了allow-transfer之后，我们的主NS将接受BackupDNS域名解析服务器的DNS区域传送请求，随后数据将拷贝完成。现在，我们就已经在BackupDNS服务中正确地创建出了的.co.ao域名空间。
说实话，我从来没想过这种方法竟然可行，因为我之前曾经测试过很多域名解析服务器，但之前都以失败告终了。为了提升成功率，我拷贝过去的域名空间中TTL值为1秒，SOA记录为60秒。如果你之前的尝试无法成功，那么我强烈建议各位通过这种设置来最小化缓存的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服务中的zone文件。但是现在，所有针对.co.ao的查询请求BackupDNS服务返回的都是REFUSED。这样一来，我们就可以确定域名后缀.co.ao是存在漏洞的，不仅如此，就连.it.ao、.nic.ao和.reg.it.ao都同样存在漏洞。
如果这些域名后缀被恶意劫持，那么后果将不堪设想，因此考虑到这些漏洞的影响力，我决定阻止用户将该域名空间添加至自己的BackupDNS账号。我将上述后缀添加到了我的账号中，但是并没有创建任何的zone数据，这样可以保证它们返回的仍然是常规的DNS错误并防止漏洞被进一步利用：
通过上面的操作只能暂时防止漏洞被利用，因此我立刻尝试与相应后缀（.co.ao和.it.ao）的管理员进行联系。
劫持一个顶级域名-通过WHOIS入侵顶级域名.na
顶级域名（TLD）持有者的信息可以在WHOIS记录中找到，而这些数据均存储在IANA Root Zone数据库中。我们现在感兴趣的是如何将原本的域名解析服务器改成我们自己的恶意域名解析服务器，这样我们就可以为TLD设置可更改的DNS记录了【操作方法】。
需要注意的是，如果WHOIS记录中的管理员和技术支持（身份通过电子邮件认证）同时申请修改TLD的域名解析服务器并提交这份申请表单，那么IANA将会允许修改。因此，我枚举出了目标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: 31NS返回的是一个DNS REFUSED错误码，这也就意味着，如果DNS提供商无法在用户将域名空间添加至自己的账号之前对域名进行正确的验证，那么这个域名将有可能被攻击者接管。为了验证我的观点，我创建了一个RapidSwitch账号，然后找到“My Domains”选项部分：
“My Domains”选项中包含一个“Add Hosted Domain”按钮，点击之后如下所示：
完整操作之后，我成功地在没有进行域名所有权认证的情况下将域名添加到了我的账号中。接下来，我只需要克隆现存的DNS记录，然后将记录添加到proof.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的管理人员取得了联系并报告了这个漏洞，并敦促他们尽快解决这个问题。
传送门