互联网云的雨幡洞：云中域名接管风险大规模检测与分析

论文题目：Detecting and Measuring Security Risks of Hosting-Based Dangling Domains （本文为ACM SIGMETRICS 2023会议录用，该会议为网络测量与高性能领域的国际顶会之一）

一、研究概述

当前网络环境中，子域名接管已演变成一种普遍且带有重大危害性的网络劫持手段，攻击者可以劫持并滥用他人的域名从事恶意行为。想象一个“大型房地产公司”有许多“房产”，有些房产因客户租约到期未续约、呈闲置状态。而因房地产公司疏于管理，这些房屋仍然挂着房地产公司的牌子，但实际上里面空无一人。此时，如果有“不法份子”发现了这些闲置房屋，可能悄悄地搬进去占据这些地方，从事非法活动。

转回到网络世界中的子域名接管攻击，主域名（房地产公司）下的某个子域名（房产）如果未被妥善管理，比如解析到了一个不再使用的服务或者外部资源，攻击者可以发现并利用这种停用的服务或资源来“接管”这个子域名，将该域名解析到攻击者控制的服务器。这样，攻击者就可以滥用这个子域名开展恶意活动，例如钓鱼攻击、散布恶意软件，甚至冒充合法服务实施网络诈骗等。这类攻击方式因其低成本、高危害、难检测而备受关注，它会使大量的合法域名落入不法分子之手，破坏了当前网络的信任机制，使得互联网上呈现的内容变得不再可靠。

​

近年来，重大的域名接管事件屡见不鲜，众多知名企业、媒体网站乃至政府机构的网络安全频频遭受威胁。例如，美国前总统竞选筹款网站（donaldtrump.com）曾经托管至国际知名CDN服务商Cloudflare，不法分子利用Cloudflare的域名所有者身份认证缺陷，用自己的账号接管了该域名的管理配置权限，并通过Cloudflare用该网站发布诋毁信息（图1）。除此之外，微软等科技巨头的网站在近几年也成为了域名接管的受害者（图2）。虽然公众对于这类威胁的认识逐渐提高，但子域名接管攻击的发生频率依然在不断上升，且其检测与防御过程颇具挑战。

本文深入分析了当前的网络部署形势，发现公共云托管服务（如CDN、Web托管服务）已成为网站部署的主流选择，众多网络服务倾向于将网站托管到更加安全、可靠的第三方云平台上。然而，这些云平台在网站接入时可能并未严格验证域名所有权，任何人都可以在这个平台上声称自己拥有某个域名，并选择为该域名部署网站资源。这种云平台的域名所有权验证缺陷为攻击者提供了域名接管的“突破口”，形成了互联网云中的“雨幡洞”。

针对这一问题，本研究提出了一种创新性的检测框架，期望能够大规模地发现存在域名所有权验证缺陷的公共云服务厂商，并提出可行的修复建议，帮助安全社区解决基于云托管服务的域名接管难题。此外，该检测框架采用被动重构域名解析依赖链的方法，能有效地检测出那些托管到了缺陷服务、容易被接管的风险域名。

本文揭示了主流云托管服务普遍存在的域名所有权验证脆弱性，并证实了亚马逊、腾讯等52家国际知名厂商的65种服务可被利用。在对一百万个流行网站（Tranco Top 1M）的子域名的测量实验中，我们成功识别出10,351个易受域名劫持影响的流行域名，涵盖了国内外知名高校（如斯坦福大学、莱斯大学）、政府机构（如美国国立卫生研究院）以及国际著名组织和企业（如诺贝尔奖组委会、万豪集团、百度）的网站。此外，通过为期半年的周期性测量实验，我们发现超过60%的受影响域名面临着长期（持续5天及以上）的安全威胁。总体而言，这项研究不仅深入揭示了域名劫持问题的严重性，也为防范此类攻击提供了有效的解决方案。

二、研究背景

