译文声明
本文是翻译文章，文章原作者bookgin，文章来源：http://bookgin.tw
原文地址：https://bookgin.tw/2019/01/05/abusing-dns-browser-based-port-scanning-and-dns-rebinding/

译文仅供参考，具体内容表达以及含义原文为准
×

在这篇文章中，我将介绍如何使用DNS重绑定来读取跨站的内容，而第二部分是利用DNS fallback机制来进行内网端口扫描。这两种攻击方式，只要求受害者点击链接打开含有恶意内容的网页。
利用一：同源策略绕过
众所周知，同源策略是一个浏览器的基本安全策略。因为默认的情况下，浏览器会阻止获取来着非同源的内容。如果有一个用户访问了我的网站example.com，我就不可以用iFrame来窃取他在Youtube (youtube.com) 的浏览记录。
然而，域名后有个IP地址，假设 example.com 解析到 93.184.216.34, 而 youtube.com 解析到 216.58.200.46。这里有个很酷的办法：不改变域名，那就不会违反同源策略，但是又可以令浏览器实际上是从 216.58.200.46获取内容：

1. ① 受害者访问了我们含有恶意内容的网站 example.com，解析到自己的IP 240.240.240.240.
2. ② 受害者正在获取example.com/account/information的内容，但是这时候域名解析到了 216.58.200.46.
3. ③ 但是此时请求并没有违反同源策略，因此我就可以读取其内容，并且把他发回我的log服务器

攻击成功！然而，当然 youtube.com 这么攻击时没用的，对于DNS重绑定技术的局限性和防御措施，请参考下面的防御措施部分。
攻击场景
所以可以假设有这样一个场景，当有个的管理员界面运行在 127.0.0.1:8080，因为它只能通过本地访问，所以你认为没有必要为它设置密码保护。倘若管理员界面中的敏感信息在127.0.0.1:8080/account/information，我们是可以绕过同源策略并且从这个页面上窃取信息。这个攻击场景是相当具有实际意义的，这儿有一个真实的案例。
假设受害者使用Chromium 71，并且点开了我们含有恶意内容的网站 example.com:8080 ，一开始它被解析到 240.240.240.240。
不幸的是，DNS重绑定攻击没办法可以这么直接地实施。由于DNS缓存机制，当域名一开始解析到 240.240.240.240 (攻击者的IP)，浏览器会把它缓存下来，并且下一次就不会再进行DNS查询了。
要绕过这个限制，我们可以自建DNS服务器，返回给多个A记录给客户端。

当DNS服务器响应中包含多条A记录的时候，Chromium首先会尝试连接到 240.240.240.240 ，如果240.240.240.240 无法访问(连接被拒绝或者路由不可达)，它就会使用0.0.0.0 作为fallback(备选)。
注意：Chromium并不一定总是会在一开始把域名解析到240.240.240.240 ，还有可能会被解析到第二项 0.0.0.0 (localhost)，出现这种情况的时候再试几次就好了。0.0.0.0 才是要点所在，我们不能用 127.0.0.1 ，否则Chrome会在一开始就直接把域名解析到 127.0.0.1 ，这样我们就没法让受害者访问我们的恶意网站了。然而，在使用 240.240.240.240 和0.0.0.0的时候，Chrome才会在一开始先解析到240.240.240.240
因此，等受害者一访问 example.com， Chromium就会把它解析到240.240.240.240，如下是我们搭建的恶意网站的内容：

然而，我们之前说过Chromium会把example.com 的解析结果240.240.240.240缓存下来，这样一来我们就永远也没办法从 0.0.0.0:8080的管理员界面窃取数据了。因此我们要做的是，把位于 240.240.240.240的Web服务器暂时关掉，基于DNS fallback机制(再次访问的时候连接被拒绝)，Chromium就会从 0.0.0.0:8080.获取内容，这样一来，我们就能在不违反同源的前提下窃取数据了！
这个Poc在Chromium 71有用，其他复杂的PoC可以参见Github上的项目singularit.
防御措施
不过，这种攻击也有一定的局限性。网站开发者们可以利用局限性来防止他们的网站受到攻击：
【1】不发送Cookie: 令网站只支持使用IP地址访问，这样浏览器就不可能把网站的Cookie发给攻击者了。
【2】验证请求头中的HOST字段：令网站验证HTTP请求头里的Host字段，这样就杜绝了漏洞，因为HOST是example.com:8080.
【3】使用HTTPS：当域名不正确的时候，浏览器会拒绝TLS连接。

利用二：端口扫描
是不是发现DNS Fallback的机制还蛮有趣的？这个部分我们来谈谈如何利用这个机制进行内网端口扫描。
办法很直接，很容易就能想到，假设DNS解析结果长这样：

因为：Chromium总是会首先把域名解析到 127.0.0.1 ，而只有在连接127.0.0.1失败的时候，才会尝试去连接 240.240.240.240。所以说，我们可以利用这个现象来检测端口是不是开放的。
开始攻击
基于浏览器的端口扫描恶意源码:

我们在自己服务器 240.240.240.240上开放 13337 – 13340 端口，如果端口接收到了来自客户端的连接，那么这就意味着在受害者的本机上，对应的端口是关闭的。
为了能扫内网，我们想知道受害者的私有IP地址，HTML5 WebRTC技术可以用来泄漏受害者的私有IP地址，可以参考这个PoC。其实HTML5看上去还有很多的特性，这些特性很容易会被滥用。

当然也有另外的办法来实现端口扫描，可以参见这两位前辈的相关文章：
【1】基于WebRTC+XHR的延时攻击：Skylined uses timing attack based on WebRTC+XHR
【2】基于iframes和一些小技巧检测连接是否被拒绝：Gareth Heyes uses iframes
后记
我一直在想：当点击一个无关痛痒的链接，即使我什么也不提供，会发生什么？攻击者可以做些什么？
【1】家庭网络内网扫描
【2】找到IoT设备的网页入口 192.168.1.2:8000 以及在192.168.1.1:8080的WiFi管理员界面
【3】发送恶意请求控制IoT设备，比如最简单的可以打开家里的门。
【4】…
好吧，可能有点夸张，但这听起来真的有可能，看看这篇文章)，不是嘛？下次点开链接之前记得三思而后行。
参考
Gareth Heyes, 基于浏览器进行端口扫描内网
Skylined (@berendjanwever), 内网扫描器
NCC Group Plc, Singularity: 一个DNS重绑定攻击框架
Michele Spagnuolo, DNS重绑定的威力：用一个网站来窃取WiFi密码
Brannon Dorsey, 用DNS重绑定攻击私有网络

欢迎登录安全客 -有思想的安全新媒体www.anquanke.com/加入交流群113129131 获取更多最新资讯

原文链接： https://www.anquanke.com/post/id/213413