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