Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-29 08:01:00 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/domain-subdomain-takeover.md
Translator workflow a21a0e7217 Translated to Chinese
2023-08-03 19:12:22 +00:00

21 KiB
Raw Blame History

域名/子域名劫持

☁️ HackTricks云 ☁️ -🐦 推特 🐦 - 🎙️ Twitch 🎙️ - 🎥 YouTube 🎥


使用Trickest可以轻松构建和自动化工作流程，使用全球最先进的社区工具。
立即获取访问权限：

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

域名劫持

如果你发现某个域名（domain.tld）被某个服务在范围内使用，但公司已经失去了对它的所有权，你可以尝试注册它（如果便宜的话），并让公司知道。如果该域名通过GET参数或Referer头部接收到一些敏感信息，那么这肯定是一个漏洞。

子域名劫持

公司的一个子域名指向一个未注册的第三方服务。如果你可以在这个第三方服务中创建一个账户并注册正在使用的名称，你就可以进行子域名劫持。

有几个工具带有字典，用于检查可能的劫持：

使用BBOT扫描可劫持的子域名：

BBOT的默认子域名枚举中包含子域名劫持检查。签名直接从https://github.com/EdOverflow/can-i-take-over-xyz获取。

bbot -t evilcorp.com -f subdomain-enum

通过DNS通配符生成子域名劫持

当域名使用DNS通配符时，该域名的任何请求的子域名，如果没有明确指定不同的地址，将被解析为相同的信息。这可以是一个A IP地址，一个CNAME...

例如，如果*.testing.com被通配为1.1.1.1。那么，not-existent.testing.com将指向1.1.1.1。

然而，如果系统管理员将其指向一个通过CNAME的第三方服务，比如一个github子域名（sohomdatta1.github.io）。攻击者可以创建自己的第三方页面（在这种情况下是在Gihub上），并声称something.testing.com指向那里。因为CNAME通配符会同意，攻击者将能够为受害者的域名生成任意子域名并指向自己的页面。

你可以在CTF的写作中找到这个漏洞的例子：https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api

利用子域接管

此信息来源于 https://0xpatrik.com/subdomain-takeover/

最近，我写了一篇文章介绍了子域接管的基础知识。尽管这个概念现在已经被广泛理解，但我注意到人们通常很难理解子域接管带来的风险。在这篇文章中，我将深入探讨我个人认为的子域接管的最显著风险。

注意：一些风险在云提供商隐式地得到了缓解。例如，当Amazon CloudFront上存在子域接管的可能性时，您无法设置TXT记录来绕过SPF检查。因此，本文旨在提供关于一般子域接管的风险。然而，其中大部分也适用于云提供商。

对浏览器的透明度

首先，让我们看一下涉及CNAME的DNS解析：

DNS解析

请注意，步骤＃7请求的是_sub.example.com_而不是_anotherdomain.com_。这是因为Web浏览器并不知道_anotherdomain.com_的存在。即使使用了CNAME记录，浏览器的URL栏仍然包含_sub.example.com_。这是浏览器的透明度。如果您考虑一下，浏览器将所有的信任都放在DNS解析器上，以提供关于域的准确信息。简而言之，子域接管是对互联网上某个特定域进行DNS欺骗。为什么？因为对受影响域进行DNS解析的任何浏览器都会接收到攻击者设置的A记录。然后，浏览器会愉快地显示从该服务器接收到的任何内容（认为这是合法的）。

这样的域名对于钓鱼来说是一个完美的场景。攻击者通常使用typosquatting或所谓的Doppelganger domains来模仿合法的域名/网站进行钓鱼。在攻击者接管了某个合法域名之后，普通用户几乎无法判断域上的内容是由合法方还是攻击者提供的。以一个随机银行为例。如果银行的一个子域易受子域接管攻击，攻击者可以创建一个模仿银行网银系统登录表单的HTML表单。然后，攻击者可以进行针对用户的钓鱼或大规模钓鱼活动，要求用户登录并更改密码。在此阶段，密码被控制该域的攻击者捕获。钓鱼电子邮件中提供的URL是银行的一个合法子域。因此，用户不知道有任何恶意活动正在进行。垃圾邮件过滤器和其他安全措施也不太可能将该电子邮件视为垃圾邮件或恶意邮件，因为它包含更高信任度的域名。

事实上，域名本身在成功的攻击中起着重要的作用。一个易受子域接管攻击的第五级子域远不如一个带有友好子域名称的第二级子域看起来合法。我见过几个完美的用于钓鱼的子域，包括：

  • purchases.SOMETHING.com
  • www.SOMETHING.com
  • online.SOMETHING.com
  • shop.SOMETHING.com

它们都容易受到子域接管攻击。它们都是大品牌。谈论完美的钓鱼？

