劫持一个国家的顶级域名之旅-华盟网

劫持一个国家的顶级域名之旅

华盟学院山东省第二期线下学习计划

http://p6.qhimg.com/t0125edef6cf4653161.png

 

写在前面的话

域名不仅是我们实现互联网的基础,而且也让我们在访问互联网资源时方便了许多。虽然很多人在自己的日常生活中都会使用到各种各样的域名,但是几乎很少有人真正了解它们的运行机制。在多个抽象层以及多种Web服务的帮助下,用户可以轻松地购买并持有域名,然后在完全不了解DNS、域名注册商或WHOIS的情况下搭建好自己的整个站点。虽然这种抽象形式给终端用户带来了很多好处,但同样也给他们屏蔽了很多重要信息。比如说,很多域名注册商会向用户积极推荐.io域名,但是又有多少个购买了.io域名的用户清楚谁才是背后真正持有并管理这些.io域名的人呢?

我想表达的并不是“绝大多数的域名持有者都不知道自己域名背后的运行机制”。实际上,我想在这篇文章中跟大家讨论的是域名后缀(Domain Extension)的安全问题。

 

DNS结构简介

注:如果你已经清楚DNS的工作机制及其委派机制的话,你可以直接跳过这一章节。

那么,当你购买一个域名时,你真正购买的实际上是什么呢?简单来说,你购买的实际上是一些NS(域名解析服务器)记录,这些记录托管在域名后缀的域名解析服务器上,其中还不包括类似WHOIS、域名注册商服务以及ICANN服务这样的辅助性服务在内。我在研究过程中发现,如果想要深入理解DNS的运行机制,那么可视化绝对是一种非常好的学习方式,因此我专门编写了这款名叫TrustTrees的工具,它可以生成一个域名的委托路径图。为了更好地理解域名后缀在整个DNS执行链中的具体位置,我们先来看一看下面这张图片,图片中显示的是example.com的委托链。

http://p7.qhimg.com/t0106dc9eb60b4acdd6.png

如上图所示,委托链起始于根节点DNS服务器,并通过一系列节点之间的传递最终寻找到目标域名解析服务器,客户端发送的DNS查询请求同样起始于根节点DNS服务器。客户端会向其中一个root域名解析服务器发送DNS查询请求,但服务器起始并不知道如何响应这种请求,因此它会将查询请求委托给TLD(顶级域名),而TLD会负责将请求发送给正确的域名解析服务器,最终客户端将接收到正确的域名解析服务器所返回的权威应答。上图显示了所有可能的委托路径(蓝色代表权威应答),之所以会存在这么多路径,是因为DNS响应中包含一堆随机排序的应答列表,这是为了均衡查询负载而设计的(这种技术名为Round Robin DNS)。根据返回结果的不同顺序,最终负责处理查询请求的域名解析服务器也会不同,因此它们也有可能提供不同的查询结果,上图中也显示了不同的排序以及域名解析服务器之间的关系。

因此,你在购买了example.com之后,.com将会向其DNS空间中添加一些NS记录,这些记录负责将有关example.com的DNS查询请求委托给你所提供的域名解析服务器。这种“委托给你域名解析服务器”的方式不仅可以允许你控制自己的域名,而且还可以允许你创建example.com的任意子域名以及DNS记录。如果.com将指向你域名解析服务器的NS记录移除了,那么任何人都无法再访问到你的域名解析服务器,因此example.com也就没有意义了。

实际上在上图所示的链图中,TLD和域名后缀的工作机制是十分相似的。TLD之所以能够存在并进行操作,是因为根域名解析服务器将查询请求委托给了TLD的域名解析服务器,如果根域名解析服务器突然将.com的NS记录从其域名空间数据库中删除了,那么全世界所有的.com域名都将无法正常访问。

与域名一样,域名后缀同样会受到域名解析服务器漏洞的影响

http://p0.qhimg.com/t01c514abaf41d92db1.png

我们现在已经清楚了,TLD和域名后缀与普通域名一样都是拥有域名解析服务器的,那么问题就来了,“这是否意味着TLD和域名后缀与普通域名一样也会受到DNS安全问题的影响呢?”答案是肯定的。如果你阅读我我们之前发布的一些文章,你就会知道我们有多种方法来劫持域名解析服务器。不仅如此,我们还介绍了如何利用过期域名劫持域名解析服务器【参考资料一】以及如何在未经认证的情况下拿到域名空间的完整控制权【参考资料二】。有了上面这些知识储备之后,我们准备实现一个更加有意思的目标:接管整个域名后缀。

 

