Subdomain Takeover 子域名接管漏洞

本文翻译Patrik Hudak 的文章，以及推荐一下55开写的子域名接管自动化工具！！！YYDS

这篇文章旨在深入说明整个子域接管问题

介绍：

子域接管是注册不存在的域名以获得对另一个域的控制权的过程。此过程最常见的情况如下：

• 域名（例如，sub.example.com）将CNAME记录用于另一个域（例如，sub.example.com CNAME anotherdomain.com）。

• 在某个时间点，anotherdomain.com到期，任何人都可以注册。

• 由于不会从example.com DNS区域删除CNAME记录，因此注册anotherdomain.com的任何人都可以完全控制sub.example.com，直到存在DNS记录为止。

子域接管的含义可能非常重要。通过使用子域接管，攻击者可以从合法域中发送网络钓鱼电子邮件，执行跨站点脚本（XSS）或破坏与该域相关联的品牌的声誉。您可以在下一篇（明天发）文章中了解有关隐含（风险）的更多信息。

子域接管不仅限于CNAME记录。NS，MX甚至A记录（均不受此限制）也将受到影响。这篇文章主要涉及CNAME记录。但是，在需要的地方会提供NS和MX记录的用例。

常规域名

使用CNAME记录的DNS委托对用户完全透明，即在DNS解析过程中它在后台发生。下图说明了具有CNAME记录的域名的Web浏览器的行为。

请注意，Web浏览器隐含地将信任关系传递给DNS解析程序返回的任何内容。这种信任意味着，当攻击者获得对DNS记录的控制权时，将绕过所有Web浏览器安全性度量（例如，同源策略）。由于子域接管破坏了域的真实性，攻击者可以通过几种方式利用该域的真实性，这带来了相当大的安全威胁。稍后将显示，TLS / SSL无法解决此问题，因为子域接管不是常规的中间人式攻击。

CNAME子域接管。CNAME子域接管的主要类型之一是规范域名是常规Internet域名（不是云提供商拥有的一个域名，下面将对此进行说明）的情况。检测某些源域名是否易受CNAME子域接管的过程非常简单：

给定一对源域名和规范域名，如果可以使用规范域名的基本域进行注册，则源域名容易受到子域接管。

在此过程中，值得注意的是，“规范域名的基本域名”。这是因为规范域名可能采用更高级别的域名形式。如果可以注册基本域名，就DNS区域中轻松地重新创建高级域名

使用NS记录进行子域接管的问题之一是源域名通常具有多个NS记录。多个NS记录用于冗余和负载平衡。name Server 是在DNS解析之前随机选择的。假设域sub.example.com具有两个NS记录：ns.vulnerable.com和ns.nonvulnerable.com。 如果攻击者接管了ns.vulnerable.com，从查询sub.example.com的用户的角度来看，情况如下：

• 由于有两个name Server，因此会随机选择一个。这意味着查询由攻击者控制的name Server的可能性为50％。

• 如果用户的DNS解析器选择ns.nonvulnerable.com（合法的name Server），则会返回正确的结果，并且可能会在6到24小时之间进行缓存。

• 如果用户的DNS解析器选择ns.vulnerable.com（攻击者拥有的name Server），则攻击者可能会提供错误的结果，该结果也将被缓存。由于攻击者控制着name Server，因此她可以为此特定结果将TTL设置为一周。

MX子域接管。与NS和CNAME子域接管相比，MX子域接管影响最小。由于MX记录仅用于接收电子邮件，因此，获得对MX记录中规范域名的控制权仅使攻击者能够接收发送到源域名的电子邮件。尽管影响不如CNAME或NS子域接管大，但MX子域接管可能在鱼叉式网络钓鱼攻击和知识产权窃取中起作用。

云提供商

近年来，云服务越来越受欢迎。云的基本前提之一是减轻其用户设置基础架构的负担。组织正在从本地设置切换到替代方案，例如云存储，云中的电子商务和平台即服务等。

用户创建新的云服务后，在大多数情况下，云提供商会生成一个唯一的域名，该域名用于访问创建的资源。由于大量的云服务客户，通过TLD注册服务商注册域名不是很方便，因此云提供商选择使用子域。标识唯一云资源的子域通常采用name-of-customer.cloudprovider.com的格式，其中cloudprovider.com是特定云提供商所拥有的基本域。

如果某个组织注册的云服务是公开的（例如，电子商务商店），则特定组织可能希望将其作为其域的一部分提供。其背后的主要原因是品牌塑造：shop.organization.com看起来比organization.ecommerceprovider.com更好。在这种情况下，组织有两个选择：

• HTTP 301/302重定向-301和302是HTTP响应代码，它们触发Web浏览器将当前URL重定向到另一个URL。在云服务的上下文中，第一个请求是针对组织的域名（例如shop.organization.com），然后重定向到云提供商的域名（例如，organization.ecommerceprovider.com）。