然而，最近的钓鱼活动将内容托管在包含品牌名称的长域名上（参见Apple示例）。具有有效的SSL证书（下面会详细介绍），域名中的关键字以及模仿目标品牌网站的网站，人们往往会陷入这些攻击中。想想看，如果是这个品牌的一个合法子域。


使用Trickest轻松构建和自动化由世界上最先进的社区工具提供支持的工作流程。
立即获取访问权限：

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

SSL证书

上述攻击可以通过生成有效的SSL证书来增强。像Let's Encrypt这样的证书颁发机构允许通过内容验证自动验证域所有权：

Let's Encrypt流程

也就是说，如果在特定的URL路径上放置了特定的内容，Let's Encrypt将批准为给定域颁发证书。由于攻击者完全控制易受子域接管攻击的域的内容，这种验证可以在几分钟内完成。因此，攻击者也能够为这样的域生成SSL证书，从而降低了钓鱼攻击的嫌疑。

Cookie窃取

这与浏览器的透明度密切相关，但后果不同。Web浏览器实施了许多安全策略，以防止恶意网站造成伤害。其中包括同源策略等内容。浏览器的主要安全职责之一是保护保存的Cookie。为什么？虽然HTTP是一种无状态协议，但Cookie用于跟踪会话。为了方便起见，用户通常会将Cookie保存一段时间，以防止每次都需要登录。因此，这些Cookie充当登录令牌，用于向Web服务器呈现并识别用户。会话劫持等攻击自然而然地从这个概念演变而来。

浏览器会自动在向发出Cookie的域发出的每个请求中呈现存储的Cookie。有一个例外情况，即Cookie可能在子域之间共享（在这里阅读，还要注意第8.7节）。这通常发生在网站使用基于Cookie的单点登录（SSO）系统时。使用SSO，用户可以使用一个子域登录，并在广泛的子域范围内共享相同的会话令牌。设置常规Cookie的语法如下：

HTTP/1.1 200 OK
Set-Cookie: name=value

如果这个cookie是由位于_example.com_上的Web服务器发出的，只有这个服务器才能在以后访问这个cookie。然而，可以通过以下方式为通配符域发出cookie（出于上述原因）：

HTTP/1.1 200 OK
Set-Cookie: name=value; domain=example.com

Cookie将包含在发送到_example.com_的HTTP请求中，也将包含在发送到任何其他子域名（如_subdomain.example.com_）的请求中。这种行为为使用子域名劫持进行高危攻击创造了可能性。假设某个特定的域正在使用通配符域的会话Cookie。如果有一个子域易受子域劫持攻击，那么获取用户会话令牌的唯一方法就是诱使用户访问易受攻击的子域。会话Cookie会自动随HTTP请求一起发送。

浏览器还为Cookie实现了额外的安全机制：

  • HttpOnly Cookie — 默认情况下，Javascript代码可以访问由创建Cookie的网站创建的Cookie。Javascript可以读取、更新和删除Cookie。HttpOnly Cookie标志（由Web服务器设置）表示特定的Cookie无法被Javascript代码访问。获取Cookie的唯一方法是通过HTTP请求和响应头。
  • Secure Cookie — 当Cookie由Web服务器设置了_Secure_标志时，只有在使用HTTPS时才能将Cookie发送回Web服务器。

如果域易受子域劫持攻击，攻击者可以通过诱使用户访问该网站来获取该域过去发出的Cookie。HttpOnly和Secure标志无法帮助，因为Cookie不是使用Javascript访问的，并且可以轻松为劫持的域生成SSL证书。

使用劫持进行Cookie窃取的方法在Arne Swinnen的漏洞赏金报告中有所解释。该报告解释了_Ubiquiti Networks_子域(ping.ubnt.com)的问题。这个子域易受子域劫持攻击，指向未声明的AWS CloudFront分发。由于Ubiquiti Networks正在使用通配符会话Cookie进行SSO，所有访问_ping.ubnt.com_的用户都可能会被窃取会话Cookie。尽管此域指向AWS CloudFront，但CloudFront分发设置允许在每个请求中记录Cookie。因此，即使子域指向AWS CloudFront，提取会话Cookie的情况完全可能。2017年，Arne还展示了针对Uber的SSO系统的类似攻击向量。

上述解释的行为不仅限于Cookie。由于Javascript脚本对其运行的网站具有完全控制权，因此能够替换合法网站上的此类脚本可能导致灾难性后果。假设网站使用来自外部提供商的Javascript代码，使用_script_标签和_src_属性。当外部提供商的域名过期时，浏览器会默默失败，即不会触发对常规用户可见的任何警报。如果外部代码没有执行任何重要操作（例如，仅用于跟踪），这样的外部提供商可能会在网站上停留很长时间。攻击者可以接管此过期的域名，匹配所提供的Javascript代码的URL路径，从而控制访问原始网站的每个访问者。

