本文翻译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（虚拟主机架构）非常相似的其他云服务的快速概述。
- Amazon S3 —先前曾简要提到过Amazon S3。用于访问存储桶的默认基本域并不总是相同，并且取决于所使用的AWS区域。AWS文档中提供了Amazon S3基本域的完整列表。与CloudFront相似，Amazon S3允许指定备用（自定义）域名来访问存储桶的内容。
- Heroku — Heroku是一个平台即服务的提供程序，可以使用简单的工作流来部署应用程序。由于需要访问该应用程序，因此Heroku使用在herokuapp.com上形成的子域公开该应用程序。但是，也可以指定自定义域名来访问已部署的应用程序。
- Shopify-Shopify提供了一种在云中创建和自定义电子商务商店的方法。访问商店的默认子域建立在myshopify.com上。如前所述，Shopify允许指定备用域名。值得注意的是，Shopify会验证正确的CNAME记录配置。但是，此验证不是域所有权验证。Shopify仅检查备用域的DNS区域中是否存在正确的CNAME记录。因此，此验证不会阻止子域接管。
- GitHub-GitHub是Git的版本控制存储库。GitHub还允许使用其GitHub Pages项目进行免费的虚拟主机。该虚拟主机通常用于项目的文档，技术博客或开源项目的支持网页。GitHub Pages除了github.io下的默认域名外，还支持自定义域名。
- Microsoft Azure – Microsoft Azure是更杰出的云提供商，类似于AWS。与上面提到的云服务相比，它的不同之处在于它不提供虚拟托管架构。简而言之，对于每个云服务，Azure都会使用自己的IP地址创建自己的虚拟机。因此，域名和IP地址之间的映射是明确的（一对一映射）。值得注意的是，由于这不是常规的虚拟主机设置，因此不一定必须在资源设置中明确定义配置CNAME记录。Azure提供了多种云服务，但本文中讨论的服务具有默认域cloudapp.net和azurewebsites.net。其文档描述了使用A或CNAME记录（指向前面提到的两个域之一）设置域名和Azure资源之间的链接。有趣的发现是，对于A记录，Azure使用TXT记录进行域所有权验证。但是，CNAME记录不是这种情况，因此即使在Microsoft Azure的情况下，也可以进行子域接管。
对于受影响的云提供商的扩展列表，我强烈建议大家学习https://github.com/EdOverflow/can-i-take-over-xyz
Internet-wide Scan
Sonar（https://0xpatrik.com/project-sonar-guide/） 用于显示Internet上子域接管的普遍性。由于Sonar项目已经包含已解析的CNAME记录，因此通过Internet自动扫描子域接管非常简单。本节说明其结果。
CNAME记录链。在某些情况下，CNAME记录可能会形成CNAME记录链。让我们来看看sub.example.com这个域名，它有一个CNAME记录到sub.example1.com。 如果依次将sub.example1.com的CNAME记录发送到sub.example2.com，则会形成三方链：
sub.example.com -> sub.example1.com -> sub.example2.com
在这种情况下，当链中最后一个域的基本域（example2.com）可用于注册时，sub.example1.com和sub.example.com都会受到影响。幸运的是，Sonar项目隐式包含了链中的所有CNAME引用。对于上面给出的链，即使没有从sub.example.com到sub.example2.com的直接CNAME记录，Project Sonar仍包含该记录。因此，无需对自动化工具进行直接更改即可支持Project Sonar中的CNAME记录链。
扫描是使用自定义的自动化工具执行的，作者不打算发布这个工具
但是我来发 https://github.com/Echocipher/Subdomain-Takeover 来自五五开的子域名接管工具