接管域名后缀-攻击计划

与恶意攻击者不同的是,我并不打算走捷径来实现我们的目标,即劫持一个域名后缀。我会按照攻击域名后缀的研究方法来带着大家一步一步进行操作。但是我发现,很多域名后缀/TLD域名解析服务器都处于一种非常不安全的状态,所以利用漏洞并获取到一个域名后缀的控制权其实比你想象的还要简单。虽然讨论类似“如何在域名解析服务器/记录上实现远程代码执行”这样的话题有些超纲了,但我还是要提到这部分内容,因为这也是实现我们目标的方法之一。

一般来说,攻击者一般会使用下面这些方法来入侵一个TLD或域名后缀:

利用DNS服务器(该服务器托管了一个给定的域名后缀)中的漏洞或利用域名后缀的域名解析服务器中其他服务的漏洞。攻击域名记录的方法同样属于这种类型,因为更新域名空间对它们来说属于常规操作。

查找并注册一个过期或拼写有误的域名解析服务器域,它可以提供针对域名后缀/TLD的权威应答。

通过创建一个DNS空间来劫持域名后缀。

查找TLD的WHOIS联系信息,并劫持其电子邮箱地址。

接下来,我们会对上面这些方法一一进行讨论,并尝试一步一步实现我们的目标。

很多TLD和域名后缀的域名解析服务器都存在安全漏洞

在研究第一种攻击方法之前,我打算对所有TLD的域名解析服务器进行一次简单的端口扫描。一般情况下,服务器会开启端口53来监听UDP/TCP连接,此时所有其他的端口都将处于关闭状态。鉴于这些域名解析服务器的功能和地位都如此重要,所以管理员们都会尽可能地缩小服务器与外界的接触范围,暴露任何多余的服务(例如HTTP、SSH或SMTP等等)都意味着我们在给攻击者提供更多的入侵方法。

 

Finger协议

203.119.60.105(e.dns-server.vn): 顶级域名.vn的权威域名解析服务器(越南)

202.29.151.3(munnari.oz.au):顶级域名.ba的权威域名解析服务器(波斯尼亚和黑塞哥维那)

Les Earnest于1971年设计出了Finger协议,该协议允许用户检查远程计算机中某个用户的状态。这是一个非常老的协议,现代系统几乎不会再使用这个协议了。这个协议的核心观点正好可以回答下面这个问题:“嗨,Dave现在正在使用他的设备吗?他正在忙吗?”在Finger协议的帮助下,你可以检测远程用户的登录名、真实名称、终端名称、空闲时间、登录时间、办公地点以及办公电话等等。接下来,我们会利用Finger协议来检查上面那个波斯尼亚的权威域名解析服务器,然后查看root用户的情况:

[sourcecode language="plain"]
bash-3.2$ finger -l root@202.29.151.3
[202.29.151.3]
Login: root Name: Charlie Root
Directory: /root Shell: /bin/sh
Last login Sat Dec 14 16:41 2013 (ICT) on console
No Mail.
No Plan.
[/sourcecode]

看来这个服务器的root用户已经很久没上过线了…接下来,我们看一看越南的那个域名解析服务器:

[sourcecode language="plain"]
bash-3.2$ finger -l user@203.119.60.105
[203.119.60.105]
Login name: nobody In real life: NFS Anonymous Access User
Directory: /
Never logged in.
No unread mail
No Plan.
Login name: noaccess In real life: No Access User
Directory: /
Never logged in.
No unread mail
No Plan.
Login name: nobody4 In real life: SunOS 4.x NFS Anonymous Access User
Directory: /
Never logged in.
No unread mail
No Plan.
Login name: named In real life: User run named
Directory: /home/named Shell: /bin/false
Never logged in.
No unread mail
No Plan.
bash-3.2$
bash-3.2$ finger -l root@203.119.60.105
[203.119.60.105]
Login name: root In real life: Super-User
Directory: / Shell: /sbin/sh
Last login Tue Sep 30, 2014 on pts/1 from DNS-E
No unread mail
No Plan.
[/sourcecode]

 

这个服务器的root用户上一次登录时间为2014年9月30日。需要注意的是,这些服务器安装了Finger协议,也就暗示了这些服务器的年代到底有多么久远。

 

动态网站