2.1 域名接管问题

域名接管是一类Use-After-Free漏洞，它是指一个域名（或子域名）被解析到了一个已被删除、过期或不再由域名所有者主动管理的目标互联网资源，而该资源可以被其他人（如攻击者）申请使用，这就间接导致了该域名可以被攻击者控制并劫持。这里所称的“目标资源”可能包括三类：（1）可被任何人申请控制的IP地址，如VPS IP；（2）过期的域名；（3）已经被停用的第三方托管服务（如CDN、Web建站服务等），这些资源在过期或释放后可能会被攻击者申请并控制。此时，一旦攻击者接管了某个子域名，就可以无偿地利用接管域名行违法之事，例如部署恶意资源、发起网络钓鱼攻击、窃取cookie或会话令牌等敏感信息，或者可以采取措施降低接管域名的声誉或排名。

域名接管问题出现的主要原因之一在于，域名所有者未清除指向被弃用互联网资源的DNS解析资源记录，这类解析记录被称为“悬空域名指针”。常见的悬空域名指针有以下几种类型：

I. CNAME型：CNAME记录将一个域名A映射到另一个域名B。如果目标域名B为过期域名，或者是可以通过第三方平台申请到的CNAME节点域名，那么域名A就可能被攻击者接管。

II. A型：如果域名A被解析到一个已经被释放并随后可以被攻击者获取到的IP地址，那么攻击者可以通过申请该IP，进而劫持所有发往域名A的请求流量。

III. NS或MX型：与CNAME型类似，域名A使用的权威服务器或者邮件服务器域名可能已经过期，或者是公共托管服务分配给用户的NS/MX节点域名，攻击者也可能通过控制NS/MX域名间接接管域名A。

2.2 公共云托管服务

公共云托管服务（如WordPress、Cloudflare、Amazon S3）由于具备较高的可扩展性、可靠性和安全性，目前已经成为部署互联网应用的首选方案。本文将研究视角聚焦到利用公共云托管平台实施域名接管攻击的检测问题。

​

图4简化展示了在云托管服务平台上部署自定义域名的流程：假设一个云租户Alice注册了Web托管服务，并尝试将其域名custom.alice.com（自定义用户域名）托管至该服务平台。首先，平台需要验证Alice是否为该域名的所有者。为此，Alice需配置由服务提供商临时发放的验证令牌，如在权威服务器上创建TXT记录。一旦挑战记录通过验证，平台便会分配网络资源，被称为域名接入节点，用于为Alice的域名提供服务。这些节点可能包括名称服务器、IP地址或平台控制的子域名。例如，平台可能为custom.alice.com分配一个或多个CNAME节点，如custom-alice.service.com。在确认CNAME记录存在后，平台将开始为该域名提供服务，这也标志着域名接入成功。

​

安全可靠的公共云托管服务需要完成以下两方面的验证过程，确保托管域名的租户对该域名有控制权，且判断域名已被成功接入： **I. 域名所有权验证（DOV）：**域名所有者是指域名注册人或域名管理员，有权配置该域名的权威服务器。一个云租户可以通过两种方式在托管平台上声明域名所有权：（i）基于DNS的验证：服务提供商生成一个随机挑战令牌，并要求客户在DNS记录中配置该挑战值。例如，让租户通过TXT记录配置一条临时生成的随机字符串。（ii）基于HTTP的验证：服务提供商要求云租户将包含挑战令牌的文件上传到网站上的某个特定路径。现在许多互联网服务都要求有效的域名所有权验证，但目前还没有统一的标准做法。 **II. 域名接入验证（DCV）：**本文将步骤(4)和(5)称为域名接入过程（Domain connection）。云租户必须通过权威域名服务器为其托管的域名配置指向云托管服务域名接入节点的DNS资源记录。常见的域名接入方法包括：（i）通过NS记录将自定义域名委托至给定的权威名称服务器；（ii）将域名解析至服务提供商管理的CNAME；（iii）将域名解析至服务提供商管理的IP地址池；或（iv）结合以上提到的方法。

