什么是子域名接管漏洞?

什么是子域名接管漏洞?

前言

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

  1. 域名(例如http://sub.example.com)将CNAME记录[1]用于另一个域(例如http://sub.example.com CNAME anotherdomain.com)。
  2. 在某个时间点,anotherdomain.com到期,任何人都可以注册。
  3. 由于不会从 http://example.com DNS区域删除CNAME记录,因此注册 anotherdomain.com 域名的任何人都可以完全控制http://sub.example.com,直到存在DNS记录为止。

子域接管的含义非常重要。通过使用子域名托管,攻击者可以从合法的域名发送网络钓鱼电子邮件,执行跨站脚本(XSS)或破坏与该域相关联的品牌的声誉。您可以在我的其他文章中了解有关隐含(风险)[2]的更多信息。

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

常规域名

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

请注意,Web浏览器无保留地信任DNS解析程序返回的任何内容。这种信任意味着,当攻击者获得对DNS记录的控制权时,将绕过所有Web浏览器安全性度量(例如,同源策略[3])。由于子域接管破坏了域的真实性,攻击者可以通过多种方式利用该域的真实性,因此这带来了相当大的安全威胁。TLS / SSL也无法解决此问题,因为子域名接管不是常规的中间人式攻击。

CNAME子域接管

CNAME子域接管的主要类型之一是规范域名,常规的Internet域(指非云提供商拥有的一个域名)的情况。检测某些源域名是否易受CNAME子域接管的过程非常简单:

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

在此过程中值得注意的是“规范域名的基本域”。这是因为规范域名可能采用更高级别的域的形式。如果基本域名可以被注册,那么之后在DNS区域里更高级别的域名也能被轻松再创建.

可以使用域名注册商(例如Namecheap)来检查基本域名的可用性。有的人认为测试NXDOMAIN的DNS 响应状态足以表明该域名是否可供注册。但是事实上并非如此,因为在某些情况下域名会以 NXDOMAIN 响应,但无法注册。原因主要是受限制的顶级域名(例如.GOV,.MIL)或TLD注册服务商保留的域名 。

NS子域接管

子域接管的概念可以自然地扩展到NS记录:如果至少一个NS记录的规范域名的基础域可用于注册,则源域名也会容易受到子域接管的影响。

使用NS记录进行子域接管的问题之一就是源域名通常具有多个NS记录,多个NS记录用于冗余和负载平衡。假设域 http://sub.example.com具有两个NS记录:

  1. ns.vulnerable.com
  2. ns.nonvul​​nerable.com

如果攻击者接管了ns.vulnerable.com,那么从查询http://sub.example.com的用户的角度来看,有以下三种情况:

  1. 由于有两条记录,因此随机选择一个。这意味着查询由攻击者控制的服务器名称的可能性为50%。
  2. 如果用户的DNS解析器选择ns.nonvul​​nerable.com(合法的名称服务器),则会返回正确的结果,并且可能会在6到24小时之间进行缓存。
  3. 如果用户的DNS解析器选择ns.vulnerable.com(攻击者拥有的名称服务器),则攻击者可能会提供错误的结果,该结果也将被缓存。由于攻击者控制着名称服务器,因此她可以对特定结果进行TTL设置,例如一周。

MX子域接管。

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

云提供商

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

用户创建了新的云服务后,大多数情况下,云提供商会生成一个唯一的域名,该域名用于访问创建的资源。由于大量的云服务客户,通过TLD注册服务商注册域名不是很方便,因此云提供商会选择使用子域。

标识唯一云资源的子域通常采用name-of-customer.cloudprovider.com的格式,其中cloudprovider.com是特定云提供商所拥有的基本域。

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

  • HTTP重定向301/302 - 301302是HTTP触发web浏览器到当前URL重定向到另一个URL响应代码。在云服务的上下文中,第一个请求是对组织的域名(例如,shop.organization.com)进行的,然后重定向到云提供商的域名(例如,organization.ecommerceprovider.com)。
  • CNAME记录 —使用此方法,“ redirect”在DNS解析期间发生。组织设置CNAME记录,所有流量自动委派给云提供商。使用此方法,用户浏览器中的URL保持不变。但是请注意特定的云服务必须支持使用CNAME记录的委派。

如果使用CNAME记录方法,则可能发生子域接管。即使云提供商拥有规范域名的基本域,也可以进行子域接管,如以下小节所述。

据统计,以下三个原因是云提供商发生子域名接管的常见原因。

  • 流行度 -基于CNAME记录的统计信息,对CNAME记录中使用率最高的云提供商域进行了优先级排序。
  • 支持CNAME记录 —如上所述,云提供商需要支持CNAME委派。云提供商意识到客户要求这种行为,并且最受欢迎的云提供商已经支持了这种行为。
  • 域名所有权验证 -所选的云提供商未在验证源域名的所有权。由于不需要证明所有者,因此任何人都可以使用过期的云配置来实现子域接管。

根据这三个原因下文我将对各个云服务展开风险分析。

亚马逊CloudFront

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

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

CloudFront遵循发行版的概念。每个分发都是指向特定Amazon S3存储桶的链接,以从中获取对象(文件)。创建新的CloudFront分配后,将生成一个唯一的子域来提供访问权限。该子域的格式为SUBDOMAIN.cloudfront.net 。上述SUBDOMAIN部分由CloudFront的产生,并且不能由用户来指定。那么除了随机生成的子域外,CloudFront还可以指定用于访问发行版的备用域名。通过创建从备用域名到CloudFront生成的子域的CNAME记录来实现获取内容的访问。

尽管Amazon不提供有关内部CloudFront概念的文档,但是可以从其行为中推断出高级架构。根据地理位置,对cloudfront.net任何子域的DNS查询会导致相同的A记录(在相同区域中)。这表明CloudFront正在后端使用虚拟主机设置。HTTP请求到达后,CloudFront的边缘服务器会根据HTTP Host 标头确定正确的分发。

其使用文档中指出:

当备用域名已经存在于另一个CloudFront分配中时,您无法将备用域名添加到另外的CloudFront分配中,即使您的AWS账户拥有另一个分配也是如此

所以我们可以发现,一个"分配"可以同时拥有多个备用域名,但是在多个"分配"中存在相同的备用域名,这样就会报错。

图片展示了CloudFront 边缘服务器的大致工作流程

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

CloudFront中备用域名的问题类似于“ 常规域”部分中说明的问题。假设http://sub.example.com 的CNAME记录设置为d1231731281.cloudfront.net 。如果在CloudFront发行版中没有注册 http://sub.example.com 作为备用域名,则可以进行子域接管。任何人都可以创建一个新的发行版,并将http://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是一个SAAS(平台即服务)的提供程序,它允许使用简单的工作流来部署应用程序。由于需要访问该应用程序,因此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的情况下也可以进行子域接管。

全互联网扫描

Sonar项目[4]可用于显示Internet上子域接管的普遍性。由于Sonar项目已经包含已解析的CNAME记录,因此通过Internet自动扫描子域接管非常简单。本节说明其结果。

CNAME记录链。在某些情况下,CNAME记录可能形成CNAME记录链。让我们来看看http://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.comhttp://sub.example.com都会受到影响。幸运的是,Sonar项目默认包含了链中的所有CNAME引用。对于上面给出的链,即使没有从http://sub.example.comsub.example2.com直接CNAME记录,Project Sonar仍包含该记录。因此,无需对自动化工具进行多余配置即可支持Project Sonar中的CNAME记录链。

扫描是使用自定义自动化工具执行的,该工具尚不打算发布。该工具能够扫描云提供商域,并发现12888个源域名易受子域接管(2017年11月)。云提供商的分发如下:

这篇文章的某些部分摘录自我的硕士论文[5]

文章来自:0xpatrik.com/subdomain-

文章翻译有不当之处,还请多多指出~

今天的内容就分享到这里,希望对你有所帮助。最近二向箔安全推出了漏洞挖掘实战班,小白入门到挖洞大佬,如果你也想学习漏洞挖掘并获得一定的报酬奖励,现在马上扫码上车。

参考

  1. ^CNAM记录也被称为规范名字。这种记录允许您将多个名字映射到同一台计算机。 通常用于同时提供WWW和MAIL服务的计算机。例如,有一台计算机名为“host”(A记录)。 它同时提供WWW和MAIL服务,为了便于用户访问服务。可以为该计算机设置两个别名(CNAME):WWW和MAIL。 这两个别名的全称就是www开头的域名和以mail开头的域名。实际上他们都指向“host”。 同样的方法可以用于当您拥有多个域名需要指向同一服务器IP,此时您就可以将一个域名做A记录指向服务器IP然后将其他的域名做别名到之前做A记录的域名上,那么当您的服务器IP地址变更时您就可以不必麻烦的一个一个域名更改指向了 只需要更改做A记录的那个域名其他做别名,那些域名的指向也将自动更改到新的IP地址上了。
  2. ^Subdomain Takeover: Thoughts on Risks: https://0xpatrik.com/subdomain-takeover/
  3. ^同源策略: https://en.wikipedia.org/wiki/Same-origin_policy
  4. ^Sonar项目: https://0xpatrik.com/project-sonar-guide/
  5. ^硕士论文: https://is.muni.cz/th/byrdn/Thesis.pdf
编辑于 05-08

文章被以下专栏收录