Web漏洞-子域名接管漏洞原理及其复现，附加GIthub页面建立教程

Web漏洞-子域名接管

一个原理很简单，仅仅只是配置错误，但是可操作性很强的漏洞

漏洞危害

通过该漏洞可以接管目标子域名，让其显示我设置的任意页面，造成的危害，主要用于网络钓鱼，包括但不限于伪造钓鱼页面，还可以盗取 Cookie，伪造电子邮件等

要理解子域名接管 漏洞，我们需要了解为什么会出现这种情况，我们先介绍CNAME解析方式，在介绍CNAME解析前先

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服务器发起查询请求，然后DNS服务器将会返回该IP：1，2，3，4，以供用户浏览器进行访问

A记录（Address）

在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的子域名

那么这种方式有什么用处呢，我们以图示说明：

内容分发网络是其典型应用，在使用CDN时，通常需要我们将自己的域名作为CNAME指向CDN服务商提供的域名，即：

www.test.com -> www.test.cdn.com

此时我们自己的域名成了cdn服务器的子域名，客户端获取的数据来自于CDN网络，使我们自己的服务器的网络压力降低，以达到负载均衡的目的

漏洞产生原理

如上图的访问流程，浏览器全程只有发起访问与接收地址（1，7），虽然我们访问的是www.test.com域名，但是CDN返回的地址是CDN服务器2的地址，在此过程中浏览器是百分之百信任DNS服务器返回的数据的，即在浏览器处理时，已经将CDN服务器2的地址当作了www.test.com的IP地址，并且能够轻易获取到SSL证书，攻击者由于可以控制子域内容，因此按照Let’s Encrypt的要求在特定的URL路径上放置特定内容之后，Let’s Encrypt 将会自动完成证书的验证，然后批准为给定域发放证书，这就给了我们以可乘之机

漏洞利用

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

• 网络钓鱼：我们可以在自己的服务器上制作钓鱼网站，恶意JavaScript脚本（绕过了内容安全策略在客户端中执行）等等
• 重定向攻击：设置特殊跳转，引导至恶意页面，或者重定向到一些公司的DNS服务器操作后进行域名污染
• Cookie获取：假使用户曾登录过原本的域名A对应网站，那么大概率会携带cookie，小概率会有可能获取到管理员的cookie（似乎有机会实现垂直越权）
• 邮件服务：在一些特殊网站存在该漏洞时，有可能会收到一些组织与个人的隐私邮件，可能会泄露大量的敏感信息（若进行截取并解密，似乎可以发起邮件骚扰，邮件炸弹）
• 劫持攻击：经典跳转账界面，页面下藏页面，用户点击即爆炸，或者剪切板附加恶意代码
• 跨域访问：利用某些Web应用的特性进行跨域资源访问（绕过了同源策略）
• Oauth 授权白名单化：Oauth 授权过程同样有白名单机制，开发者可以指定指定哪个回调URI是可以接受的。当存在劫持漏洞的子域名被列入这个白名单中时，攻击者可以在Oauth授权过程中把用户会话重定向到先前那个存在劫持漏洞的域名中，以此窃取Oauth 授权信息。
• 密码窃取：有些web应用/客户端存在自动填充表单的功能，可以进行获取
• Broken Link Hijacking：这种情况下的子域名，并不属于目标网站所有，但却是用来运行目标网站网页内容的。如果目标网站网页需要从外部导入资源，举例来说，攻击者就可以通过JavaScript的Blob对象类型进行导入，从而声明对目标网站相关子域名的控制权限

NS接管

假使存在有两个CNAME解析，C解析到A，B。若我们劫持了A，用户访问时，既可能访问A，也可能访问B，假使访问了我们劫持的A，将会在DNS上保存解析记录，我们若在A上设置高值的TTL：

TTL是Time to Live的缩写。在计算机网络中，它是一个数值，用于指定在网络上传输的数据包的生存期。TTL值设置在每个数据包的头部，并表示该数据包可以通过的最大跳数或路由器数量，超过该值后数据包将会被网络丢弃。这可以防止数据包在网络中无限循环，有助于确保网络资源的有效利用。当数据包达到其TTL限制时，它要么被丢弃，要么返回给发送方，并附带错误消息。

错误结果将保留在该时段的DNS缓存中。在此期间，对C的所有请求都将使用我们缓存的虚假DNS结果。当使用公共DNS解析器，甚至会放大这个攻击程度。公共解析器可能会缓存错误结果，这意味着使用相同DNS解析程序的所有用户将获得错误结果，直到缓存销毁

除了控制源域名外，还可以控制源域名的所有更高级别的域。这是因为拥有NS记录的规范域名意味着拥有源域名的完整DNS区域

参考大佬文章：

https://links.jianshu.com/go?to=https%3A%2F%2Fthehackerblog.com%2Fthe-international-incident-gaining-control-of-a-int-domain-name-with-dns-trickery%2Findex.html

MX接管

由于MX记录仅用于邮件，仅允许我们接收发往原域名的电子邮件，最常见的还是钓鱼攻击

漏洞解决方案

• 删除对应的解析记录
• 及时重购原有域名

漏洞复现

使用github自带的页面功能（这里我去除了自己的域名信息）

我们先创建一个仓库，为testwwt.github.io，如果存在已有可用仓库可以改名，但要注意的是，格式必须是

xx.github.io

开启页面功能，我这里是已经做好解析了：

创建必要文件，可以在 add file处添加：

第一个必须为CNAME，并且内容只能是CNAME的域名：

第二个文件可以是README.md，index.html详情参照官方文档，随手写点内容

然后我们配置CNAME解析：

然后访问CNAME域名，成功：

然后我们删除该仓库，另外创建一个不同名仓库，并且同上开启页面功能，包含两个文件index.html，与CNAME，我这里要测试JavaScript所以建立了一个index.html文件，但是CNAME中仍然需要只写CNAME域名：

创建，并且用JavaScript简单写个Hello World：

访问我们解析的CNAME域名：

接管成功，漏洞复现

参考文献：

https://links.jianshu.com/go?to=https%3A%2F%2Fthehackerblog.com%2Fthe-international-incident-gaining-control-of-a-int-domain-name-with-dns-trickery%2Findex.html

子域名接管：关于风险的思考 (0xpatrik.com)