多样的DNS重绑定攻击的深入链#

当然是有前置知识的

DNS(Domain Name Service)，这是将ip地址和域名相连接的

互联网服务，这样大众也就可以在访问域名的时候直接对公网

的ip主机进行访问，而不用记枯燥的ip

这里引用一下dns的记录类型

• A记录：将域名解析为IPv4地址。
• AAAA记录：将域名解析为IPv6地址。
• CNAME记录：用于将一个域名指向另一个域名。
• MX记录：指定处理域名电子邮件的邮件服务器。
• NS记录：指定负责解析域名的DNS服务器。
• TXT记录：用于存储与域名相关的任意文本信息。
• SRV记录：用于指定提供特定服务的服务器及其优先级和权重。

当在浏览器对一个域名进行请求的时候，首先浏览器会查询自身缓存的dns，

如果没有后会查询os端的host文件，如果还没有就继续向上查询根域名服务器，返回顶级域的地址

当然这里可以注意到，如果本地没有dns缓存的话

我们请求dns服务器的解析的返回结果是完全取决于服务端的，

并且每个根域名服务器的架构不同，默认的TTL，也就是默认缓存时间也不一样

这样我们就可以趁两次TTL的差值进行dns重绑定

光说没用，可以模拟一下场景

如果在实战中有一个ssrf点，但是ban了本地地址，无法直接输入127,0,0,1或者localhost等等

那么可以利用dns劫持的二次回环

http://make-1.1.1.1-rebind-127-0-0-1-rr.1u.ms:2375/xxxx

这里的make代表动态解析域名，也就是自己指定如何解析

第一次查询返回1.1.1.1，rebind也就是利用了dns解析两次不一致，后续切换解析为

127-0-0-1，rr也就是轮询。最后也就是dns服务器的地址

当然这种解析规则是根据服务商不一样而变化的

比如7f000001.01010101.rbndr.us

这里的7f000001就是127.0.0.1，01010101就是1.1.1.1

但是本质是一样的，这都可以绕过单点ssrf对于其中回环模式的block

当然，这里还是有后续思路的，

撰写一个poc，扫描绕过单点ssrf后的端口，探测到docker remote服务

可以直接发json起服务，拿到flag

简述下POC

1
{
2
  "Image": "busybox",
3
  "Cmd": ["/host/readflag"],
4
  "HostConfig": {
5
    "Binds": ["/:/host:ro"]
6
  }
7
}

当然，这点在不规范化请求的时候还蛮常见的

那么，深入来说，到底是什么时间点，dns的解析发生了变化

在服务器向dns服务商请求完ip之后，本地缓存TTL开始生效的时候，那个瞬间TCP连接还没有确立

然后它再次检查的时候遇到了rebind，也就进行了重定向，

至于为什么是两次，一次是DNS解析检查，第二次才是真正的HTTP

也就是说，因为需要检查本地回环，它需要连续发两次解析请求，而TTL时间极短

在这之中ip发生了重绑定，也就绕过了本地回环了block。

也就是说，目标若在 check 和 connect 间再次解析域名，就给了 rebinding 时间窗口。

当然，防范的理论也比较好说，第一次校验立即锁定ip即可，或者最终检查ip即可

sora~~~~

》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》