三、威胁模型

本文关注的威胁模型称为基于云托管服务的域名接管攻击。为便于描述，下文统一将存在安全脆弱性、可被攻击者利用的公共云托管服务称为“脆弱服务”，将脆弱服务上托管的、处于可被接管状态的用户域名称为“风险域名”。

3.1 云托管服务域名验证环节的安全脆弱性

在实际的部署场景中，为了平衡安全性和可用性，公共云托管服务商通常会将域名所有权验证（DOV）与域名接入验证（DCV）过程合并为一个步骤以简化验证程序，即通过验证“用户域名成功接入随机分配的服务域名”来证明域名所有权的归属。比如从一个庞大的NS/CNAME域名池中随机抽取2-3个域名赋予单一云租户，用这种“随机选取域名接入节点”的方法替代“生成并验证随机挑战令牌”的步骤。在这种机制下，成功将自定义用户域名（Custom domain）关联到随机分配的接入节点的云租户，将被认定为该域名的所有者。

然而，如果公共云托管服务的域名接入节点分配机制不具备高度随机性，且未严格执行安全的DOV验证过程，那么该服务极易引入域名接管攻击威胁。本文将云托管服务域名验证环节可能存在的安全脆弱性分为三种情形：（a）对托管域名的云租户未执行任何形式的DOV检验；（b）虽然执行了DOV检验，但检验策略存在可被利用的漏洞；（c）采取分配随机接入节点以替代DOV的方法，但随机性不足，导致攻击者能够利用节点碰撞获取与受害者相同的域名接入节点。例如，如果托管平台的备选接入节点池规模较小，攻击者可能仅通过“申请-释放”众多账户的方式，就能实施节点碰撞策略。利用上述问题，攻击者可以在脆弱服务平台上申请接入任意用户域名，声称是该域名的所有者，从而使用该域名部署恶意服务。

在此威胁模型中，本文假设攻击者是使用公共云托管服务的任意租户，其可申请和撤销云平台提供的服务资源，并利用已分配给其他租户的服务域名来部署任意Web应用服务或提供文件资源，但其不具有控制受害者域名的权威服务器、污染DNS缓存或破解受害者云服务账号密码等能力。攻击者的目标是利用公共云平台的认证脆弱性，通过申请并控制受害租户曾经使用的云托管服务域名接入节点（Endpoint，包括IP地址、CNAME域名、NS服务器），来间接实现对风险域名的接管和操纵，利用该域名部署恶意资源，进而实施隐私泄漏、网站钓鱼和跨站请求伪造等攻击。

图5. 基于云托管服务的域名接管流程

3.2 攻击流程

假设云租户Alice曾经使用云平台的一项脆弱服务搭建Web应用网站，并通过图4中的流程接入自定义域名custom.alice.com。然而，当其购买的服务因过期等原因停用后，Alice并未及时清除其在权威域名服务器中配置的DNS资源记录，如图5所示。此时，一个恶意的云租户（攻击者）可以利用该脆弱服务接管Alice的域名，攻击流程如下： （1）攻击者申请向相同云平台接入域名custom.alice.com； （2）攻击者可以通过多次“申请－释放”云服务的方式，来实现服务域名碰撞；或通过自定义服务域名前缀的方式，申请与Alice相同的服务域名customalice.service.com； （3）攻击者声称自己为custom.alice.com的域名所有者。若云平台不检查随机挑战值（如TXT记录值）或未严格检查，则攻击者可绕过域名所有权验证过程； （4）云平台查询权威域名服务器，检测到该域名已经通过CNAME记录接入分配的服务域名； （5）云平台为域名custom.alice.com开启访问Web应用服务的权限，而对应的Web服务资源由攻击者部署管理，可能为钓鱼网站或其他恶意资源。

