0x00 前言

前几个月，关于子域名劫持的安全报告数量激增，去看了几篇报告，感觉这也是一个现在较为广泛存在的问题，就写出来共享一下。

0x01 子域名与域名解析

先来介绍一下子域名和域名解析的一些相关知识。

子域名

我们通常在域名提供商购买的域名如 baidu.com，并不是只能解析一个服务器，我们可以在它的基础上增加很多的子域名，比如 test.baidu.com，smtp.baidu.com，image.baidu.com，talent.baidu.com 等等，它们可以分别解析到不同的服务器。

域名解析

域名解析的记录类型很多：

• A记录：地址记录，用来指定域名的IPv4地址，如果需要将域名指向一个IP地址，就需要添加A记录。

• CNAME： 如果需要将域名指向另一个域名，再由另一个域名提供ip地址，就需要添加CNAME记录。

• TXT：在这里可以填写任何东西，长度限制255。绝大多数的TXT记录是用来做SPF记录（反垃圾邮件）。

• NS：域名服务器记录，如果需要把子域名交给其他DNS服务商解析，就需要添加NS记录。

• AAAA：用来指定主机名（或域名）对应的IPv6地址（例如：ff06:0:0:0:0:0:0:c3）记录。

• MX：如果需要设置邮箱，让邮箱能收到邮件，就需要添加MX记录。

• 显性URL：从一个地址301重定向到另一个地址的时候，就需要添加显性URL记录（注：DNSPod目前只支持301重定向）。

• 隐性URL：类似于显性URL，区别在于隐性URL不会改变地址栏中的域名。

• SRV：记录了哪台计算机提供了哪个服务。格式为：服务的名字、点、协议的类型

我们最常用的是A记录与CNMAE记录，分别是将域名指向ipv4地址或另一个域名。

0x02 漏洞原理

子域名劫持产生的原因一般都是网站开启了很多子域名，这些子域名其中又有很多cname解析来解析到其他的网站，然后在某一天，这些被指向的网站废弃了，然后又没有去删除解析记录。

这些被废弃的网站原本的域名被攻击者注册或通过其他手段获得，然后定向到攻击者的服务器并在上面部署钓鱼网站，或者劫持cookie的代码，当用户再次访问这些子域名就会解析向钓鱼网站，或者被盗取cookie而丢失账号。

0x03 漏洞利用

我们可以用实例来证明一下，假设现在我们有一个域名 uuzdaisuki.com ,其中有一个解析记录 test.uuzdaisuki.com 原本指向我们另外一个域名 www.sbwyfdsmjb.tk ，但是有一天，我们废弃了这个功能，将第二个域名注销了，却忘记删掉这条解析记录。

如果这个解析被攻击者发现了(通过扫描之后的报错界面)，然后攻击者抢注了这个已经被废弃的域名 sbwyfdsmjb.tk，这个时候攻击者就可以将域名解析向自己的服务器，我这里以github页面证明一下。

可以看到，test.uuzdaisuki.com解析到了最终由攻击者可控的github页面。

这个时候从包括第二个域名及其之后的东西全部都是我们可控了，这个时候可以用来做些什么，相信大家心里都有数了。

我来举两个常见的例子：

钓鱼网站

我们在第二个域名中，使用A记录解析到一台自己的匿名服务器，然后在服务器上部署web服务，根据第一个域名所在公司的业务类型，写一个相似的前端登陆界面然后发送链接出去，就可以实施钓鱼，被攻击者一般看到这个域名的确是所登陆业务的域名，也就不会有疑心了，钓鱼成功率大大增加。

提供一个qq邮箱的完整前后端钓鱼代码: https://github.com/echohun/tools/tree/master/%E9%92%93%E9%B1%BC/qq%E9%82%AE%E7%AE%B1%E9%92%93%E9%B1%BC%E5%89%8D%E7%AB%AF%2B%E5%90%8E%E7%AB%AF%E5%85%A8%E4%BB%A3%E7%A0%81/mailqq

效果如下，可以达到以假乱真：

csrf

我们目前可以控制的子域名和对方业务属于同一个顶级域名，那同源策略就限制不了我们了，只需要在这个子域构造一个恶意的页面，跳转对这个顶级域名下其他业务发起请求，很容易造成跨站请求伪造。

详细可以参考这个案例： https://hackerone.com/reports/172137

cookie盗取

同样的，既然我们控制的子域和对方业务属于同一个顶级域名，那么cookie的作用域，我们也是共享的，只需要在这个子域名增加代码将cookie保存起来，之后就可以利用cookie登陆这些被攻击用户的账号，造成cookie劫持。

具体方法和xss进行cookie盗取一样。

0x04 应对

造成子域名劫持根本的原因是运维人员的粗心大意，没有及时关闭掉废弃的dns解析，只需要及时关闭，就可以避免这个问题。但是不幸的是这个问题现在广泛的存在于各个企业之中，每周都能看到非常多关于子域名劫持的安全报告。

其他案例：

https://hackerone.com/reports/32825

https://hackerone.com/reports/38007

https://hackerone.com/reports/175070