Contents

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

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

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

简介

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

    譬如,一条指向test.sec.comCNAME记录未被删除,而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,这个仓库里还有很多可间接接管的指纹,但由于不常见,没有完全添加进去,感兴趣,可以自己添加进去试试。

项目展示

/images/imgs/1.png

/images/imgs/2.png