四、基于云服务的域名接管攻击检测系统

本文设计了一个针对基于云托管服务的域名接管攻击的高效检测系统HostingChecker（Hosting-based dangling domain checker），它包含两部分功能：（1）发现公共Web托管服务；（2）检测托管到脆弱服务的风险域名。

4.1 服务域名特征

为了挖掘尽可能多的公共Web托管服务，我们首先收集了以往博客、研究中披露的相关脆弱服务，发现这类服务在域名特征方面有一些共性： 1. 服务接入节点域名具有相似的命名规则。单一云平台的同类服务遵循统一的接入节点域名命名格式，如图6中蓝色后缀所示。本文将每个托管服务的最长公共节点域名后缀定义为节点域名后缀。

图6. 云托管服务的节点域名命名格式示例

2. 用户域名对接入节点域名有较高的依赖性。如果一个域名通过CNAME或NS解析至另一个域名，则可认为两个域名之间存在解析依赖关系。本文定义依赖于一个CNAME或NS域名的用户域名数量为域名依赖值（DN）。例如，图7中service.com的DN值为N。由于公共云托管服务商有成百上千个云租户，因此其服务域名模板将会被大量用户域名依赖，DNS解析数据表现为具有高域名依赖值。

图7. 域名依赖关系与域名依赖值示例

4.2 检测方案概述

HostingChecker的整体目标为：尽可能多地发现存在域名所有权和域名接入验证问题的公共云托管服务，即脆弱服务发现；在此基础上，针对互联网空间内大规模流行域名对脆弱服务的依赖关系与安全状态进行高效检测，即域名威胁状态检测。检测框架采用数据驱动的设计思路，其宏观架构如图8所示，主要包含脆弱服务发现模块和风险域名检测模块。这两个模块所依赖的数据源均为大规模的域名解析历史数据（Passive DNS）。

图8. 检测系统设计架构

I. 脆弱服务发现模块采用半自动化的方法，主要包含四个关键步骤：首先，根据域名依赖关系，从PassiveDNS数据集中识别出候选服务域名集合；其次，通过构建域名后缀树的方法，从候选服务域名集合中提取服务域名模板；随后，基于服务域名模板识别云服务类型，并通过人工检查对应服务域名验证策略的方式来识别脆弱服务，同时收集可标记服务状态的指纹特征；最后，利用确认的脆弱服务域名模板和指纹信息构建脆弱服务信息数据库，并将其用作域名威胁状态的判定基准。

II. 风险域名检测模块通过判断域名是否依赖于已停用的脆弱服务的方法来检测可接管域名，主要包含四个关键步骤：首先，根据域名访问的量化指标（即域名访问量），从PassiveDNS数据中为待测主域名列表收集子域名；其次，通过限制域名访问时间的方式，从数据集中提取子域名的相关活跃DNS资源记录，并为其高效地恢复域名解析链；随后，检查域名解析链是否匹配服务域名模板，以判定域名是否依赖于脆弱服务，并提取风险域名候选集合；最后，向候选域名发起主动扫描探测，检查其DNS和HTTP响应是否匹配预先获取的脆弱服务指纹，以判定被检测域名的可接管状态。

4.3 脆弱服务发现

根据云服务场景中的域名系统特性，理论上可以通过集中的域名依赖关系和统一的域名命名规则，从PDNS数据集中识别公共托管服务域名。然而，该过程存在三项技术难点：

挑战1：并非只有公共云服务存在此类DNS特性。一些大型组织（如谷歌、微软这类科技巨头）会自建负载均衡架构，其入口节点也会为自己的大量子域名提供内容分发等服务，它们的服务节点域名也可能有相似的后缀。

