本文共 3149 字,大约阅读时间需要 10 分钟。
译文声明
本文是翻译文章,文章原作者bookgin,文章来源:http://bookgin.tw原文地址:https://bookgin.tw/2019/01/05/abusing-dns-browser-based-port-scanning-and-dns-rebinding/译文仅供参考,具体内容表达以及含义原文为准
×example.com
,我就不可以用iFrame来窃取他在Youtube (youtube.com) 的浏览记录。然而,域名后有个IP地址,假设 example.com
解析到 93.184.216.34
, 而 youtube.com
解析到 216.58.200.46
。这里有个很酷的办法:不改变域名,那就不会违反同源策略,但是又可以令浏览器实际上是从 216.58.200.46
获取内容: example.com
,解析到自己的IP 240.240.240.240
.example.com/account/information
的内容,但是这时候域名解析到了 216.58.200.46
.攻击成功!然而,当然 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记录给客户端。 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
,如下是我们搭建的恶意网站的内容: 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连接。 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
转载地址:http://pdima.baihongyu.com/