登陆 注册

谁劫持了我的DNS:全球域名解析路径劫持测量与分析

№` ﹍°Y`` 2019-04-30 DNS全球域名解析路径劫持测量分析

或许你已知道网络中几乎所有的DNS请求都是通过明文进行传输的,但是你是否相信,这一协议设计的缺陷,已经开始被用于域名解析路径劫持了?

问题背景

由于某些运营商利用DNS解析服务器植入广告等盈利行为,运营商的DNS解析服务器一直备受质疑[2~6], 而公共DNS服务器(如Google的8.8.8.8)由于其良好的安全性与稳定性被越来越多的互联网用户所信任。然而,我们发现,这层信任关系会轻易地被DNS解析路径劫持所破坏。网络中的劫持者将用户发往指定公共DNS的请求进行劫持,并转发到其他的解析服务器。除此之外,劫持者还会伪装成公共DNS服务的IP地址,对用户的请求进行应答。从终端用户的角度来看,这种域名解析路径劫持难以被察觉。我们设计并部署了一套测量平台用于检测全球范围的DNS解析路径劫持现象。  

主要研究结论

1.  劫持的规模:在全球3047个自治域中,我们在259个自治域内发现了DNS解析路径劫持现象。特别是在中国,近三成发往谷歌公共DNS服务器的UDP流量被劫持。

2.  劫持特点:在不同的自治域中,路径劫持策略和特点有着明显差异。整体而言,通过“UDP”协议传输发往“知名公共DNS服务器”的“A记录类型”的数据包更容易成为劫持目标。

3.  安全威胁:我们不仅观测到劫持设备会篡改DNS响应结果,而且,通过对劫持者所使用的DNS服务器的分析,我们发现其功能特性和安全性均存在隐患。

4. 劫持目的: 我们认为,DNS解析路径劫持的主要目的是减少运营商网间流量结算成本,而非提高用户DNS服务器的安全性或优化DNS查询的性能。

5.  解决方案:我们认为,解决DNS解析路径劫持的最佳方案是,在推进DNSSEC大规模规范部署的同时,加快DNS加密方案的实施。

威胁模型

我们首先阐述所关注的威胁模型。部分网络用户可能选择使用公共DNS服务器,正常情况下,其DNS解析路径如图一蓝线所示。同时,我们假设路径上的某些设备可能会监控用户的DNS请求流量,并且能够劫持和操纵用户的DNS请求。例如,将满足预设条件的DNS请求转发到中间盒子(Middlebox),并使用其他替代的DNS服务器(Alternative resolver)处理用户的DNS请求;最终,中间盒子通过伪造IP源地址的方式将DNS应答包发往终端用户,此时的解析路径如图一红线所示。   

 图1 威胁模型示意

        

通过对DNS数据包“请求阶段”中的解析路径进行划分,我们将DNS解析路径分为四类。首先是正常的DNS解析路径(Normal resolution),用户的DNS请求只到达指定的公共DNS服务器;此时,权威服务器应当只看到一个来自公共服务器的请求。剩下三类均属于DNS解析路径劫持。第一类DNS路径劫持方法是请求转发(Request redirection),用户的DNS请求将直接被重定向到其他的服务器,解析路径如图二红线所示;此时,权威服务器只收到来自这个服务器的请求,用户指定的公共DNS服务器完全被排除在外。第二类方法是请求复制(Request replication),用户的DNS请求被网络中间设备复制,一份去往原来的目的地,一份去往劫持者使用的解析服务器,解析路径如图二黄线所示;此时,权威服务器将收到两个相同的查询。第三类方法是直接应答(Direct responding),用户发出的请求同样被转发,但解析服务器并未进行后续查询而是直接返回一个响应,解析路径如图二蓝线所示;此时,权威服务器没有收到任何查询,但是客户端却收到解析结果。

 

 图2DNS解析路径类别(仅考虑请求阶段)

 

我们注意到,可能造成DNS解析路径劫持的设施种类较多,不仅包括运营商部署的中间盒子[7],还包括恶意软件、反病毒软件[8]、防火墙以及企业代理[9]等。在这项研究中,我们重点关注如何检测这种现象,因此不对劫持者进行区分。

测量分析

对于DNS解析路径劫持现象,我们在测量分析中依次回答了下列问题:

1. DNS解析路径劫持规模有多大?

我们设计了两个阶段的实验。第一阶段,研究全球范围通过TCP协议传输的DNS数据包,结果在2691个自治域中,198个自治域检测到DNS解析路径劫持,7.36%的DNS数据包受到影响;第二阶段,研究中国范围内通过UDP和TCP协议传输的DNS数据包,结果在356个自治域中,61个自治域检测到DNS解析路径劫持,17.13%的DNS数据包受到影响。

特别是,在中国网络中, 通过UDP协议发往Google公共DNS的数据包,有27.9%受到DNS解析路径劫持的影响(通过TCP传输时为7.3%);相比而言,对于不知名的DNS服务器,同样也有9.8%的数据包受到影响(通过TCP传输时为1.1%)。

2.DNS解析路径劫持有什么特点?

-- 路径劫持类型层面的特征

   我们发现,直接应答劫持方式(Direct responding)极少发生。这很可能是因为此时的响应结果明显是不正确的。此外,请求转发(Request directing)的比例要高于请求复制(Request replication)的比例。

-- 自治域层面的特征

       在每个自治域内,解析路径劫持的特点差别巨大,即使在同一个自治域内,由于劫持者的多样性,整体表现出的劫持特征也会较为复杂。 例如,在表1选取的案例中,AS9808和AS56040这两个自治域同属于一家运营商,但是在请求复制类型的比例上也存在明显差异。

表1 DNS解析路径劫持在不同自治域内的特点 

3.劫持现象对DNS查询性能有什么影响?

1)不同类型的解析路径劫持对DNS查询性能有什么影响?

将各DNS请求完成的时间(Round trip time, RTT)进行累积分布作图,得到图三。相比于未被劫持的请求(绿色曲线),我们发现通过请求复制(红色曲线)的劫持方式确实能够提高DNS查询的性能,总体的查询时间更短;但是通过请求转发的方式(黄色曲线)不能够稳定地实现这一目标。另外,我们向用户的本地DNS服务器(Local DNS resolver)发送一个DNS数据包用于作性能对比,结果显示其性能曲线(蓝色)与请求转发的性能曲线高度近似。

 

图3DNS查询性能对比

 2) 对于请求复制这一场景,哪一个查询数据包会更先到权威服务器?

另一个我们感兴趣的问题是,当劫持者使用请求复制(Request replication)方式劫持解析路径时, 如果从权威服务器的角度观测,原始的DNS请求和复制的DNS哪个会更先到达权威服务器。图四显示我们对这一时间差异的分析。 对于大部分的自治域而言,复制后的DNS请求会更先到达权威服务器,然而我们仍然发现了一个属于中国电信的自治域,其中所有被复制后的请求均比原始请求要慢。我们推测,这种现象可能是由于自治域内设备部署不当引起的,或是此时的DNS数据包经过了更长的路由导致的。

 

图4 复制抢答式路径劫持性能分析

4.劫持者是否会篡改DNS响应数据包内容?

我们在所收集的实验数据中,发现了上百例DNS解析结果被篡改的案例。通过人工分析,导致DNS响应记录被篡改的原因包括:本地流量网关、灰色流量变现、管理员误配置等。例如,图五是我们发现劫持并修改Google公共DNS服务器响应内容一个案例,劫持后的网页内容为一款移动APP的推广信息。

 

 图5某运营商劫持DNS流量示例

5.路径劫持会带来哪些安全威胁?

-- 道德与隐私风险

    劫持者很可能在未征得用户同意的情况下,篡改用户的DNS访问,不仅带来了道德问题,而且给用户的隐私来了风险。

-- 网络故障

    劫持者的行为使得用户的网络链路更加复杂,当出现故障时难以排除。

-- DNS功能特性

    替代DNS服务器可能缺乏DNS的某些功能特性,例如,根据终端子网返回最优的IP地址的选项(EDNS Client Subnet,ECS)。

-- DNS服务器安全性

        劫持者所使用的替代DNS服务器往往不遵守最佳安全实践。例如,我们发现仅有43%的替代DNS服务器“接受”DNSSEC请求;而且,所有使用BIND软件的替代DNS服务器版本都严重落后(全部低于BIND 9.4.0,应当于2009年过期)。

6.劫持背后的目的是什么?

我们调研了大量设备提供商与软件提供商,整理出一份能够提供DNS解析路径劫持功能的厂商列表[10~12]。我们收集产品的功能介绍信息并结合实际测量结果,推测劫持背后的目的。

1) 提高用户DNS服务器的安全性。我们观测到发往知名公共DNS的数据包更容易被劫持,而且相当一部分劫持者使用的解析服务器可能存在安全问题。因此,该结论虽然不能完全排除,但我们认为不是劫持的主要目的。

2) 优化用户的DNS查询性能。我们发现请求复制式劫持能够提高DNS查询性能;但在实际网络中,劫持者更多的是采用请求转发的方式。因此,大部分的劫持并不是为了优化DNS查询性能。

3) 减少运营商网间流量结算成本。发往公共DNS服务器的异网流量对中小型运营商而言,提高了运营商的流量结算成本。通过对异网DNS流量进行管控,可以有效节省网间流量结算成本。 因此,我们倾向于认为这是DNS解析路径劫持的主要原因。通过与国内某大型运营商线下交流,我们确认了这一结论。

解决方案

我们认为,解决DNS解析路径劫持的最佳方案是在部署DNSSEC的基础上,推进DNS加密方案的部署。 DNSSEC能够解决DNS响应记录内容被中间盒子篡改的问题,部署DNSSEC可以保证终端用户拿到正确的响应结果。 然而,此时DNS流量仍然通过明文传输,存在隐私隐患。DNS加密方案,包括DNS-over-TLS [13]、DNS-over-HTTPS等,不仅解决明文传输时的隐私威胁,而且可以对用户所使用的DNS服务器进行认证,进而最终解决劫持者伪装公共DNS服务器的问题。

目前,Firefox浏览器从第62版本开始支持DNS-over-HTTPS。此外,越来越多的公共DNS服务器和知名DNS软件开始逐步支持不同的DNS加密方案,其中公共DNS服务器包括Google、Cloudflare、Quad9等,知名的DNS软件包括BIND、Unbound、Knot、CoreDNS等。

总结

在这项研究中,我们系统地分析了DNS解析路径劫持这一威胁。通过全球范围的大规模测量研究,分析了其规模、特点、安全威胁以及目的。在论文发表后,多个国际知名安全媒体对我们的研究内容进行了报道,包括ACM TechNews、The Register、 HackRead、HelpNet Security 和 Rambler [14~17] 等。我们希望这项研究结果,能够进一步推进DNSSEC和加密DNS方案的大规模规范部署和应用。

作者简介

刘保君,清华大学计算机系博士研究生,导师段海新教授与刘莹教授,曾在UC Berkeley 访问研究,在Vern Paxson教授指导下工作。主要研究方向为网络基础设施安全,包括DNS、Web、CDN等系统的安全以及地下产业检测。现有学术论文发表于USENIX Security、DSN等网络安全会议。

参考文献

[1] Liu, B., Lu, C., Duan, H., Liu, Y., Li, Z., Hao, S., & Yang, M. Who Is Answering My Queries: Understanding and Characterizing Interception of the DNS Resolution Path. In USENIX Security (2008).

[2] DAGON, D., PROVOS, N., LEE, C. P., AND LEE, W. Corrupted dns resolution

paths: The rise of a malicious resolution authority. In NDSS (2008).

[3] WEAVER, N., KREIBICH, C., NECHAEV, B., AND PAXSON, V. Implications of netalyzr dns measurements. In Proceedings of the First Workshop on Securing and Trusting Internet Names (SATIN), Teddington, United Kingdom (2011).

[4] WEAVER, N., KREIBICH, C., AND PAXSON, V. Redirecting dns for ads and profit. In FOCI (2011).

[5] KUHRER, M., HUPPERICH, T., BUSHART, J., ROSSOW, C., AND HOLZ, T. Going wild: Large-scale classification of open dns resolvers. In Proceedings of the 2015 ACM Conference on Internet Measurement Conference (2015), ACM, pp. 355–368.

[6] CHUNG, T., CHOFFNES, D., AND MISLOVE, A. Tunneling for transparency: A large-scale analysis of end-to-end violations in the internet. In Proceedings of the 2016 ACM on Internet Measurement Conference (2016), ACM, pp. 199–213.

[7]Is your ISP hijacking your dns traffic? https://labs.ripe.net/Members/babak_farrokhi/is-your-isp-hijacking-your-dns-traffic.

[8]Avast secure DNS. https://help.avast.com/en/av_abs/10/etc_tools_secure_dns_overview.html.

[9]Cisco umbrella intelligent proxy.

https://learn-umbrella.cisco.com/feature-briefs/intelligent-proxy.

[10] ZDNS: Solutions for campus network services. http://free.eol.cn/edu_net/edudown/2017luntan/zdns.pdf.

[11]The practice of DNS traffic control based on out-of-band responder

Mechanism. http://www.ttm.com.cn/article/2016/1000-1247/1000-1247-1-1-00064.shtml.

[12] Cisco: DNS configuration guide. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dns/configuration/12-4t/dns-12-4t-book/dns-config-dns.html.

[13] Hu, Z., et al. Specification for DNS over transport layer security (TLS). No. RFC 7858. 2016.

[14] ACM Technews. How Often Are Users' DNS Queries Intercepted? https://technews.acm.org/archives.cfm?fo=2018-08-aug/aug-24-2018.html.

[15] The Resigter. How's that encryption coming, buddy? DNS requests routinely spied on, boffins claim. https://www.theregister.co.uk/2018/08/20/dns_interception/.

[16] HackRead. Hackers can intercept and manipulate DNS queries, researchers warn. https://www.hackread.com/hackers-can-intercept-and-manipulate-dns-queries-researchers-warn/.

[17] Rambler. Most DNS queries can be easily intercepted, experts say.https://news.rambler.ru/other/40604197-bolshinstvo-dns-zaprosov-legko-perehvatit-schitayut-eksperty/.

请发表您的评论
请关注微信公众号
微信二维码
不容错过
Powered By HeiBaiTeam.