挑战2：难以通过简单的正则匹配和固定后缀长度截取的方式，提取不同服务的域名命名模板。由于不同云平台的服务域名命名规则有所差异，不同云服务的域名模板的标签数量不尽相同。此外，相同标签数量的域名后缀可能提供不同服务，例如s3.us-east-1.amazonaws.com和elb.us-east-2.amazonaws.com分别服务于Amazon S3和AWS Elastic Load Balancing两类服务。目前只有少数云平台（例如亚马逊云和阿里云）的服务域名命名模板可从官方文档和公共域名后缀列表中获得，但是大多数云平台的模板无法从官方渠道获取。

挑战3：公共域名后缀在一些随机域名中也很常见，而这类域名不属于提供公共云服务的节点域名，需要从服务域名候选列表中识别并剔除。例如，一些互联网应用服务（如搜索引擎、社交网络）会通过算法自动化生成大量一次性域名，并利用这些域名在不同网络或计算节点之间传递临时信号；从命名规则来看，一次性域名也含有公共后缀，表现出和云服务域名相似的格式特征。

对此，我们选择通过为域名定义量化评估指标的方式解决上述问题。

首先，各组织私有的负载均衡系统只为其自身管理和使用的域名提供服务，相对于为大规模用户域名提供服务的公共平台而言，私有服务节点的域名依赖值DN会有明显缩减。因此，通过设定的阈值下限的方式，可以比较有效地识别出公共托管服务的接入节点域名。

其次，我们设计了一种构建域名后缀树并逐级归并域名标签的方式，动态提取公共托管服务的域名后缀模板，以应对第二项挑战。

最后，被用于信号传输信道的域名均由固定算法生成，具有很高的随机性，量化表现为域名标签片段熵值高；并且由于其“即用即弃”的属性，通常只会被查询一次。因此，通过识别域名中的随机字符串标签和限制域名访问次数下限，可有效过滤一次性域名。

最终，我们从Passive DNS过滤出了可能为公共云托管服务的接入节点域名，基于网页信息、搜索引擎检索、域名WHOIS等多维信息来推断这些域名所属的云服务厂商，并通过人工验证的方式检测相关服务商在域名所有权验证环节是否存在漏洞。

4.4 风险域名检测

风险域名检测模块主要包括子域名采集、解析链恢复与域名威胁状态判定三个关键流程。为了及时且全面地检测整个互联网域名空间潜在的域名接管威胁，检测系统需要确保所收集子域名列表的完备性以及检测过程的高效性。

1. 基于访问活跃性的子域名采集

待测目标域名所有子域名的收集方法需要满足两项基本要求，即子域名资产覆盖率要尽可能完备，且应当具备快速发现新增子域名的能力。然而，检测系统收集子域名的过程具备较强挑战性。首先，大型组织（如亚马逊、微软）的子域名资产通常具有规模大、更新频率高的特点。其次，这类组织具有复杂的层次化授权结构，其业务应用的子域名也可能包含多级标签，例如region.console.aws.amazon.com，每级标签代表不同规模的逻辑架构。因此，对于大规模主域名而言，难以通过简单的暴力枚举法或DNS区域传输（Zone Transfer）的方法高效地穷举其子域名资产。

除此之外，对于检测云服务中的域名接管问题而言，待测目标域名集合应当具备广泛性，不能倾向于特定使用场景，故现有的开源数据集（如Censys HTTPS数据、CT证书数据、搜索引擎检索数据）不满足系统需求。为了平衡检测覆盖率和子域名枚举效率，检测系统利用DNS历史数据集来为待测目标域名收集被客户端真实访问过的子域名。

2. 基于 DNS 历史数据集的域名解析链恢复

在域名威胁检测过程中，我们需要获取待检测域名的所有解析链，通过将链中每个域名与服务域名模板匹配的方式，判断域名是否被托管到了公共云服务平台。如果云服务停用时平台返回不可访问的DNS响应资源（如将域名解析到127.0.0.1），检测系统将无法通过直接访问域名的方式获取到Web资源，从而检查HTTP指纹信息。因此，获取域名解析链是完成威胁状态检测的关键过程。