• CNAME记录—使用此方法，“ , redirect”在DNS解析期间发生。组织设置CNAME记录，所有流量自动委派给云提供商。使用此方法，用户浏览器中的URL保持不变。特定的云服务必须支持使用CNAME记录的委派。

如果使用CNAME记录方法，则可能发生子域接管。即使云提供商拥有规范域名的基本域，仍可以进行子域接管，具体如下：

• 普遍性 - 基于CNAME记录的统计信息，优先考虑CNAME记录中使用率最高的云提供商域。

• 支持CNAME记录 - 如上所述，云提供商需要支持CNAME委派。云提供商意识到客户要求此类行为，而最受欢迎的云提供商已经支持此行为。

• 域所有权验证 - 所选的云提供商未验证源域名的所有权。由于所有者不需要经过验证，因此任何人都可以使用过期的云配置来实现子域名接管。

Amazon CloudFront

Amazon CloudFront是Amazon Web Services（AWS）中的内容交付网络（CDN）。CDN将Web内容的副本分发到位于不同地理位置（称为存在点）的服务器。当用户向CDN发出请求时，将根据访问者的位置选择最近的存在点，以降低延迟。组织使用CDN，主要用于分发媒体文件，例如视频，音频和图像。CDN的其他优点包括拒绝服务攻击防护，减少带宽和在流量高峰时进行负载平衡。

CloudFront使用Amazon S3作为Web内容的主要来源。Amazon S3是AWS提供的另一项服务。它是一种云存储服务（S3是Simple Storage Service的缩写），允许用户将文件上传到所谓的存储桶中，这是S3中逻辑组的名称。

CloudFront使用发行版的概念。每个分发都是指向特定Amazon S3存储桶的链接，以从中提供对象（文件）。创建新的CloudFront分配后，将生成一个唯一的子域来提供访问权限。该子域的格式为SUBDOMAIN.cloudfront.net。SUBDOMAIN部件是由CloudFront制作的，不能由用户指定。

除了随机生成的子域之外，CloudFront还可以指定用于访问发行版的备用域名。通过创建从备用域名到CloudFront生成的子域的CNAME记录来实现。尽管Amazon不提供有关内部CloudFront概念的文档，但是可以从其行为中推断出高级架构。根据地理位置，对cloudfront.net的任何子域的DNS查询将导致相同的A记录（在相同区域中）。这表明CloudFront正在后端使用虚拟主机设置。HTTP请求到达后，CloudFront的边缘服务器会根据HTTP Host标头确定正确的分发。文档还支持该理论，因为该理论指出：即使另一个AWS Cloud分配中已经存在另一个域名，也无法将另一个域名添加到CloudFront分配中，即使您的AWS账户拥有另一个分配“”。具有指向一个分布的多个备用域是正确的，但是，在多个分布中存在相同的备用域名却不正确。

因此，为了正确处理备用域名，CloudFront需要事先知道备用域名附加到哪个发行版。换句话说，仅配置CNAME记录是不够的，需要在分发设置中显式设置备用域名。

CloudFront中备用域名的问题与“常规域”部分中说明的问题相似。假设sub.example.com的CNAME记录设置为d1231731281.cloudfront.net。如果在CloudFront发行版中没有注册sub.example.com作为备用域名，则可以进行子域接管。任何人都可以创建一个新的发行版，并将sub.example.com设置为备用域名。但是请注意，新创建的CloudFront子域不需要与CNAME记录（d1231731281.cloudfront.net）中指定的子域匹配。由于CloudFront使用虚拟主机设置，因此使用HTTP主机标头而非DNS记录确定正确的分配。

下图显示了HTTP请求后到备用域名的错误消息，该备用域名具有到CloudFront的DNS CNAME记录，但未在任何CloudFront发行版中注册。

此错误消息是对子域接管可能性的明确指示。但是，需要考虑两个例外：

• 仅HTTP / HTTPS分发-CloudFront允许指定分发是仅HTTP还是仅HTTPS。将HTTP切换为HTTPS可能会为某些发行版提供正确的响应。

• 禁用的分发-某些分发可能已禁用。禁用的分发不再继续有效地提供内容，同时仍保留其设置。这意味着某些备用域名可能在HTTP请求后引发错误消息。但是，它甚至已在禁用的分发中注册，因此不容易受到子域接管。确定替代域名是否已在某个分发中注册的正确方法是创建新的分发并设置替代域名。如果注册过程没有引发错误，则自定义域很容易受到子域接管。下面的屏幕快照显示了用户尝试注册其他某些CloudFront发行版中已经存在的备用域名后出现的错误。

Other

如CloudFront所示，即使没有基域可用于注册的云服务，也可以进行子域接管。但是，由于云服务提供了一种指定备用域名（CNAME记录）的方式，因此仍然存在子域接管的可能性。本节提供了与CloudFront（虚拟主机架构）非常相似的其他云服务的快速概述。