焦点报道:僵尸唤醒:利用域名托管服务对活跃域名进行隐蔽劫持
近年来,DNS托管服务逐渐兴起,为用户带来便捷的同时也引发了新的安全风险。与此同时,过期NS记录(指向不再解析域名的域名服务器)问题也引起了广泛的讨论与研究。本文将二者结合,发现了由DNS托管服务停用导致的驻留在二级域的过期NS记录,证明了借此发起域名隐蔽劫持攻击的可行性和危害性,并提出了可供多方参考的解决方案。本文发表于网络安全顶级学术会议CCS 2020(录用率:16.9%),作者主要来自美国印第安纳大学。
01【研究背景】
DNS托管服务是帮助用户管理域名并提高查询效率的有效方式。客户在服务商创建账户并添加域名,服务商分配一组域名服务器来管理域名并响应DNS查询请求。不同的服务商对于域名服务器的分配方式各不相同,比如 DigitalOcean 为所有用户分配固定的一组域名服务器,而 CloudFlare 和 GoDaddy 则从域名服务器池中随机选择。
(资料图片)
图表1:托管在CloudFlare上的域名
在接收托管域名时,有部分托管服务商并不会检查用户对被托管域名的所有权,允许用户添加不属于自己的域名解析关系。在下图所示的案例中,用户在没有控制百度域名的情况下,在Amazon Route 53托管平台上增添了baidu[.]com的解析记录。不过一般情况下,由于顶级域处的授权信息没有改变,在域名baidu[.]com的递归解析过程中不会访问到Amazon的服务器,因此这样的配置似乎不存在安全问题。
图表2:AWS Route 53托管服务允许用户添加baidu[.]com的解析关系
然而,本文发现当域名停用托管服务时,其二级域内有可能仍然保留指向旧托管商的“过期”NS记录;而如果这个旧的托管商允许任意添加解析关系,则有可能导致域名劫持。与已被研究的“悬空记录”(保留在顶级域内的过期NS记录)[1] 不同,本文发现的攻击模型基于二级域(SLD)内的过期记录。它们因为位于正常解析路径之外,并未引起足够的重视,造成的攻击效果也更加隐蔽。
因此,论文研究的核心目标包括:
通过设计实验证明,利用这种过期NS记录发起新型攻击是实际可行的。
通过测量分析证明,这种新型攻击方式的危害性很大。
根据调查研究,提出可供不同机构参考的解决方案。
02【研究方法】
1. Zaw攻击模型
当域名(例如example[.]com)的所有者不再使用某托管服务时,可能会将域名SLD区域信息从托管服务商名下的域名服务器(例如ns.provider[.]com)直接导入到新的DNS服务器(例如ns.example[.]com)。在这种转移模式下,SLD区域保留了指向旧的托管服务器(ns.provider[.]com)的过期NS记录。正常情况下,这条过期的记录仅存在于SLD区域中,不会在递归解析过程中被使用到;旧的服务商也停止了对这个域名的解析。
图表3:域名不再使用托管服务后的解析过程
然而,由于这条过期记录的存在,攻击者可以隐蔽地对域名example[.]com进行劫持,步骤如下。
首先,攻击者在托管服务商处谎称自己是这个域名的所有者,并且通过ns.provider[.]com重新配置example[.]com的资源记录,指向恶意地址(步骤1-2)。
随后,查询域名example[.]com的NS类型资源记录(步骤3)。
根据域名查询规则,SLD区域内的NS记录优先级高于TLD区域 [2],因此将被缓存(步骤4-8)。然而,这就导致了过期的NS记录也被写入缓存,可能在后续查询中被解析器选中[3]。
因此,解析器在处理后续对于example[.].com的查询时,将可能查询到旧服务商的服务器,并返回攻击者配置的恶意记录(步骤9-14)。
图表4:Zaw域名劫持攻击流程
上述攻击模型就被称为“僵尸唤醒”(Zaw攻击),这种过期NS记录被称为“僵尸授权”(Zrefs),建立起的域名劫持解析路径被称为“僵尸解析通道”。
2. Zaw攻击的危害性测量
从攻击模型中总结,Zaw攻击模型成功,需要具备两方面的条件:
域名在SLD层面存在过期的NS记录,将这样的域名称为PVD(Potentially Vulnerable Domain)
域名托管服务商不检查域名的所有权,允许配置任意域名的解析
从这两方面入手,作者设计出了工具 ZreFinder 来半自动化地发现Zrefs,用于大规模地发现PVD及相应的服务商。
图表5:ZreFinder工作流程图
1)PVD和服务商挖掘
PVD与正常域名的不同点在于,它们在SLD层比TLD多出了过期的NS记录,因此可以通过两级NS记录的不一致性确定PVD。随后,对于多出的NS记录,进一步地识别和检查所属的DNS托管服务商。作者选取了Alexa Top 1M 域名作为筛选对象,筛选出4914个PVD、11个主流服务商和6个免费服务商。
2)托管服务商策略检查
满足以下任一条件的托管服务商,并不支持任意配置域名,因此需要把它们移除:
服务商需要用户认证对域名的所有权,才允许用户添加域名
同一服务商名下同时存在过期NS记录(Zrefs)和有效NS记录
服务商同时也是注册商,会直接禁止非法的域名添加行为
服务商停止了对特定TLD下域名的服务(如国家顶级域)
作者利用上述方法,从4914个PVD中进一步筛选出了628个确认可被劫持的域名。
3)对于DNS解析器的实际测试
在完成上述域名和服务商分析后,进一步检验DNS解析器确实能被用于域名劫持。具体而言,作者注册了新的域名,每一个子域名用于向相应的解析器发送查询请求。同时按照攻击流程来配置记录,查看是否能够建立“僵尸解析通道”。
作者选取了11K个解析器进行分析,包括12个知名DNS运营商的46个知名公共解析器、1个组织内部解析器和6个DNS实现设施。与已有工作相比,实验规模更大、涉及范围更广。
03【主要发现】
1. 可被劫持的域名特征及托管服务商
1)影响范围
涵盖体育、商业、教育、政府、金融、购物和大型企业等领域,攻击者可以隐蔽地获取这些领域重要域名的流量来实现用户信息收集、钓鱼或恶意软件传播等行为,造成严重的危害。存在范围较广、数量较多的域名都是有风险的,且与多个主流托管服务商相关,充分证明了问题的流行性和严重性。
图表6:可被劫持的域名类别及其托管服务商分布
2)TLD分布
有60%可被劫持的域名位于 .com 下,国家顶级域 .ir 和 .gr 占比较大。其中伊朗因遭受制裁而被 Domain.com 列入黑名单,但其他服务商还在正常提供服务,导致伊朗域名从服务商迁出时留下了大量的过期NS记录。
图表7:可被劫持的域名的TLD分布
3)存在劫持风险时长
在实验进行的91天中,89.97%的可被劫持的域名在至少30天中存在Zrefs,65.29%全程存在Zrefs,只有4.93%在10天内消除了隐患。大部分域名都为攻击者提供了较长的利用时间。
图表8:可被劫持的域名的风险时长分布
4)Zref来源
利用Passive DNS确认,至少有17.36%的域名被确认是由于域名服务器迁移导致的。
2. DNS解析器实验结果
有83.33%的运营商网络中,至少存在一个能被污染的解析器,攻击者只需平均6.5次尝试就可以成功向缓存中注入恶意IP。作者进一步检验解析器是否支持DNSSEC,发现大部分知名解析器都支持DNSSEC,但63.62%的解析器存在被污染风险,其中只有21.88%支持DNSSEC验证。这说明容易受到Zaw攻击的是没有DNSSEC保护的解析器,DNSSEC对Zaw攻击的防护至关重要。
3. Zaw的攻击复杂度分析
1)缓存污染成功率高
对于每一个可被劫持的域名,作者向40个解析器发送查询A记录的请求,并要求解析器只通过缓存返回结果。将同一运营商名下的解析器归为同一类,统计一致率和缓存缺失率。结果发现4个一致率较高的运营商的缓存缺失率均高达99%,证明攻击者想找到投毒时机是较为容易的。
图表9:缓存污染成功率结果(部分)
2)Zref被选中的概率高
选中Zref的概率等于从TLD区域的NS记录中选择一个SLD区域服务器的概率与从这个SLD区域服务器的NS记录中选中Zref的概率之积。通过计算发现,有 62.26%的域名Zref选择率不低于50%,有42.99%的域名Zref选择率接近100%,由此可见Zref选择率很高,对攻击者很利好。
图表10:选中Zref的概率计算
3)DNSSEC的部署率低
完整部署的DNSSEC记录包含DNSKEY、RRSIG和DS,作者依次查看可被劫持的域名中是否存在这三部分信息,发现98.56%的域名三者均不具备,1.27%的域名至少拥有DNSKEY,只有一个域名部署了完整的DNSSEC。由此可见在这些域名中DNSSEC部署的严重缺失,也进一步说明了DNSSEC部署的紧迫性。
04【缓解措施】
对于域名托管服务商,可以采取:
要求用户在注册商处登记TLD级别的随机生成的NS记录,只有从解析路径中观察到这个随机记录才激活域名。
对于检测出过期NS记录的域名,强制重新分配不同的域名服务器。
提醒用户及时删除不需要的NS记录,或逐步缩短无用记录的TTL值。
对于解析器运营商,可以采取:
广泛应用在TLD级别的范围限制规则 Bailiwick rule ,拒绝缓存不在子域范围内的记录
给予TLD区域数据更高的可信度,优先缓存来自TLD区域的记录
尽快部署DNSSEC
05【结论】
本文首次对驻留在SLD区域的过期NS记录的危害进行了大规模的研究,证明了这种新型的记录可以被攻击者借助DNS托管服务用于隐蔽域名的劫持。进一步,作者通过测试大量的域名、主流托管服务商和解析器运营商,分析了这种新型攻击的影响范围和实际危害。最后,作者提出了多种有效的缓解措施来帮助各方应对这种新型安全风险。
原文链接
https://dl.acm.org/doi/10.1145/3372297.3417864
参考文献
[1] Daiping Liu, Shuai Hao, and Haining Wang. 2016. All your DNS records point to us: Understanding the security threats of dangling DNS records. ACM CCS 2019
[2] Robert Elz and Randy Bush. 1997. Clarifications to the DNS specification. RFC 2181. RFC Editor. https://tools.ietf.org/html/rfc2181
[3] Yingdi Yu, Duane Wessels, Matt Larson, and Lixia Zhang. 2012. Authority server selection in DNS caching resolvers. Proceedings of the ACM SIGCOMM Computer Communication Review, 80–86.
孙俊哲,编辑&审校 | 陆超逸
相关阅读
-
焦点报道:僵尸唤醒:利用域名托管服务对...
近年来,DNS托管服务逐渐兴起,为用户带来便捷的同时也引发了新的安... -
“星链”如何助力美军作战指挥能力提升_...
“星链”是美国太空探索技术(SpaceX)公司推出的商业低轨卫星星座... -
从美军“黑色天空”演习看联合电磁战指控
2022年9月19~23日,美国太空训练与战备司令部完成了首次“黑色天空... -
美国2023年隐私立法的未来:各州、儿童...
1月5日,IAPP发布了一篇名为“2023年隐私的未来:美国各州、儿童和... -
脚本小子的狂欢:ChatGPT首次被黑客用于...
自去年11月推出测试版以来,人工智能聊天机器人ChatGPT已经被各行业... -
PowerShell远程代码执行漏洞 (CVE-2022...
PowerShell是一种跨平台的任务自动化解决方案,由命令行shell、脚本...