HostingChecker恢复域名解析链的具体方法如下。对待测域名列表中的每个FQDN，系统首先从PDNS中获取它的所有域名解析资源记录。而对其中的每条资源记录，如果类型为NS、CNAME或MX，则将其解析到的目标域名（rdata）加入待测域名列表，随后递归获取该“目标域名”的解析资源记录。通过此迭代查询过程，HostingChecker可以从PDNS的被动数据中恢复出待测域名的完整解析链。由于单个域名可能存在多条解析关系，域名之间也可能存在交叉依赖关系，因此实际上为每个FQDN可以构造出如图9中展示的解析依赖图。

图9. 域名解析依赖图

HostingChecker在恢复域名解析链时仅依赖于DNS历史数据库，因此可以在计算集群中并行完成数据检索和处理过程，无需发起主动的网络请求，具备高效性。但由于真实互联网流量中的DNS解析数据存在大量冗余信息，数据处理过程存在两项待解决的问题。首先，必须保证从PDNS中提取的DNS资源记录仍然处于存活状态，即可被解析访问。对此，HostingChecker利用资源记录日访问量来衡量一条DNS资源记录的活跃程度，并通过设置活跃度下限的方式排除掉网络攻击、扫描、一次性域名等数据。最终，系统将输出待测域名列表的活跃域名解析图集合。

3. 基于主动扫描的域名威胁状态检查

对于域名解析图集合中的每个图G，HostingChecker会从“初始顶点域名”出发，通过深度优先搜索（DFS）的方式遍历所有顶点，并将非顶点域名与预先收集的服务节点域名后缀列表中的每个后缀进行比较。若G中存在任意一个顶点d，且d与某一服务s的域名命名后缀模板匹配，则称“初始顶点域名”部署了服务s。

在判断服务依赖现状的基础上，HostingChecker会向所有已经部署云服务的域名列表发起主动DNS和HTTP请求，获取实时的指纹信息，并将其与脆弱服务停用状态相关的指纹进行对比。如果发现一条及以上匹配的指纹，则认为被检测的域名当前会受到域名接管威胁。最终，系统输出风险域名集合。

五、现实安全威胁评估

根据HostingChecker高效率和高覆盖率的特点，本文利用一年半的Passive DNS历史数据集，面向Tranco流行度排名前100万的域名实现安全检测，以评估互联网域名空间内由缺陷云服务导致的威胁规模。本节深入分析了脆弱服务和风险域名的主要特征，并分别评估了其现实影响，期望帮助安全社区及时发现并缓解相关安全问题。

5.1 公共托管服务安全风险分析

1. 脆弱服务概览

HostingChecker的脆弱服务发现模块可以辅助研究人员发现大量存在安全漏洞的公共云服务，主流云服务的相关策略实现具有多样性，但是普遍存在安全缺陷，容易造成广泛的安全影响。

如表1所示，HostingChecker共识别出52家知名云服务厂商（亚马逊、阿里等）的65种托管服务（云存储、CDN、Web托管等）存在域名所有权验证缺失等安全****脆弱性，可被利用于域名接管攻击。目前已经有10家厂商确认并修复了相关漏洞。

图10. 部分确认漏洞的厂商示例

表1. 主流云服务提供商及其脆弱服务示例

2. 可被利用的域名接入策略

此外，我们新发现了四种域名验证策略绕过方法，可导致Top 20的公共云托管服务均可被攻击者利用，致使2,927个用户域名受到劫持威胁。这四种威胁模型的如图11所示：

图11. 四种绕过域名所有权验证的威胁模型

