DNS重绑定攻击0

回顾域名解析系统DNS

在之前，我对DNS的接触主要有两方面：

计网里对DNS的学习。基本只讲了【使用端口53，域名/域名服务器的概念和基本构成，递归查询与迭代查询】三个知识点。都是基础，但必须学过。

DNSlog注入测试中对DNS的使用。用DNSlog.cn获取它的一个子域。向其发起请求时，该DNS服务器不会真的返回IP地址，但会记录下查询的域名并在DNSlog中显示。利用它，我们就可以在上述子域的子域中实现信息外带。（《DNSlog注入测试》）

DNS重绑定攻击

简介

最简单的说，DNS重绑定攻击就是通过恶意DNS服务器，对于一个相同的域名，在两次解析中返回不同的IP地址，实现攻击。其攻击的往往是处于内网中的目标。

利用DNS_rebind绕过同源策略

同源策略（SOP）

同源的定义：如果两个URL的协议、域名、端口都相同的话，则这两个URL同源，否则这两个URL跨域。

在浏览器中，跨域的资源不能相互调用（<script>、<link>、<iframe>、<img>等标签的SRC属性除外）。

如果没有同源策略，就会出现很多问题。举个例子，当没有同源策略时，如果你在浏览器里同时登录了淘宝、邮箱，他们就可以相互读取你的操作和隐私资料。更可怕的是，你打开的其他不相干的网站A、B、C...也可以读取上述内容。那就乱套了。

攻击要求

我们需要控制一个域名（要求DNS和HTTP访问）和一个云服务器。

在该域名下创建子域1，用A模式链接到自己的服务器IP；创建子域2，用NS模式链接到子域1。

这样，在子域2及其子域中，DNS解析的权利就从云服务器提供者那里转到了我们这里。我们在云服务器中自己写一个脚本（53端口通信），就可以起一个恶意DNS服务器。

同时，我们在云服务器的80端口部署HTTP服务，并嵌入一些恶意代码。

完成布置后，我们将子域2作为钓鱼网址发布。

公网上的受害者只要点击包含子域2域名的URL，就会受到攻击。

恶意DNS服务器

将DNS服务器的TTL（生存时间）置为0。这样，受害者的本地域名服务器（或浏览器）每次进行DNS查询的时候都要访问我们的恶意域名服务器，而不会直接在本地取缓存。

第一次查询时，恶意服务器返回我们云服务器真实的IP地址。

在之后的查询中，恶意服务器返回受害者的内网IP地址。

恶意HTTP服务器

第一次查询后，

我们的HTTP服务器收到受害者访问钓鱼URL的请求，发过去一堆恶意JS代码。这些代码通过XMLHTTPRequest持续进行子域2中不同资源路径之间的通信。

在这一阶段，受害者本地域名服务器中记录的子域2指向真实的云服务器IP。恶意JS代码是没有危害的，因为它们只有发到受害者内网的某些端口才会产生危害，而受同源策略保护，来自子域2的XMLHTTPRequest不能直接与内网IP通信。

但经过之后的查询，受害者本地域名服务器中记录的子域2指向了受害者的内网IP。此时，上述的恶意JS代码已经可以直接发向内网IP，因为在浏览器看来，这种信息传送不是子域2与内网IP的跨域通信，而是子域2中不同资源路径之间的通信。

利用DNS_rebind攻击特定逻辑

在一些特定逻辑中，的攻击往往涉及到其他知识点/漏洞，而不是像上面所说的，钓鱼。这时，同上述攻击条件相比，我们只需要让我们的域名支持DNS访问（53端口；这意味着该域名不需要进行备案，因为阻断不备案的域名是在用户通过域名访问80端口时实现的。），并在云服务器中实现DNS恶意服务器就行了。

DNS恶意服务器的逻辑也要根据具体题目做修改；但核心思想（同一域名解析出不同IP）是不变的。

（《buaactf2022::ftp_checker》）