hacktricks/pentesting-web/domain-subdomain-takeover.md

# 域名/子域名劫持

<details>

<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks 云 ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 推特 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>

* 你在一家**网络安全公司**工作吗？想要在 HackTricks 中看到你的**公司广告**吗？或者你想要**获取最新版本的 PEASS 或下载 HackTricks 的 PDF**吗？请查看[**订阅计划**](https://github.com/sponsors/carlospolop)！
* 发现我们的独家 NFT 收藏品[**The PEASS Family**](https://opensea.io/collection/the-peass-family)
* 获取[**官方 PEASS & HackTricks 商品**](https://peass.creator-spring.com)
* **加入**[**💬**](https://emojipedia.org/speech-balloon/) [**Discord 群组**](https://discord.gg/hRep4RUj7f) 或 [**Telegram 群组**](https://t.me/peass)，或者**关注**我在**推特**上的[**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**。**
* **通过向**[**hacktricks 仓库**](https://github.com/carlospolop/hacktricks) **和**[**hacktricks-cloud 仓库**](https://github.com/carlospolop/hacktricks-cloud) **提交 PR 来分享你的黑客技巧。**

</details>

<figure><img src="/.gitbook/assets/image (3).png" alt=""><figcaption></figcaption></figure>

\
使用[**Trickest**](https://trickest.io/)可以轻松构建和自动化由全球**最先进的社区工具**提供支持的工作流程。\
立即获取访问权限：

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

## 域名劫持

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

### 子域名劫持

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

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

* [https://github.com/EdOverflow/can-i-take-over-xyz](https://github.com/EdOverflow/can-i-take-over-xyz)
* [https://github.com/blacklanternsecurity/bbot](https://github.com/blacklanternsecurity/bbot)
* [https://github.com/punk-security/dnsReaper](https://github.com/punk-security/dnsReaper)
* [https://github.com/haccer/subjack](https://github.com/haccer/subjack)
* [https://github.com/anshumanbh/tko-sub](https://github.com/anshumanbh/tko-subs)
* [https://github.com/ArifulProtik/sub-domain-takeover](https://github.com/ArifulProtik/sub-domain-takeover)
* [https://github.com/SaadAhmedx/Subdomain-Takeover](https://github.com/SaadAhmedx/Subdomain-Takeover)
* [https://github.com/Ice3man543/SubOver](https://github.com/Ice3man543/SubOver)
* [https://github.com/m4ll0k/takeover](https://github.com/m4ll0k/takeover)
* [https://github.com/antichown/subdomain-takeover](https://github.com/antichown/subdomain-takeover)
* [https://github.com/musana/mx-takeover](https://github.com/musana/mx-takeover)

#### 使用 [BBOT](https://github.com/blacklanternsecurity/bbot) 扫描可劫持的子域名：
BBOT 的默认子域名枚举中包含子域名劫持检查。签名直接从 [https://github.com/EdOverflow/can-i-take-over-xyz](https://github.com/EdOverflow/can-i-take-over-xyz) 获取。
~~~bash
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`）。攻击者可以**创建自己的第三方页面**（在这种情况下是 GitHub），并声称 `something.testing.com` 指向那里。因为**CNAME 通配符**会同意，攻击者将能够**为受害者的域名生成任意子域名并指向自己的页面**。

你可以在 CTF 的解题报告中找到这个漏洞的示例：[https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api)
## 利用子域劫持

**此信息来源于** [**https://0xpatrik.com/subdomain-takeover/**](https://0xpatrik.com/subdomain-takeover/)

最近，我[写了一篇文章](https://0xpatrik.com/subdomain-takeover-basics/)介绍了子域劫持的基础知识。尽管这个概念现在已经被广泛理解，但我注意到人们通常很难理解子域劫持带来的风险。在这篇文章中，我将深入探讨我个人认为的子域劫持的最显著风险。

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

### 对浏览器的透明度 <a href="#transparencytoabrowser" id="transparencytoabrowser"></a>

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

![DNS解析](https://0xpatrik.com/content/images/2018/05/resolution-2.png)

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

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

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

* _purchases.SOMETHING.com_
* _www.SOMETHING.com_
* _online.SOMETHING.com_
* _shop.SOMETHING.com_

它们都容易受到子域劫持。它们都是大品牌。谈论完美的钓鱼？

然而，最近的钓鱼活动将内容托管在包含品牌名称的长域名上（参见[Apple示例](https://www.phishtank.com/target\_search.php?target\_id=183\&valid=y\&active=All\&Search=Search)）。具有有效的SSL证书（下面会详细介绍），域名中的关键字以及模仿目标品牌网站的网站，人们往往会陷入这些攻击中。想想看，如果是这个品牌的一个合法子域。

<figure><img src="/.gitbook/assets/image (3).png" alt=""><figcaption></figcaption></figure>

\
使用[**Trickest**](https://trickest.io/)轻松构建和**自动化工作流程**，由世界上最先进的社区工具提供支持。\
立即获取访问权限：

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

### SSL证书 <a href="#sslcertificates" id="sslcertificates"></a>

上述攻击可以通过生成有效的SSL证书来增强。像[_Let's Encrypt_](https://letsencrypt.org/)这样的证书颁发机构允许通过内容验证自动验证域所有权：

![Let's Encrypt流程](https://0xpatrik.com/content/images/2018/05/letsencrypt.png)

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

### Cookie窃取 <a href="#cookiestealing" id="cookiestealing"></a>

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

浏览器会自动在每个请求中向发出它们的域呈现存储的Cookie。有一个例外情况，即Cookie可能在子域之间共享（[在这里阅读](https://tools.ietf.org/html/rfc6265#section-8.6)，还要注意第8.7节）。这通常发生在网站使用基于Cookie的[单点登录](https://en.wikipedia.org/wiki/Single\_sign-on)（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** ——默认情况下，可以通过在创建cookie的网站上下文中运行的Javascript代码访问cookie。Javascript可以读取、更新和删除cookie。由Web服务器设置的_HttpOnly_ cookie标志表示特定的cookie无法被Javascript代码访问。获取它的唯一方法是通过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系统](https://www.arneswinnen.net/2017/06/authentication-bypass-on-ubers-sso-via-subdomain-takeover/)的类似攻击向量。

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

然而，有一种方法可以保护浏览器中Javascript文件的完整性。_子资源完整性_ [被提议](https://www.w3.org/TR/2016/REC-SRI-20160623/)作为在HTML5中的_script_标签中包含加密哈希作为属性_integrity_的机制。当提供的加密哈希与下载文件不匹配时，浏览器拒绝执行它。

### 电子邮件 <a href="#emails" id="emails"></a>

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

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

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

### 更高级的风险 <a href="#higherorderrisks" id="higherorderrisks"></a>

子域接管的概念可以自然地扩展到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 [演示了](https://thehackerblog.com/the-international-incident-gaining-control-of-a-int-domain-name-with-dns-trickery/index.html)使用NS记录在_maris.int_上进行子域接管的攻击。.INT顶级域是一个特殊的TLD，只有少数域名在使用它。Bryant展示了即使这些域名的注册仅由IANA批准，但可以将名称服务器设置为任意域名。由于_maris.int_的一个名称服务器可以注册（_cobalt.aliis.be_），因此即使在这个受限制的TLD上也可以进行子域接管。

Matthew还[演示了](https://thehackerblog.com/the-io-error-taking-control-of-all-io-domains-with-a-targeted-registration/index.html)更高级别的攻击，他能够控制.IO顶级域的名称服务器。控制.IO意味着控制所有.IO域名的响应。在这种情况下，.IO的一个名称服务器是_ns-a1.io_，可以注册。通过注册_ns-a1.io_，Bryant能够接收DNS查询并控制所有.IO域的响应。
### 缓解措施 <a href="#mitigation" id="mitigation"></a>

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

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

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

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

像[GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/)这样的提供商意识到了子域接管的问题，并实施了域名验证机制。

本文的某些部分摘自我的[硕士论文](https://is.muni.cz/th/byrdn/Thesis.pdf)。

下次再见！

[Patrik](https://twitter.com/0xpatrik)

<figure><img src="/.gitbook/assets/image (3).png" alt=""><figcaption></figcaption></figure>

\
使用[**Trickest**](https://trickest.io/)轻松构建和自动化由全球**最先进**的社区工具提供支持的工作流程。\
立即获取访问权限：

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

<details>

<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>

* 你在**网络安全公司**工作吗？你想在HackTricks中看到你的公司广告吗？或者你想获得最新版本的PEASS或下载PDF格式的HackTricks吗？请查看[**订阅计划**](https://github.com/sponsors/carlospolop)！
* 发现我们的独家[NFT收藏品](https://opensea.io/collection/the-peass-family)——[**The PEASS Family**](https://opensea.io/collection/the-peass-family)
* 获得[**官方PEASS和HackTricks周边产品**](https://peass.creator-spring.com)
* **加入**[**💬**](https://emojipedia.org/speech-balloon/) [**Discord群组**](https://discord.gg/hRep4RUj7f)或[**电报群组**](https://t.me/peass)，或在**Twitter**上**关注**我[**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**。**
* **通过向**[**hacktricks repo**](https://github.com/carlospolop/hacktricks) **和**[**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **提交PR来分享你的黑客技巧。**

</details>