Mysticbinary

只有通过概念的劳作才能获得真实的思想

DNS Rebinding漏洞原理


DNS Rebinding 广泛用于绕过同源策略、SSRF过滤等。

为什么需要SSRF过滤器:
• 由于一些业务的需要,他们就是需要让用户输入URL,然后进行跳转,如果过滤得好,这就是一个正常功能,如果过滤得不好,那么这里就存在SSRF漏洞。

SSRF过滤器设计

有漏洞的SSRF过滤器执行步骤如下:

  1. 获取输入的URL,从该URL中提取HOST,如果提取出来的是IP,那么直接跳到第三步;
  2. 对该HOST进行DNS解析,获取到解析的IP;
  3. 检测该IP是否是合法的,比如是否是私有IP等(是就直接终止流程);
  4. 如果IP检测为合法的,则进入CURL发包;

漏洞点:
我们从DNS解析的角度看,该检测方式一共有两次,第一次是步骤2中对该HOST进行DNS解析,第二次是使用CURL发包的时候进行解析。这两次DNS解析是有时间差的,我们可以使用这个时间差进行绕过

其实上面就已经讲清楚DNS Rebinding漏洞的原理了,只不过只有大致步骤,下面我们就通过具体实现来深入了解。

背景知识

了解DNS Rebinding漏洞的利用步骤前,了解一些这些背景知识还是很有必要的。

DNS TTL

TTL值全称是“生存时间(Time To Live)”,简单的说它表示DNS记录在DNS服务器上缓存时间,数值越小,修改记录各地生效时间越快。
当各地的DNS(LDNS)服务器接受到解析请求时,就会向域名指定的授权DNS服务器发出解析请求从而获得解析记录;该解析记录会在DNS(LDNS)服务器中保存一段时间,这段时间内如果再接到这个域名的解析请求,DNS服务器将不再向授权DNS服务器发出请求,而是直接返回刚才获得的记录;而这个记录在DNS服务器上保留的时间,就是TTL值。

常见的设置TTL值的场景:
• 增大TTL值,以节约域名解析时间
• 减小TTL值,减少更新域名记录时的不可访问时间

公网DNS服务器

比如大名鼎鼎的:
114.114.114.114
8.8.8.8
...

DNS重绑定

需要自己持有一个域名,然后将这个域名解析指向自己的DNS Server,在该域名写2个解析服务。

同样是test.exploitcat.xyz.域名,却写上了两个A记录。这样做的目的就是,写2个解析服务,这样每次请求的时候都能返回不同的解析结果。

• 第一次请求DNS查询,结果返回的是101.191.60.117,是一个合法的公网IP;
• 第二次请求时,变成了私有IP 10.36.5.215;
简单来说就是已知服务器会向DNS服务器发送两次解析请求,目的就是要让第一次解析出来是个外网ip,第二次解析出来是个内网ip。

同一个域名绑定两条A记录。这样解析是随机的。 (ps:同时绑定两条A记录,在请求解析的时候并不一定交替返回)

注意,这两条记录的ttl都是0,这是为了防止有DNS服务器对解析结果进行缓存。现在国内购买的域名大都无法直接将TTL设置为0,例如我的阿里云的域名,最小的TTL是10分钟。而某些国外的域名可以设置TTL=0。
记住:TTL数值越小,修改记录各地生效时间越快。

自建DNS服务器

上面说的DNS重绑定,有个不好的点,就是解析是随机的,需要多次访问才能得到自己想要的内网IP。但是如果使用自建DNS服务器,那么就可以稳定的控制返回结果。

常见的技术方案:搭建DNS服务器采用python的twisted库中的name模块。具体技术细节自行搜索吧。

利用步骤图解

有了上面的背景知识铺垫,下面就可以开始看利用步骤图了。

建议看看里面的流程图:https://www.freebuf.com/column/194861.html

步骤6解释,当你请求外部恶意http://www.a.com时,www.a.com就加载了一个JS脚本,这个脚本的作用就是等待你机器的DNS缓存时间一到,就立马重新自动访问www.a.com。

这个图画了多个箭头,会让一些人觉得是发送了多次HTTP请求,其实只发送了一次HTTP请求,只不过进行了两次DNS解析操作。

实战中的注意事项

抄这里的:https://blog.csdn.net/u011721501/article/details/54667714
事实上,基于DNS Rebinding的绕过方式在实战中可能会遇到一些问题。

问题一是DNS缓存的问题,即使我们在前面实现的时候设置了TTL为0,但是有些公共DNS服务器,比如114.114.114.114还是会把记录进行缓存,完全不按照标准协议来,遇到这种情况是无解的。但是8.8.8.8是严格按照DNS协议去管理缓存的,如果设置TTL为0,则不会进行缓存,从效果上来看,每次dig都会跑去我们的NS服务器上去查询一遍。

问题二是DNS迭代查询和递归查询的问题,往往这边发起攻击,DNS服务器会收到很多不同IP的查询请求,无法确定与受害服务器相关的来源IP是哪个。为此我一共实现了3版解析脚本,第一版很容易想到,首先对来源IP进行搜集,保存在文件中,然后真实发起请求的时候基于IP列表进行解析,但是后来发现还是很多莫名其妙的来源IP过来。但是仔细查看这些IP,发现都是某个B段或者C段的,很固定,因此第二版是基于IP段过滤,但是又有这种解析flag标志位交替不准确的问题。

最终,我实现一个时间窗口,用这个时间窗口去返回解析内容,比如前5s返回结果1,后5s返回结果2,对于时间窗口的具体值,需要探测阶段进行统计和尝试。

防御

可以重新设计一下SSRF过滤器,在第四步中:4.如果IP检测为合法的,则进入CURL发包。 执行到发包流程的时候,直接换成IP访问访问WEB服务,并且判断IP是否符合规则,不符合规则的IP直接结束流程。

参考

https://blog.csdn.net/u011721501/article/details/54667714
https://www.freebuf.com/column/194861.html
http://bendawang.site/2017/05/31/关于DNS-rebinding的总结/


这篇文章对你有帮助吗?作为一名程序工程师,在评论区留下你的困惑或你的见解,大家一起来交流吧!
微信公众号: Mysticbinary
Github:https://github.com/Mysticbinary
本文版权归作者所有,欢迎转载,但未经作者同意请保留此段声明,请在文章页面明显位置给出原文链接
声明:本文章仅限于讨论网络安全技术,请勿用作任何非法用途,否则后果自负,本人和博客园不承担任何责任!

posted on 2021-03-02 18:30  Mysticbinary  阅读(344)  评论(0编辑  收藏  举报

导航