subdomain takeower

子域名接管

CNAME解析方式

在我们访问一个网站时，我们可以通过对应IP访问，也可以通过域名访问，而域名之所以能够让我们访问到对应网站，是因为网站所有者将域名解析到了自己的网站服务器的IP地址，假使我的服务器IP：1.2.3.4，那么解析过程就是将域名指向了IP：1.2.3.4。在对应的DNS服务器上存在了我们的记录

域名指向关系：www.test.com -> 1.2.3.4

此时我们访问www.test.com网站，浏览器会先向DNS服务器&spm=1001.2101.3001.7020)发起查询请求，然后DNS服务器将会返回该IP：1.2.3.4，以供用户浏览器进行访问

A记录

在DNS解析时，我们将一个域名或主机名直接指向一个IP地址，这样的关系我们称之为A记录，这种关系也叫做IP解析

域名指向关系：www.xxx.com -> 1,2,3,4
主机名指向关系：name -> 5,6,7,8

CNAME

这种解析方式与A记录不同，这种方式相当于是为当前域名起了一个别名，即使用一个域名来指向另一个域名：

www.test1.com -> www.test.com -> 1,2,3,4

这种解析方式还可以将多个域名解析到同一域名上：

www.test1.com -> www.test.com -> 1,2,3,4

www.test2.com -> www.test.com -> 1,2,3,4

www.test3.com -> www.test.com -> 1,2,3,4

并且当主域名IP被修改后，其他域名指向的IP也将改变，即修改www.test.com的IP：1，2，3，4将会使www.test1.com，www.test2.com，www.test3.com的IP都发生改变，所以后面三个域名可以认为都是域名 www.test.com的子域名

漏洞利用

域名A将自己CNAME解析到B域名上，此时A成了B的别名。当域名B过期时，并且在域名A未在DNS服务器上解除对应的解析记录（域名A仍然指向域名B）的情况下，我们注册/获取到该域名的使用权，并且解析到我们的服务器上，此时如果有用户通过这条路径来访问域名A的内容，将会访问到我们的服务器，即用户流量经过了我们的服务器，即我们绕开了浏览器的安全策略（因为此时浏览器是百分之百信任DNS的），这就为我们提供了绝佳的中间人欺骗环境（特殊的中间人攻击）

常见的由于错误的配置容易导致子域名接管漏洞的 SaaS 服务有：Github Pages、AWS S3、Wordpress 等，关于目前已知公开可以被接管的服务EdOverflow/can-i-take-over-xyz： “Can I take over XYZ？” — 服务列表以及如何使用悬空 DNS 记录申请（子）域。 (github.com)

HackerOne 上能找到一些子域名接管的报告

极狐GitLab |报告 #2523654 - Gitlab 页面中的子域接管 (hackerone.com)

挖掘

如何判断一个子域名是否存在子域名接管漏洞，一共有两个步骤：

1. 通过 DNS 解析情况，判断其是否解析到了第三方服务上
2. 通过发起 HTTP（S）请求，判断响应内容是否包含指定特征（拿 AWS S3 举例来说，如果存在子域名接管漏洞的话，会返回 The specified bucket does not exist 特征。）

还有一个场景，就是 NS 记录可控导致的子域名接管漏洞，详细的玩法可以参考 Kubernetes 的Kubernetes |报告 #794382 - test-cncf-aws.canary.k8s.io 上的 Route53 子域接管 (hackerone.com)

一个检测子域名接管漏洞的开源项目 haccer/subjack：用 Go 编写的子域接管工具 (github.com)

我们可以将该工具集成到自动化漏洞发现工作流（workflow）中，自动化的域名资产发现，定期的子域名接管漏洞检测，添加一些私有的漏洞识别规则，实时告警等