最近在HackerOne上看到了几个子域名接管方面的漏洞，几个漏洞都可以轻松就对子域获得控制权，并且获得了来自企业的高额奖金。在国外看到了这篇文章，粗略翻译了下，也顺便围绕这个话题说说吧，相关漏洞案例可以去H1搜索“subdomain takeover”查看。
子域名接管漏洞通常被滥用于以下几个目的：恶意软件分发、网络钓鱼/鱼叉式网络钓鱼、XSS 、身份验证绕过等等。由于某些证书颁发机构仅需要域验证，因此也可以轻松生成SSL证书。
子域名接管是注册不存在的域名以获得对另一个域的控制权的过程。此过程最常见的情况如下：
域名（例如，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子域接管的主要类型之一是叫做互联网常规域名的规范域，而不是云服务商拥有的域名的情况，如下所述。检测某些源域名是否容易受到CNAME子域名接管的过程非常简单：
给定一对源域名和规范域名，如果规范域名的基本域可供注册，则源域名容易被子域接管。
这个过程中值得注意的事情是，规范域名的基本域。这是因为规范域名可能是更高级别的域名。如果基础域可用于注册，高级域名可以很容易地在DNS区域中重新创建。
使用域名注册商（如Namecheap）可以检查基础域名的可用性。有人可能认为测试NXDOMAIN的DNS响应状态足以表明域名可用于注册。但请注意，情况并非如此，因为存在域名以NXDOMAIN响应但无法注册的情况。原因包括TLD注册商限制的顶级域名（例如.GOV，.MIL）或保留域。
NS子域名接管。子域名接管的概念可以自然地扩展到NS记录：如果至少一个NS记录的规范域名的基本域可用于注册，则源域名易受子域名接管的影响。
使用NS记录而产生子域名接管漏洞中的一个问题是源域名通常具有多个NS记录。多个NS记录用于冗余和负载平衡。在DNS解析之前随机选择名称服务器。假设域sub.example.com有两个NS记录：ns.vulnerable.com和ns.nonvulnerable.com。如果攻击者接管了ns.vulnerable.com，则从查询sub.example.com的用户的角度来看，情况如下：
由于有两个名称服务器，因此随机选择一个。这意味着查询攻击者控制的名称服务器的概率为50％。
如果用户的DNS解析程序选择ns.nonvulnerable.com（合法名称服务器），则返回正确的结果，并且可能会在6到24小时之间缓存。
如果用户的DNS解析器选择ns.vulnerable.com（攻击者拥有的名称服务器），则攻击者可能会提供错误的结果，该结果也将被缓存。比如，由于攻击者控制着名称服务器，因此她可以将此特定结果的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记录 - 使用此方法，“重定向”在DNS解析期间发生。组织设置CNAME记录，并且所有流量都自动委托给云提供商。使用此方法，用户浏览器中的URL保持不变。但是需要注意是是，云服务必须支持使用CNAME记录的委派。
如果使用CNAME记录方法，子域名接管的可能性就会发挥作用。即使云提供商拥有规范域名的基本域，仍然可以进行子域接管，如下面所述。
普遍性 - 基于CNAME记录的统计信息，优先考虑CNAME记录中使用率最高的云提供商域。
支持CNAME记录 - 如上所述，云提供商需要支持CNAME委派。云提供商意识到客户要求此类行为，而最受欢迎的云提供商已经支持此行为。
域所有权验证 - 所选的云提供商未验证源域名的所有权。由于所有者不需要经过验证，因此任何人都可以使用过期的云配置来实现子域名接管。
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记录来实现。虽然亚马逊没有提供有关内部CloudFront概念的文档，但可以从其行为中扣除高级体系结构。根据地理位置，对cloudfront.net的任何子域的DNS查询会导致相同的A记录（在同一区域中）。这表明CloudFront正在后端使用虚拟主机设置。HTTP请求到达后，CloudFront的边缘服务器根据HTTP 主机头确定正确的分发。文档也支持这一理论，因为它表明：如果备用域名已存在于另一个CloudFront分配中，则无法将备用域名添加到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分配中已存在的备用域名后显示的错误。
如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项目进行免费的虚拟主机托管。此Web托管通常用于项目的文档，技术博客或支持Web页面到开源项目。除github.io下的默认域名外，GitHub Pages还支持自定义域名。
Microsoft Azure - Microsoft Azure是一个更加突出的云提供商，类似于AWS。与上面提到的云服务相比，它不同，因为它不提供虚拟主机架构。简而言之，对于每个云服务，Azure都会创建自己的具有自己IP地址的虚拟机。因此，域名和IP地址之间的映射是明确的（一对一映射）。值得注意的是，由于这不是常规虚拟主机设置，因此不一定必须在资源设置中明确定义配置CNAME记录。Azure提供多种云服务，但本文中讨论的云服务具有cloudapp.net和azurewebsites.net的默认域。其文档描述了使用A或CNAME记录设置域名和Azure资源之间的链接（指向前面提到的两个域之一）。一个有趣的观察是，对于A记录，Azure使用TXT记录进行域所有权验证。但是，对于CNAME记录而言并非如此，因此即使在Microsoft Azure的情况下也可以进行子域接管。
Sonar项目可用于显示互联网上子域名接管的普遍程度。由于Project Sonar已经包含已解析的CNAME记录，因此通过Internet自动扫描子域接管非常简单。本节介绍其结果。
CNAME记录链。在某些情况下，CNAME记录可能会形成CNAME记录链。让我们域sub.example.com具有CNAME记录sub.example1.com。如果反过来，sub.example1.com有一个到sub.example2.com的CNAME记录，则会形成一个三向链：
sub.example.com -> sub.example1.com -> sub.example2.com
在这种情况下，当链（example2.com）中的最后一个域的基本域可用于注册时，sub.example1.com和sub.example.com都会受到影响。幸运的是，Project Sonar隐含地包含链中的所有CNAME引用。对于上面给出的链，即使从sub.example.com到sub.example2.com没有直接的CNAME记录，Project Sonar也包含此记录。因此，不需要对自动化工具进行直接更改以支持Project Sonar中的CNAME记录链。
扫描云提供商域，发现12,888个源域名易受子域名接管（2017年11月）。
云提供商分发如下：
翻译自：https://0xpatrik.com/subdomain-takeover-basics
原文作者：@Patrik / 翻译：@仓鼠
注明：翻译时进行了适当删减与更改，转载请注明，感谢。
本文作者：仓鼠
本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/94973.html
必填 您当前尚未登录。 登录？ 注册
必填（保密）