V1：CNAME验证绕过。大多数云平台（18/20）会通过为每个租户分配唯一性CNAME服务域名组合的方式进行域名验证，但其中16家存在实现漏洞。如图11(V1)~中的威胁模型，云平台分配的CNAME域名（alice.rAnD0m.service.com）中间标签完全随机，但是该CNAME域名会被进一步解析到固定域名别名cname-fix.service.com。此时，如果存在一个用户域名在接入时直接将域名解析到该固定域名，云平台也认定其“通过”域名验证。这类服务的验证策略可以被攻击者利用。

**V2：TXT验证绕过**。让云租户为接入域名配置一条随机生成的TXT记录（包含随机挑战值）也是云平台的常用做法。例如，当租户尝试接入自定义域名customer.com时，知名CDN服务商Cloudflare会要求该租户为cloudflare-verify.customer.com配置一条TXT资源记录，随后再将用户域名解析到所分配的CNAME节点。但是测试结果表明，Cloudflare并未对TXT记录做严格校验，即只需成功配置CNAME记录便可通过验证。如图11(V2)~所示，攻击者可以利用这个安全漏洞，劫持任意解析到Cloudflare CNAME节点的用户域名。

**V3：IP验证绕过**。为每个云租户分配独立的IP地址或唯一性的IP组合，该方式理论上可以防止多租户复用服务节点。然而，一些云平台（例如WP Engine）的候选IP池规模过小，如图11(V3)~所示，攻击者可以通过有限次数的“申请－释放”过程便可申请到其他租户使用的IP组合，以绕过验证过程。

**V4：NS验证绕过**。与V3类似，云平台也可能会为租户分配唯一性NS组合，而候选NS池规模过小。一些云平台甚至不会检查租户所配置的NS服务器是否为平台为该租户唯一指定的组合，只要其配置的NS属于平台提供的NS资源池，即可通过验证。如图11(V4)，云平台要求租户将域名托管至NS_id1，但是如果租户将其权威域名服务器设置为NS_id2，也能通过云平台的校验。

3. 主流公共云托管服务安全现状

我们根据服务类型和服务流行度选取了20家主流云服务厂商进行深入研究（部分服务展示在表1中，详见论文），这些服务商占据约70%的市场份额，覆盖了我们发现的所有服务类型和域名接入方法。通过对每个服务的域名验证漏洞检测，我们发现V1-V4四种新型域名验证策略绕过方法可导致这20种服务全部受到威胁，致使2,927个用户域名面临劫持攻击威胁。

5.2 主流网站安全风险分析

为进一步研究云托管场景下域名接管问题的现实威胁规模，我们针对Tranco Top 1M主域名（apex domain）、9,808 个.edu和7,798 个.gov下的二级域名开展了大规模、持续性的测量研究，检测结果如表2所示。

表2. 受威胁的域名测量结果

1、风险域名概览

HostingChecker共为1,008,734个主域名收集到11,446,359个子域，并在2021年12月16日到2022年7月28日期间，针对这些子域名开展了101次测量实验。从大规模测量结果来看，受云服务域名验证脆弱性影响的用户域名广泛存在。在已收集的子域名数据中，有284,006（2.5%）个域名曾经部署过公共云服务，其中40.2%的域名托管于脆弱服务。通过探测服务指纹，HostingChecker最终检测出了10,351个可被攻击者接管劫持的用户域名（下文简称为“风险域名”）。

图12. 风险域名及相关脆弱服务示例（PoC）

这些风险域名中包括很多重要领域的网站（如图12所示）。例如，我们发现有23个可接管的教育网站（.edu）域名被托管在Webflow、AWS Elastic Beanstalk和Pantheon这些建站平台中。其中有两个分别属于unc.edu和rice.edu的子域名的威胁状态持续了近三个月，这意味着若高校的子域名资源记录未经妥善管理，很容易被攻击者通过第三方云服务劫持利用。除此之外，还有一些大型公司和政府网站会受到影响，包括百度、华为、万豪、美国国立卫生研究院（NIH）的子域名。