然而，有一种方法可以保护浏览器中Javascript文件的完整性。子资源完整性 被提议作为在HTML5中的_script_标签中包含加密哈希作为属性_integrity_的机制。当提供的加密哈希与下载文件不匹配时，浏览器拒绝执行它。

电子邮件

当CNAME子域劫持可能时，攻击者还可以将MX记录设置为任意Web服务器。这允许将电子邮件接收到某个品牌的合法子域中，这在（针对）钓鱼攻击中特别有用，其中攻击者和受害者之间需要互动。攻击者通常会伪造Return-Path头以接收电子邮件的回复。有了正确的MX记录，这个问题就被绕过了。

另一方面，发送电子邮件也是可能的。虽然很容易伪造From头以包含任何电子邮件地址，但SPF过滤器通常会检查Return-Path头和域的允许发送邮件的主机。SPF在DNS TXT记录中存储配置。通过子域劫持，攻击者也可以控制TXT记录 - SPF检查可以轻松通过。

正如我在开始时指出的，这些策略通常不适用于大多数云提供商，因为您无法直接控制DNS区域。

更高级的风险

子域劫持的概念可以自然地扩展到NS记录：如果至少一个NS记录的基域名可以注册，源域名就容易受到子域劫持的攻击。

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

  1. 由于有两个名称服务器，会随机选择一个。这意味着查询由攻击者控制的名称服务器的概率为50%。
  2. 如果用户的DNS解析器选择_ns.nonvulnerable.com_（合法名称服务器），将返回正确的结果，并且可能在6到24小时之间被缓存。
  3. 如果用户的DNS解析器选择_ns.vulnerable.com_（攻击者拥有的名称服务器），攻击者可能提供一个虚假结果，该结果也将被缓存。由于攻击者控制名称服务器，她可以为此特定结果设置TTL，例如一周。

上述过程在每次缓存条目过期时重复。当攻击者选择使用高值的TTL时，虚假结果将在DNS缓存中保留该时期。在此期间，对_sub.example.com_的所有请求都将使用攻击者缓存的虚假DNS结果。当使用公共DNS解析器（例如，Google DNS）时，这个想法甚至会被放大。在这种情况下，公共解析器很可能会缓存虚假结果，这意味着所有使用相同DNS解析器的用户将获得虚假结果，直到缓存被撤销。

除了对源域名的控制外，还获得了对源域名的所有更高级别域的控制。这是因为拥有NS记录的规范域名意味着拥有源域名的完整DNS区域。

2016年，Matthew Bryant在_maris.int_上使用NS记录演示了子域劫持。.INT顶级域是一个特殊的TLD，只有少数几个域名在使用它。Bryant表明，尽管这些域名的注册仅由IANA批准，但可以将名称服务器设置为任意域名。由于_maris.int_的一个名称服务器可以注册（cobalt.aliis.be），因此即使在这个受限制的TLD上也可以进行子域劫持。

Matthew还演示了一种更高危的攻击，他能够控制.IO顶级域的名称服务器。控制.IO意味着控制所有.IO域名的响应。在这种情况下，.IO的一个名称服务器是_ns-a1.io_，可以注册。通过注册_ns-a1.io_，Bryant能够接收DNS查询并控制所有.IO域的响应。

缓解措施

对于已经存在子域接管漏洞的域名，缓解策略非常简单：

  • 删除受影响的DNS记录 — 最简单的解决方案是从DNS区域中删除受影响的记录。通常情况下，如果组织认为受影响的源域名不再需要，就会采取这一步骤。
  • 认领域名 — 这意味着在特定的云提供商注册资源，或者在常规互联网域名的情况下，重新购买过期的域名。

为了防止将来发生子域接管，组织应该改变其基础设施中创建和销毁资源的过程。在资源创建的情况下，DNS记录的创建必须是这个过程的最后一步。这个条件可以防止DNS记录在任何时间点指向一个不存在的域名。在资源销毁的情况下，相反的情况适用：DNS记录需要作为这个过程的第一步被删除。工具如aquatone包括对子域接管的检查。组织的安全团队应定期执行这些检查，以验证是否存在易受攻击的域名。由于组织内部集中收集暴露的域名的过程通常效率不高（由于全球团队等原因），外部监控通常是最佳选择。

云提供商也应考虑采取缓解策略。云服务不会验证域名的所有权。这主要是出于方便考虑。云提供商不验证源域名的所有权不会引入任何漏洞。因此，用户需要监控其DNS记录。另一个原因是，当云资源被删除时，用户通常不再是该服务的客户。云提供商会问自己一个问题：我们为什么要关心呢？

像GitLab这样的提供商意识到子域接管是一个问题，并实施了域名验证机制。

本文的某些部分摘自我的硕士论文。

下次见！

Patrik


使用Trickest轻松构建和自动化由全球最先进的社区工具提供支持的工作流程。
立即获取访问权限：

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