来Track安全社区投稿~
赢千元稿费！还有保底奖励~（https://bbs.zkaq.cn）
子域接管漏洞综合分析：SDTO、DNS劫持、悬空DNS、CNAME配置错误等
我收集了 HackerOne 上的 143 篇 SDTO（子域接管）漏洞报告，以及 74 篇详细的技术文章，然后潜心研究并记录下心得。在这里，我将分享我的发现，并教你如何正确地寻找 SDTO 漏洞。
子域接管 TLDR（快速入门）
我不会在这里详细展开，因为本文旨在提供更适合中高级猎人的见解。不过，我尽量让新手也能读懂这篇文章。子域接管是一种 高危（甚至可能是 关键）漏洞。当某个资产（通常是子域）通过 CNAME DNS 记录 指向第三方托管提供商时，它会从该第三方提供商获取内容。如果公司停止支付该托管服务费用，但仍然 保留 CNAME 引用，攻击者可能会注册该第三方服务，从而使公司子域指向攻击者控制的资源。
子域的类型 — 应该寻找哪些子域？
一开始，出于某些原因，我假设大多数易受攻击的子域是内部子域，它们本来就不应该面向用户，并且被开发者遗忘了。例如 api.e2e-kops-aws-canary.test-cncf-aws.canary（这是 “@codecancare” 的 Twitter 用户 “todayisnew” 发现的漏洞，一个让我无比敬佩的人）。![]( "null")
仅有 27.1% 的易受攻击子域是为 内部 使用而设计的。这些子域通常包含诸如 “stage”、“dev”、“test” 等单词，通常与其他单词组合，或通过连字符或点与现有子域连接。这表明在寻找新子域时，针对现有子域进行排列组合非常重要，可以使用 AltDNS[1] 实现此目的。这类子域的示例包括：8ybhy85kld9zp9xf84x6、photo-test、dev-admin、api.techprep。57% 的易受攻击子域是为 公开 使用而设计的，曾经是供用户访问的。这个比例是合理的，因为随着公司的发展，它们往往会尝试进入新领域，这些尝试中许多会失败，导致基础设施或网站部分被移除，但 CNAME 可能会被遗忘。这也解释了为什么 最常见的子域是“blog”，共有 5 个实例。
如何发现这些子域？
遗憾的是，在撰写漏洞报告时，漏洞猎人并没有义务披露发现方法，因此 43.9% 的报告没有提及或暗示子域的发现过程。大多数人寻找 SDTO 时会使用 subjack[2] 或 nuclei 等工具，这些工具通过字符串匹配进行搜索。一些托管服务会显示 404 页面，可能表明该站点存在被接管的风险，猎人会关注这些页面。然而，仅有 23% 的漏洞报告表明使用了这种方法。因此，也许你应该重新评估你的子域接管方法。![]( "null")
30.2% 的漏洞报告表明，通过解析域名发现了子域接管漏洞，可能使用了 dig 命令，接着检查 CNAME 记录是否指向已知的易受攻击服务，然后进行更深入的分析。现代模板工具（如 nuclei）现在支持 DNS 检查，因此可以用于部分漏洞发现。在漏洞赏金社区中，我从未见过对此进行讨论，但实际上，在没有第三方托管服务的情况下接管子域是可能的，这种情况在 2.2% 的时间内被观察到。具体来说，一个子域依赖于一个独特的根域，当该根域停止续订时，注册该域将产生相同的接管效果。
是否应该使用 Can-I-Take-Over-XYZ？
如果你曾研究过 SDTO，你一定听说过 Can-I-Take-Over-XYZ，这是一个 GitHub 仓库，展示了哪些服务易受攻击，哪些服务安全。然而，我发现自己使用的方法并不正确，并且你可能也没有正确使用，此外，还有许多服务未列在 Can-I-Take-Over-XYZ 上，这意味着99% 的漏洞猎人尚未追踪这些漏洞。![]( "null")
首先，大多数人仅浏览过 Can-I-Take-Over-XYZ的首页，但实际上，这个页面更新频率很低，仅列出了少部分服务。你可以打开 Issues 页面[3]，并通过 "vulnerable" 标签 进行搜索，发现远比你最初预想的更多服务。其次，有许多服务从未被报告到该仓库。例如，我发现了一些未记录的服务，包括 readymag、reg.ru[4]、Shoplo、icn.bg[5]、modulus.io[6]、Mailgun、DYN、Fider、Wufoo、bigcartel。这些服务中可能还有更多。如果你遇到某个 CNAME 没有被记录，深入研究它，你可能会成为第一个发现该漏洞的人！
托管平台的类型
如果你正在寻找 SDTO 漏洞，了解目标是什么会有所帮助。每个托管服务提供商都有自己的一套接管流程或检测漏洞的方法。因此，最好的方式是选择一个或几个特定的提供商，并专注于寻找这些提供商的漏洞。![]( "null")
图表显示了从报告中提取的 55 个独特托管商的分布情况。由于数据量较大，其中部分已被截断。
SDTO 随时间变化——这种漏洞还值得寻找吗？
在研究这个问题时，我预测随着托管服务商逐渐实施安全功能以防止 SDTO 的发生，漏洞子域会变得越来越少。![]( "null")
然而，我认为这可能适用于所有漏洞类型，因为随着漏洞赏金计划的普及，报告数量自然会增加。不过，由于样本量相对较小，我对从图表中得出明确结论持谨慎态度。然而，值得注意的是，SDTO 并没有如预期那样显著下降，因此 SDTO 仍然值得继续挖掘。
影响力提升——如何获得更高的奖励
SDTO 通常被默认视为高严重性漏洞，但这并不意味着到此为止。你可以通过漏洞链结合的方式来展示更大的影响力，甚至将漏洞提升至关键严重性。利用 SDTO 提升其他漏洞的危害性
•SSRF（服务器端请求伪造） SSRF 通常被视为 P5/P4（信息性/低严重性）漏洞，因为多数情况下它只能调用外部服务器，且目标服务器通常会配置黑名单以阻止访问内部资源。然而，如果我们利用 SDTO 接管子域（如 blog.example.com），可以在该页面上设置一个重定向链接，例如 blog.example.com/?redirect=http://169.254.169.254。这样，目标服务器会通过允许的子域访问被阻止的 IP，进而绕过过滤器，获取敏感信息（例如 AWS 数据）。•绕过内容安全策略（CSP） CSP 旨在预防 XSS 攻击，但通过 SDTO，我们可以绕过该策略。如果接管的子域允许我们托管内容（如 JavaScript 文件），且 CSP 策略设置过于宽松（如 *.example.com），那么可以将该子域利用为存储型 XSS 的载体，进一步窃取会话 Cookie 或实现账户接管。
其他漏洞赏金技巧
1.使用 Wayback Machine 捕获子域接管的证据。即使漏洞被修复或接管失效，你仍有证据证明漏洞存在！(参考：https://hackerone.com/reports/380158)2.检查邮件服务器！即使它们不托管内容，也可能存在漏洞。(参考：https://hackerone.com/reports/736863)3.二阶子域接管漏洞（Second Order Subdomain Takeovers） 也是真实存在的 (参考：https://blogs.msmvps.com/alunj/2021/08/15/second-order-subdomain-takeovers-they-do-exist/)。4.使用 httpx -probe 查找不在线的域名/子域。5.根域名 也可能被接管！(参考1：https://hackerone.com/reports/1226891, 参考2：https://hackerone.com/reports/159156:)
关键点总结！
•检查 DNS 记录比使用字符串匹配方法寻找 SDTO 更有效。•查看 Can-I-Take-Over-XYZ 的 Issues 页面以发现更多未列出的服务。•不要只关注 AWS 接管漏洞，还有很多其他托管服务提供商可供挖掘！
References
[1] AltDNS: https://github.com/infosec-au/altdns
[2] subjack: https://github.com/haccer/subjack
[3] Issues 页面: https://github.com/EdOverflow/can-i-take-over-xyz/issues
[4] reg.ru: https://reg.ru/
[5] icn.bg: http://icn.bg/
[6] modulus.io: http://modulus.io/以上内容由白帽子左一翻译并整理。原文：https://medium.com/@BrownBearSec/what-i-learnt-from-reading-217-subdomain-takeover-bug-reports-c0b94eda4366声明：⽂中所涉及的技术、思路和⼯具仅供以安全为⽬的的学习交流使⽤，任何⼈不得将其⽤于⾮法⽤途以及盈利等⽬的，否则后果⾃⾏承担。所有渗透都需获取授权！
如果你是一个网络安全爱好者，欢迎加入我的知识星球：zk安全知识星球,我们一起进步一起学习。星球不定期会分享一些前沿漏洞，每周安全面试经验、SRC实战纪实等文章分享，微信识别二维码，即可加入。
![]()
