mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
99 lines
6.9 KiB
Markdown
99 lines
6.9 KiB
Markdown
# Domain/Subdomain takeover
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|
||
|
||
|
||
## Domain takeover
|
||
|
||
如果你发现某个域名 (domain.tld) **被某个服务使用在范围内**，但该 **公司** 已经 **失去** 了对它的 **所有权**，你可以尝试 **注册** 它（如果价格足够便宜）并通知公司。如果这个域名接收一些 **敏感信息**，比如通过 **GET** 参数或在 **Referer** 头中的会话 cookie，这肯定是一个 **漏洞**。
|
||
|
||
### Subdomain takeover
|
||
|
||
公司的一个子域名指向一个 **未注册名称的第三方服务**。如果你可以在这个 **第三方服务** 中 **创建** 一个 **账户** 并 **注册** 正在使用的 **名称**，你可以执行子域名接管。
|
||
|
||
有几个工具带有字典来检查可能的接管：
|
||
|
||
- [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/antichown/subdomain-takeover](https://github.com/antichown/subdomain-takeover)
|
||
- [https://github.com/musana/mx-takeover](https://github.com/musana/mx-takeover)
|
||
- [https://github.com/PentestPad/subzy](https://github.com/PentestPad/subzy)
|
||
- [https://github.com/Stratus-Security/Subdominator](https://github.com/Stratus-Security/Subdominator)
|
||
- [https://github.com/NImaism/takeit](https://github.com/NImaism/takeit)
|
||
|
||
### Subdomain Takeover Generation via DNS Wildcard
|
||
|
||
当域名使用 DNS 通配符时，任何请求的子域名如果没有明确的不同地址，将会 **解析为相同的信息**。这可以是 A IP 地址，CNAME...
|
||
|
||
例如，如果 `*.testing.com` 被通配符指向 `1.1.1.1`。那么，`not-existent.testing.com` 将指向 `1.1.1.1`。
|
||
|
||
然而，如果系统管理员不是指向一个 IP 地址，而是通过 CNAME 指向一个 **第三方服务**，例如一个 G**ithub 子域名**（`sohomdatta1.github.io`）。攻击者可以 **创建他自己的第三方页面**（在这种情况下是在 Gihub 上）并声称 `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)
|
||
|
||
## Exploiting a subdomain takeover
|
||
|
||
子域名接管本质上是针对特定域名的 DNS 欺骗，允许攻击者为一个域名设置 A 记录，使浏览器显示来自攻击者服务器的内容。这种 **透明性** 使得域名容易受到网络钓鱼攻击。攻击者可能会使用 [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) 或 [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) 来实现这一目的。特别容易受到攻击的是那些在网络钓鱼邮件中看似合法的 URL，欺骗用户并因域名的固有信任而逃避垃圾邮件过滤器。
|
||
|
||
查看这个 [post for further details](https://0xpatrik.com/subdomain-takeover/)
|
||
|
||
### **SSL Certificates**
|
||
|
||
如果攻击者通过像 [_Let's Encrypt_](https://letsencrypt.org/) 这样的服务生成 SSL 证书，将增加这些假域名的合法性，使网络钓鱼攻击更具说服力。
|
||
|
||
### **Cookie Security and Browser Transparency**
|
||
|
||
浏览器的透明性也扩展到 cookie 安全，由像 [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy) 这样的政策管理。cookie 通常用于管理会话和存储登录令牌，可以通过子域名接管进行利用。攻击者可以 **收集会话 cookie**，只需将用户引导到一个被攻陷的子域名，危及用户数据和隐私。
|
||
|
||
### CORS Bypass
|
||
|
||
可能每个子域名都被允许访问来自主域或其他子域的 CORS 资源。攻击者可以利用这一点 **访问敏感信息**，滥用 CORS 请求。
|
||
|
||
### CSRF - Same-Site Cookies bypass
|
||
|
||
可能子域名被允许向主域或其他子域发送 cookie，而这被 cookie 的 `Same-Site` 属性所阻止。然而，请注意，如果反 CSRF 令牌得到了正确的实施，仍然会阻止此攻击。
|
||
|
||
### OAuth tokens redirect
|
||
|
||
可能被攻陷的子域名被允许在 OAuth 流程的 `redirect_uri` URL 中使用。攻击者可以利用这一点 **窃取 OAuth 令牌**。
|
||
|
||
### CSP Bypass
|
||
|
||
可能被攻陷的子域名（或每个子域名）被允许用于 CSP 的 `script-src`。攻击者可以利用这一点 **注入恶意脚本** 并滥用潜在的 XSS 漏洞。
|
||
|
||
### **Emails and Subdomain Takeover**
|
||
|
||
子域名接管的另一个方面涉及电子邮件服务。攻击者可以操纵 **MX 记录** 从合法子域接收或发送电子邮件，从而增强网络钓鱼攻击的有效性。
|
||
|
||
### **Higher Order Risks**
|
||
|
||
进一步的风险包括 **NS 记录接管**。如果攻击者控制了一个域名的 NS 记录，他们可以将一部分流量引导到他们控制的服务器上。如果攻击者为 DNS 记录设置了高 **TTL（生存时间）**，则这一风险会加大，延长攻击的持续时间。
|
||
|
||
### CNAME Record Vulnerability
|
||
|
||
攻击者可能会利用指向不再使用或已停用的外部服务的未声明 CNAME 记录。这使他们能够在受信域名下创建页面，进一步促进网络钓鱼或恶意软件分发。
|
||
|
||
### **Mitigation Strategies**
|
||
|
||
缓解策略包括：
|
||
|
||
1. **删除易受攻击的 DNS 记录** - 如果子域名不再需要，这种方法是有效的。
|
||
2. **声明域名** - 在相应的云提供商处注册资源或重新购买过期域名。
|
||
3. **定期监控漏洞** - 像 [aquatone](https://github.com/michenriksen/aquatone) 这样的工具可以帮助识别易受攻击的域名。组织还应修订其基础设施管理流程，确保 DNS 记录的创建是资源创建的最后一步，而资源销毁的第一步。
|
||
|
||
对于云提供商，验证域名所有权对于防止子域名接管至关重要。一些提供商，如 [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/)，已经认识到这个问题并实施了域名验证机制。
|
||
|
||
## References
|
||
|
||
- [https://0xpatrik.com/subdomain-takeover/](https://0xpatrik.com/subdomain-takeover/)
|
||
- [https://www.stratussecurity.com/post/subdomain-takeover-guide](https://www.stratussecurity.com/post/subdomain-takeover-guide)
|
||
- [https://www.hackerone.com/blog/guide-subdomain-takeovers-20](https://www.hackerone.com/blog/guide-subdomain-takeovers-20)
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|