22 KiB
域名/子域名劫持
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- 你在一家网络安全公司工作吗？想要在HackTricks中看到你的公司广告吗？或者你想要获取PEASS的最新版本或下载PDF格式的HackTricks吗？请查看订阅计划！
- 发现我们的独家NFTs收藏品——The PEASS Family
- 获取官方PEASS和HackTricks周边产品
- 加入💬 Discord群组 或者 Telegram群组 或者关注我在Twitter上的🐦@carlospolopm。
- 通过向hacktricks repo 和hacktricks-cloud repo 提交PR来分享你的黑客技巧。
使用Trickest可以轻松构建和自动化工作流程，使用全球最先进的社区工具。
立即获取访问权限：
{% 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/blacklanternsecurity/bbot
- https://github.com/punk-security/dnsReaper
- https://github.com/haccer/subjack
- https://github.com/anshumanbh/tko-sub
- https://github.com/ArifulProtik/sub-domain-takeover
- https://github.com/SaadAhmedx/Subdomain-Takeover
- https://github.com/Ice3man543/SubOver
- https://github.com/m4ll0k/takeover
- https://github.com/antichown/subdomain-takeover
- https://github.com/musana/mx-takeover
使用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）。攻击者可以创建自己的第三方页面（在这种情况下是Github），并声称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解析：
请注意，步骤＃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这样的证书颁发机构允许通过内容验证自动验证域名所有权：
也就是说，如果在特定的URL路径上放置了特定的内容，Let's Encrypt将批准为给定域名颁发证书。由于攻击者完全控制易受子域接管攻击的域名的内容，这种验证可以在几分钟内完成。因此，攻击者也能够为这样的域名生成SSL证书，这只会降低钓鱼攻击的怀疑程度。
Cookie Stealing
这与浏览器透明度密切相关，但后果不同。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的网站上下文中的Javascript代码。Javascript可以读取、更新和删除cookie。HttpOnly cookie标志（由Web服务器设置）表示特定的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系统的类似攻击向量。
上述解释的行为不仅限于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_的用户的角度来看，情况如下：
- 由于有两个名称服务器，随机选择一个。这意味着查询由攻击者控制的名称服务器的概率为50%。
- 如果用户的DNS解析器选择_ns.nonvulnerable.com_（合法名称服务器），则返回正确结果，并可能在6到24小时之间被缓存。
- 如果用户的DNS解析器选择_ns.vulnerable.com_（攻击者拥有的名称服务器），攻击者可能提供一个虚假结果，该结果也将被缓存。由于攻击者控制名称服务器，她可以为此特定结果设置TTL，例如一周。
上述过程在每次缓存条目过期时重复。当攻击者选择使用高值的TTL时，虚假结果将在DNS缓存中保留该时期。在此期间，所有对_sub.example.com_的请求都将使用攻击者缓存的虚假DNS结果。当使用公共DNS解析器（例如，Google DNS）时，这个想法甚至会被放大。在这种情况下，公共解析器很可能会缓存虚假结果，这意味着所有使用相同DNS解析器的用户将获得虚假结果，直到缓存被撤销。
除了对源域名的控制外，还获得了对源域名的所有更高级别域的控制。这是因为拥有NS记录的规范域名意味着拥有源域名的完整DNS区域。
在2016年，Matthew Bryant 演示了使用NS记录在_maris.int_上进行子域接管的攻击。.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这样的提供商意识到子域接管是一个问题，并实施了域名验证机制。
本文的某些部分摘自我的硕士论文。
下次再见！
使用Trickest轻松构建和自动化由全球最先进的社区工具提供支持的工作流程。
立即获取访问权限：
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- 你在网络安全公司工作吗？你想在HackTricks中看到你的公司广告吗？或者你想获得最新版本的PEASS或下载PDF格式的HackTricks吗？请查看订阅计划！
- 发现我们的独家NFTs收藏品——The PEASS Family
- 获得官方PEASS和HackTricks周边产品
- 加入💬 Discord群组或电报群组，或在Twitter上关注我🐦@carlospolopm。
- 通过向hacktricks repo 和hacktricks-cloud repo 提交PR来分享你的黑客技巧。