DNS Rebinding漏洞原理

目录

• SSRF过滤器设计
• 背景知识
  • DNS TTL
  • 公网DNS服务器
  • DNS重绑定
  • 自建DNS服务器
• 利用步骤图解
• 实战中的注意事项
• 防御
• 参考

---

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。

实战中的注意事项

抄这里的：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访问，不符合规则的IP直接结束流程。

参考

https://blog.csdn.net/u011721501/article/details/54667714

https://www.freebuf.com/column/194861.html

http://bendawang.site/2017/05/31/关于DNS-rebinding的总结/