子域名接管安全性分析及落地化

能说只是为了学Go嘛？33333 Github项目直通车

简介

1. 子域名接管，主要原因归结于失效dns记录未删除。

   譬如，一条指向test.sec.com的CNAME记录未被删除，而test.sec.com已被注销，这个时候，如果攻击者如果注册了该域名，那么该子域名就会指向一个可控的主机或者域名上。

   CNAME记录是最常被利用的，但其实A记录，NS记录等其他DNS记录也存在被接管的可能。

2. 那么子域名在实战中又能发挥哪些作用？

   • 记得红队钓鱼时有一个钓鱼网站的操作，而往往为了更逼真，获取更高的可信度，往往将域名设置为一个和原域名很相似的域名。而如果能直接接管子域名中的CNAME记录，那岂不是很nice。所以子域名接管的利用主要就是为了高度伪造目标站点，提供高伪装性。

   • 其他危害

DNS

DNS主要就是将好记得域名解析为不好记的IP地址

DNS文档-RFC1034

DNS文档2-RFC1035

从1034到1035新增了几个记录，当下共有16中DNS记录，简要介绍其中和当前分析有关的几个记录类型：

• A 记录域名指向的主机ip
• NS 域名服务器记录，用来指定该域名由哪个DNS服务器来进行解析
• CNAME 别名记录，允许您将多个名字映射到同一台计算机
• MX 邮件交换记录，它指向一个邮件服务器

DNS记录与子域名接管

从上面几个DNS记录来看，如果是A记录，由于ip的可控性很低，虽然也存在类似的服务，例如弹性公网ip申请之类的，所以暂不考虑A记录的接管。而如果记录是指向一个域名的话，则往往可控性更高，可利用性也就更高。

Subtaker项目

有了上面的知识，现在就开始落地化了。

项目需求

1. 判断记录是否被注销，可被重新申请注册
2. 记录指向是否间接可控，例如github page

设计思路

1. 读取字典，遍历子域名的CNAME,MX记录
2. 对收集到的记录进行分别判断其是否可注册
3. 继续对CNAME记录进行指纹识别，看是否为间接可控
4. 输出结果

存在的问题或者关键点

• CNAME链解决(这里也许有什么CNAME->MX记录，但实战中存在的可能性较低，相反工具的性能降低，所以只对CNAME记录链进行处理)
• 线程控制实现方法：采用了信号量+锁的方式
• 高并发性的同时，怎么确保域名查询注册接口进行有效反馈？随机切换查询API+状态码判断
• 单个子域名对应多个记录，go中的net解析时被当作CNAME记录
• 奇奇怪怪的域名解析处理：CNAME解析最后一直返回同样的记录！MX记录进行CNAME记录查询解析竟然也会返回CNAME记录–》调换了MX记录和CNAME记录的判断顺序，但无疑会影响解析速度
• 部分页面例如Github是属于外网，访问速度很慢，或者干脆不能访问，这直接影响结果的准确率–》你们懂的

https://github.com/EdOverflow/can-i-take-over-xyz，这个仓库里还有很多可间接接管的指纹，但由于不常见，没有完全添加进去，感兴趣，可以自己添加进去试试。

项目展示