从Tranco域名流行度排名来看，流行度高的域名更容易受到威胁，具体有两方面原因：第一，大型组织的网站流行度排名通常较高，且由于其业务具有多样性和复杂性，这些组织会创建大量子域名，导致子域名资产管理具有挑战性。第二，流行网站更倾向于将子域名托管至第三方平台，通过云服务来提高网站的安全性和可靠性。然而其选择的云服务可能存在域名验证缺陷，反而使其域名更易受到劫持攻击。

间接风险域名及其威胁规模 除了云服务的用户域名之外，我们发现一些托管平台的安全漏洞也可危及未部署云服务的域名。如果域名A依赖于托管在云服务的域名B，而后者使用了存在安全漏洞的托管服务，那么攻击者可以在接管域名B之后间接控制A。我们通过Passive DNS反向查询，共检测到18,253个类似于A的“间接风险域名”。这种域名依赖关系会使云服务漏洞导致的威胁规模扩大化，且因间接风险域名自身并未部署云服务，难以被域名所有者及时检测发现。

风险域名生命周期 经过长时间的威胁检测，本文发现可利用云服务接管的风险域名不断出现且持续存在。例如，在图13展示的周期性检测结果中，平均每周有270个新增的风险域名。

图13. 每周风险域名检测结果变化趋势

经过为期半年的上百轮检测实验，我们为风险域名绘制出了如图14所示的完整生命周期。我们将𝛿𝑣𝑢𝑙=𝑇𝑒-𝑇𝑠定义为一个域名的威胁时间区间。通过统计风险域名生命周期，我们发现域名接管威胁可以持续很长时间。只有17%的风险域名很快得到了修复，而近60%的风险域名持续5天以上，甚至有36.3%持续存在超过一个月。这意味着域名所有者很难及时发现威胁存在，并采取主动措施来消除威胁，这将给攻击者留下很长的攻击时间窗口。

图14. 风险域名生命周期

4. 风险域名生命周期

作为进一步补充分析，本文尝试量化评估风险域名造成的现实安全影响，即通过Passive DNS数据集来统计所有风险域名在威胁时间区间内影响的客户端IP地址数量和域名访问量。统计结果表明，尽管云租户使用的目标服务已被停用，有45.5%的风险域名仍然会在威胁区间内持续收到来自超过7,000万客户端IP地址的域名查询流量。其中，有43个风险域名影响了数百万甚至数千万的客户，有364个被访问了至少100万次。这意味着一旦相应域名被攻击者接管控制，将有大量客户端会受到钓鱼欺骗、隐私泄露等攻击威胁，这进一步表明对云服务引入的域名接管威胁开展及时且高效的检测具有必要性。

六、安全实践建议

1. 公共云托管平台需要严格遵循标准化的域名所有权验证规则，包括但不限于使用DNS TXT记录验证用户的域名所有者身份（具体过程可参考阿里云CDN的验证过程）。若公共托管平台必须选择通过固定NS/CNAME域名池来提供域名所有权验证，则必须保障为不同用户分配域名组合的完全随机性，防止发生NS/CNAME碰撞（具体过程可参考Cloudflare CDN厂商的域名所有权验证逻辑。）
2. 公共云托管平台需要保存所有用户的部署信息，严格记录分配给每个用户的服务节点域名，执行账号冲突检查。若CNAME域名允许用户自定义前缀，则需严格避免不同用户申请注册相同域名前缀。若不同用户账号申请部署相同域名，则需发出“账号信息冲突”等警示信息，待用户账号通过域名所有权验证之后再为其提供域名托管服务。
3. 用户自身需要谨慎管理域名的资源记录，定期删除不使用的资源记录（dangling DNS records），防止攻击者有机可乘。但由于并非所有资源记录都为域名所有者管理或配置，所以还需公共云托管平台严格实现验证措施，为整个云社区提供相对安全的服务环境。
4. 若有更加安全可行的实践方案，可与作者联系，共同交流讨论。