除了端口53之外,域名解析服务器中最常见的开放端口应该就是端口80(HTTP)了,我们甚至可以直接访问这些网站来获取很多有意思的信息。比如说,其中的一个域名解析服务器会直接将我重定向到一个广告网站:

[sourcecode language="plain"]
* Rebuilt URL to: http://93.190.140.242/
* Trying 93.190.140.242...
* Connected to 93.190.140.242 (93.190.140.242) port 80 (#0)
> GET / HTTP/1.1
> Host: 93.190.140.242
> Accept: */*
> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0
>
< HTTP/1.1 302 Moved Temporarily
< Server: nginx/1.10.1
< Date: Sun, 04 Jun 2017 03:16:30 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: close
< X-Powered-By: PHP/5.3.3
< Location: http://n158adserv.com/ads?key=6c6004f94a84a1d702c2b8dc16052e50&ch=140.242
<
* Closing connection 0
[/sourcecode]

 

我现在还无法确定这是不是一台已经被入侵的域名解析服务器,或者说这只是管理员单纯地想赚外快而已。

某些其他的域名解析服务器(例如阿尔巴尼亚的.com.al, .edu.al, .mil.al, .net.al和.nic.al域名解析服务器)则会返回各种配置页面,这些页面提供了关于当前设备的verbose信息:

https://p9.qhimg.com/t01de7327e1ac2acaf5.png

如果不能在远程服务器上运行命令行工具的话,总感觉少了点什么:

http://p1.qhimg.com/t015f873d597b0b31cb.png

总结

除此之外,某些域名解析服务器中还加载了很多有趣的服务,但在此我就不对其进行赘述了。对于域名解析服务器来说,类似SMTP、IMAP、MySQL、SNMP和RDP这样的端口很可能都处于开放状态,这些服务给攻击者提供了很多攻击切入点,这将会极大地提高攻击者的入侵成功率。但我不鼓励大家进行更深入地测试,因为我们的目的并不是为了进行恶意操作。其实很多域名解析服务器早就已经过时了,而且服务器所运行的软件其安全性也是千疮百孔。不幸的是,由于这些服务器的年代过于久远,我们甚至连管理员都无法联系到,更别说去修复这些漏洞了。

 

 

http://p0.qhimg.com/t016262cb4c5bc5d753.jpg

检测过期的TLD/后缀NS的域名

这种方法是我比较有信心成功的,所以我花了不少的时间开发出了一款能够检测这种漏洞的工具。

首先,我们要枚举出给定域名后缀所对应的全部域名服务器的主机名,然后查看是否存在可以进行注册的基域名(Base-Domain)。但现在的问题在于,很多域名注册商虽然告诉你这个域名可以注册,但当你真正尝试购买这个域名时又会遇到各种问题。而且在某些情况下,虽然域名解析服务器对应的域名过期了,但这个域名仍然无法再次购买或注册,而且也没有被标记为“已被预订”。因此,我们可以通过扫描给定TLD或域名后缀空间来了解域名的购买情况。

检查托管TLD/后缀NS的DNS错误

另一种寻找漏洞的方式就是扫描常见的DNS错误以及服务器的错误配置,并分析你所发现的异常情况。此时我们可以使用这款名叫ZoneMaster的工具,它不仅是一款通用DNS配置扫描工具,而且还可以扫描大量域名解析服务器/DNS的错误配置。为了方便起见,我使用了简单的脚本并配合ZoneMaster的强大功能来扫描公共后缀列表中所有的域名后缀,扫描结果非常的有趣,其中一项分析结果我在之前的文章中已经介绍过了【参考资料】,另一项分析结果请大家接着往下看。

在错误中发现了漏洞

在上一章节中,我使用了脚本并配合ZoneMaster工具实现了针对公开后缀列表中TLD和域名后缀的自动化扫描,并得到了一个非常有趣的扫描结果。在分析扫描结果时,我发现当我尝试向NS请求.co.ao域名时,.co.ao后缀所对应的其中一个域名解析服务器返回了一个DNS REFUSED错误码:

http://p3.qhimg.com/t01f517b367a19c521a.png

存在问题的域名解析服务器ns01.backupdns.com似乎是由一个名叫Backup DNS的第三方DNS主机服务商托管的:

http://p6.qhimg.com/t01909254cb1764d1e3.png

在对这个网站进行了分析之后,我发现这是一个非常老的DNS托管服务商,它主要托管的是备用DNS服务器(以防止主NS无法响应)。不过,让我感兴趣的是DNS错误码REFUSED,一般来说只有域名解析服务器没有空间存储特定域名时才会返回这个错误码。这是非常危险的,因为DNS提供商通常都允许任意账户设置DNS空间,而且不会对域名所有权进行验证。这也就意味着,任何人都可以创建一个账号以及.co.ao的域名空间来更新DNS记录。

为了验证我的观点,我在该网站创建了一个新的账号,然后访问她们的文档页面:

https://p9.qhimg.com/t0114d6756388eb3ecb.png

为了创建.co.ao的域名空间,我首先要将域名空间通过域名管理面板添加到我的账号中:

http://p0.qhimg.com/t01492aa4ffb4e76d92.png

这一步在没有任何验证的情况下顺利完成了,但是我们还没有加载任何空间数据。接下来就是在远程主机中设置一个BIND服务器,然后将其配制成.co.ao空间的权威域名解析服务器。除此之外,服务器还得允许从BackupDNS域名解析服务器进行DNS区域传送,这样域名空间数据才可以被拷贝过来。下面的几张图片显示的是完整的操作过程:

http://p8.qhimg.com/t0171cb154d7c561c0a.png

我们从主DNS服务器开始(BIND服务器设置在AWS),我们要将目标BackupDNS域名解析服务器的数据拷贝进去。

http://p8.qhimg.com/t01a8115369111e20a9.png

BackupDNS的域名解析服务器会在一定时间间隔内发送DNS区域传送请求(AXFR DNS查询),这就相当于域名解析服务器询问“可以给我一份.co.ao所有的DNS数据吗?”

http://p4.qhimg.com/t016d7de28480623eb8.png

在BIND服务器中配置了allow-transfer之后,我们的主NS将接受BackupDNS域名解析服务器的DNS区域传送请求,随后数据将拷贝完成。现在,我们就已经在BackupDNS服务中正确地创建出了的.co.ao域名空间。

说实话,我从来没想过这种方法竟然可行,因为我之前曾经测试过很多域名解析服务器,但之前都以失败告终了。为了提升成功率,我拷贝过去的域名空间中TTL值为1秒,SOA记录为60秒。如果你之前的尝试无法成功,那么我强烈建议各位通过这种设置来最小化缓存的DNS响应。

接下来,BackupDNS的域名解析服务器会立刻处理.co.ao的DNS流量,当服务确认了拷贝数据之后,我使用dig命令并通过一次查询请求再次对服务器进行了确认:

[sourcecode language="plain"]
$ 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
[/sourcecode]

可是现在的情况看起来不太对啊。我一开始在BIND文件中存放了一些NS记录,用来将DNS查询请求转发给合法的域名解析服务器,但是现在BIND配置文件中出现了一些问题,服务器本该返回一个DNS引用,但服务器现在返回的是一个NXDOMAIN的权威应答,所以我赶紧删掉了BackupDNS服务中的zone文件。但是现在,所有针对.co.ao的查询请求BackupDNS服务返回的都是REFUSED。这样一来,我们就可以确定域名后缀.co.ao是存在漏洞的,不仅如此,就连.it.ao、.nic.ao和.reg.it.ao都同样存在漏洞。

如果这些域名后缀被恶意劫持,那么后果将不堪设想,因此考虑到这些漏洞的影响力,我决定阻止用户将该域名空间添加至自己的BackupDNS账号。我将上述后缀添加到了我的账号中,但是并没有创建任何的zone数据,这样可以保证它们返回的仍然是常规的DNS错误并防止漏洞被进一步利用:

https://p9.qhimg.com/t01d13931bd927d8e27.png

通过上面的操作只能暂时防止漏洞被利用,因此我立刻尝试与相应后缀(.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)。具体请参考下面这张委托路径图:

http://p0.qhimg.com/t01e8a5e95dac3104f5.png

与测试相关的委托部分如下图所示:

http://p4.qhimg.com/t01e675f1a7550d9739.png

如上图所示,当我们发送请求时,这些域名解析服务器将会返回致命错误。ns1.rapidswitch.com、ns2.rapidswitch.com和ns3.rapidswitch.com都属于DNS管理服务商RapidSwitch,我们可以通过dig命令查看到服务器返回的错误详情:

[sourcecode language="plain"]
$ 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
[/sourcecode]

NS返回的是一个DNS REFUSED错误码,这也就意味着,如果DNS提供商无法在用户将域名空间添加至自己的账号之前对域名进行正确的验证,那么这个域名将有可能被攻击者接管。为了验证我的观点,我创建了一个RapidSwitch账号,然后找到“My Domains”选项部分:

http://p8.qhimg.com/t01fe12654c7c194e49.png

“My Domains”选项中包含一个“Add Hosted Domain”按钮,点击之后如下所示:

http://p6.qhimg.com/t01bccc1415c4ed28b6.png

完整操作之后,我成功地在没有进行域名所有权认证的情况下将域名添加到了我的账号中。接下来,我只需要克隆现存的DNS记录,然后将记录添加到proof.na-nic.com.na,此时我们就成功地劫持了该域名的DNS。请看下面的dig请求结果:

[sourcecode language="plain"]
$ 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
[/sourcecode]

如上所示,请求返回了TXT记录(以及A记录)也证实了DNS劫持的问题。在真实的攻击中,最后一步就是对合法的域名解析服务器进行DDoS攻击来消除DNS请求的竞争。

证实了安全问题的确存在滞后,我尝试与顶级域名.na的管理人员取得了联系并报告了这个漏洞,并敦促他们尽快解决这个问题。

 

 

https://p9.qhimg.com/t01c6816c8a87675dfb.jpg

 

通用认证&国际域名

当然了,这些漏洞不仅仅只会影响安哥拉和纳米比亚等国家的域名后缀,受影响的国家还有很多很多。比如说,很多热门的网络服务为了给全球各地的用户提供更好的本地体验,它们的主页会使用很多国家的域名后缀。其中的大多数网站会将其所有的主页绑定在一个通用认证流中,并将登录服务的用户自动重定向到使用本地区域名后缀的主页。

其中的一个例子就是谷歌的搜索主页,这个主页就使用了多个域名后缀(有关谷歌域名后缀的信息请参考【这里】)。比如说其中的google.co.ao:

http://p4.qhimg.com/t01a65b00799ef04b0b.png

另外一个例子是google.com.na:

http://p4.qhimg.com/t0135f7bbb829b5b575.png

为了享受更加无缝的网络体验,你可以直接点击页面右上角的蓝色按钮(Sign in-登录)在任何一个后缀的谷歌主页登录你的账号。点击这个按钮约等于访问下面这条链接:

[sourcecode language="plain"]https://accounts.google.com/ServiceLogin?hl=pt-PT&passive=true&continue=https://www.google.co.ao/%3Fgws_rd%3Dssl[/sourcecode]

如果直接访问这个链接的话,后台服务器会将你重定向至下面这个链接:

[sourcecode language="plain"]https://accounts.google.co.ao/accounts/SetSID?ssdc=1&sidt=[SESSION_TOKEN]&continue=https://www.google.co.ao/?gws_rd=ssl&pli=1[/sourcecode]

链接会通过sidt参数传递一个会话令牌,它会将你登录到google.co.ao域名并允许进行跨域认证。

但这些东西对于我们的漏洞利用有何帮助呢?如果你成功入侵了任意一个谷歌主页域名后缀,那么你就可以利用这个漏洞来劫持任何一个谷歌账号。但这毕竟是一种非常奇特的威胁模型,因为在攻击一个谷歌账号之前你必须要入侵两百个谷歌域名后缀NS中的其中一个才行。而且攻击的难度也不低,毕竟谷歌拥有一个非常强大的安全团队,而这些技术人员会不断审查他们的基础设施状态。

为了成功利用这种类型的DNS劫持漏洞,你需要按照以下步骤进行操作(所有操作必须悄悄进行,以免被抓个现行):

1.入侵一个域名后缀的域名解析服务器(或记录),然后修改目标网站的域名解析服务器。

2.开始返回你针对目标域名所设置的新域名解析服务器,并设置时间较长的TTL(BIND的解析器默认支持至少一周的时间)。这一点非常重要,因为这样我们就可以尽可能地得到更多的缓存,我们还需要为google.co.ao/google.com.na子域名的A记录设置较短的TTL,这样我们就可以在它们之间进行快速切换了。

3.接下来,我们要拿到一份针对google.co.ao/google.com.na域名的有效SSL证书。这是其中最棘手的一个步骤了,因为证书透明(Certificate Transparency)很可能会暴露我们的恶意行为。有关SSL证书的内容请参考【这篇文章】。

4.现在我们设置了多台服务器来托管恶意的google.co.ao/google.comna网站并启用了SSL,然后将所有的A记录响应更改为指向我们的恶意服务器。接下来,我们就可以开始让尽可能多的谷歌用户去访问上面给出的链接,访问之后我们就能够获取到他们的认证令牌了。这种攻击方法的一个优势就是目标用户甚至不用去手动访问那个URL地址,因为我们可以通过类似<img>这样的标签来发送GET请求,并利用这些请求来完成302重定向操作。

影响范围非常大

另一个需要考虑的方面是,受这个DNS劫持漏洞影响的并非只有*.co.ao、*.it.ao和*.na域名,实际上任何一个依赖于这些域名后缀的站点都将会受到该漏洞的影响。比如说,其他同样使用了*.co.ao/*.it.ao/*.na域名服务器的主机将有可能受到代理攻击,而且WHOIS联系方式中如果暴露了域名后缀的相关信息,那么这些网站同样是非常危险的,因为攻击者可以利用WHOIS信息来获取SSL证书。

总结与思考

我希望可以通过这篇文章让大家意识到顶级域名或域名后缀的安全性其实是非常不可靠的。请大家一定要记住,虽然现在有很多针对DNS的欺骗技术,但是最简单的攻击方法就是利用域名后缀NS中某项服务的漏洞来实施攻击。在我看来,我认为互联网服务商和广大社区应该采取下列措施来提升DNS的安全性:

1.对于修改顶级域名中重要参数的行为,需要对操作者的身份进行电话验证,最低的要求是对WHOIS联系信息中的电子邮件地址进行确认。

2.对顶级域名的域名解析服务器设置更加严格的安全要求,限制暴露在网络中的接口,尽可能地只开启UDP/TCP端口53。

3.对顶级域名的DNS进行定期的自动化安全审计,一旦自动化检测系统发现了DNS错误,则立刻通知DNS管理员。

4.向域名拥有者告知购买多种域名后缀/顶级域名的安全风险,并保存过去曾发生的安全事件记录。这样一来,当用户准备购买某个域名时,我们就可以确保他们能够作出明智的决定了。除此之外,我们还应该重视例如响应时间和解析时间等安全因素,因为它们对于域名的安全性也同样重要。

5.提高对DNSSEC(DNS安全扩展)的认知,并让DNS解析器支持使用DNS安全扩展。如果我们采用了DNSSEC,并且域名和解析器都采用了的话,它将可以帮助我们更好地抵御这些DNS劫持攻击。根据我的个人经验来看,我平时根本没有见过DNSSEC失效的情况,因为几乎没有一个网络采用过这项安全防护技术。在这里我并不想强迫大家去部署DNSSEC,但我想告诉大家的是DNSSEC绝对可以为你的基础设施带来一层额外的安全保护,并帮助你更好地抵御DNS劫持攻击。

注:DNSSEC,即Domain Name System Security Extensions,中文意思为DNS安全扩展。DNSSEC是由IETF提供的一系列DNS安全认证机制(具体请参考RFC2535),它提供了一种请求来源鉴定和数据完整性验证的功能扩展,而正是由于DNS基础设施中存在这样那样的劫持漏洞,所以我们才需要引入这种被称为DNS安全扩展的技术以保护互联网中这一部分重要的通信基础设施。

http://p0.qhimg.com/t01676cf65c9309a888.png

虽然一些涉及到ccTLDs(即国家和地区顶级域名,目前200多个国家都按照ISO3166国家代码分配了顶级域名,例如中国是cn,日本是jp等)的情况会非常棘手,但我相信本系列文章所给出的安全观点和操作建议可以帮助你提升网站以及DNS基础设施的安全性,而与此同时我也非常明白,确保这些安全方案得到真正的实施其实也是一件非常困难的事情,因为永远都是说起来容易做起来难。

无论怎样,DNS目前的安全情况都不容乐观,而且考虑到DNS基础设施面临着非常大的攻击面,我认为今后顶级域名或域名后缀被攻击的事件将会发生得愈加频繁。

www.idc126.com

本文翻译自 thehackerblog.com,https://thehackerblog.com/the-journey-to-hijacking-a-countrys-tld-the-hidden-risks-of-domain-extensions/index.html。如若转载请注明出处。

本文由 华盟网 作者:AlexFrankly 发表,其版权均为 华盟网 所有,文章内容系作者个人观点,不代表 华盟网 对观点赞同或支持。如需转载,请注明文章来源。
0

发表评论