专栏首页Seebug漏洞平台检测本地文件躲避安全分析

检测本地文件躲避安全分析

来源:安全客

原文链接:https://www.brokenbrowser.com/detecting-local-files-to-evade-analysts/

译者:WisFree

前言

上个月,我们一直都在尝试弄清楚攻击者到底是如何通过检测目标系统中应用程序的相关MIME类型来对用户进行攻击的。如果目标计算机中安装了反病毒工具的话,恶意软件将拒绝下载恶意代码。这样一来,攻击者不仅可以保证恶意软件不会被检测工具所检测到,而且还可以在目标主机中潜伏很长的时间。当然了,所有的这一切都发生在浏览器中。虽然厂商及时修复了相关的漏洞,但我们现在仍然可以绕过补丁来实施攻击。

漏洞概述

今天我们要讲解的是另外一个指纹漏洞,这个漏洞将允许攻击者检测目标主机中是否存在某些类型的文件。根据Proofpoint公司的安全研究专家所透露的信息,这个漏洞是一个信息泄露漏洞,此前有很多不同的恶意广告活动和漏洞利用工具都利用了这个漏洞来实施攻击。目前,微软公司已经成功修复了这个漏洞。

在2015年10月至12月期间,Proofpoint公司的安全研究专家发现了至少两个信息泄露漏洞(CVE-2016-3351CVE-2016-3298),并且已经将漏洞细节提交给了微软公司。微软于2016年9月份修复了漏洞CVE-2016-3351,并且在2016年10月份修复了漏洞CVE-2016-3298。但不幸的是,黑客在不到一天的时间里就成功绕过了这两个补丁。

利用漏洞CVE-2016-3298

我们可以加载目标文件的内部资源,并通过检查类似onload/onreadystate/onerror这样的事件是否发生来检测主机中是否存在某些目标文件(exe、dll和cpl等等),这种方法也是目前攻击者最为常用的方法。实际上,IE浏览器会使用内部资源来加载信息页面、错误信息、以及某些插件图标。虽然这些资源嵌入在二进制文件之中,但是我们也可以单独加载这些资源。

最常见的一个例子就是当我们尝试在IE浏览器中加载无效的URL资源时,IE浏览器会显示一个错误页面。比如说,当我们在浏览器地址栏中输入网址“http://invalidsite ”之后,IE浏览器就会将如下图所示的页面显示给我们:

我们看得懂这个URL地址,但是浏览器不一定看得懂,而这个页面很明显跟我们输入的网址没有任何关系。接下来,我们可以通过检查该页面的属性来找出该页面真正的URL地址:在页面空白处点击鼠标右键,然后在弹出的菜单中选择“页面属性”,浏览器便会将关于该页面的信息显示出来:

加载资源

正如我们所看到的那样,该页面的内容来自于res://ieframe.dll/dnserror.htm#http://invalidsite/,其中“res:”表示的是资源,而这是IE浏览器用来从二进制文件中加载内部资源所用的方法。默认情况下,浏览器会假设资源文件存在于目录“windows/system32”之中,但是我们也可以修改这个路径。比如说,如果我们安装了Fiddler,我们就可以轻易地找出其中的一个有效资源,并将其提供给IE浏览器。接下来,我们就可以通过检测readystate事件来查看资源是否加载成功了。

如果你使用的是Resource Hacker这样的免费工具,那么你就可以直接读取到资源的名称和内容,并将它们以图片或者HTML文件的形式进行加载。为了进行简单的演示,我们在Resource Hacker中打开并查看dnserror.htm的内容,具体如下图所示:

实际上,我们根本不需要通过Resource Hacker来查找有效资源,因为二进制文件中的默认资源都有固定不变的值。比如说,所有二进制文件的“文件信息”都可以通过资源“/16/1(16 == RT_VERSION)”来查找。需要注意的是,我们完全不必检索每一个需要进行测试的文件,因为我们可以直接通过加载默认资源来实现我们的目的。比如说,我们可以向Fiddler提供资源的默认信息,而下面这段指令将会触发一个readystatechange事件。

res://c:\Program Files (x86)\Fiddler2\Fiddler.exe/16/1

安装补丁之前的PoC

为了利用这个漏洞,我们应该在一个iFrame中加载资源,并且记录下onreadystate事件被触发的次数。如果该事件被触发了一次,则说明目标文件存在;如果被触发了两次,则说明该文件不存在。

关键代码如下所示,如果你愿意的话,你也可以直接下载一个可用的PoC

下载地址 - 密码:infected。

<iframe src="res://c:\Program Files (x86)\Fiddler2\Fiddler.exe/16/1" onreadystatechange="count++"></iframe>  <script>  count = 0;  // This onload gives the iFrame a bit of time to load.// But has nothing to do with the method itselfwindow.onload = function()  {
  if (count == 1) alert("File exists!");
  else alert("File does not exist");}</script>

改进PoC

上面的这个PoC在上周之前还是可以正常工作的,但是因为微软在上周修复了这个漏洞,所以我们现在就得通过其他的方法来利用这个漏洞了。首先,让我们来看一看攻击者是怎么实现的。关键代码如下图所示:

在这里,恶意软件的作者使用了三种不同的技术来检测某一本地文件是否存在,但是漏洞现在已经被微软修复了。在上面这段代码中,第一个引起我注意的就是“mhtml:file”,因为即使IE禁用了“file:protocol”,但是mhtml仍然可以正常工作。于是我脑海中闪现了一个念头:虽然“mhtml:file”和“res://”已经无法使用了,但如果将mhtml和res配合使用的话,会不会产生意想不到的效果呢?

如果你正在使用IE浏览器的话,你可以直接在线体验一下这个漏洞[传送门]。关键代码如下所示:

<iframe src="mhtml:res://c:\Program Files (x86)\Fiddler2\Fiddler.exe/16/1" onload="count++"></iframe>  <script>  count = 0;  window.onload = function()  {
  if (count == 1) alert("File exists!");
  else alert("File does not exist");}</script>  

如果你想深入了解这个漏洞和相关的补丁程序,或者你想寻找其他绕过方法的话,我建议你下载免费版的IDA,然后尝试一下我们在之前利用mimeType漏洞时所使用的方法[传送门],你也许可以从中得到一些启发。

我们现在已经知道的是,IE浏览器会非常乐意去加载类似“res://ieframe.dll”这样的东西,所以我们就可以找出这部分代码,然后看看是否能够利用这些代码来做更多有意思的事情。我直接告诉你吧,我们所要寻找的函数名为“IsIEResourcePage”。

接下来,我们要修改iFrame的location,并且要与之前设置为“res://ieframe.dll”时的返回值进行对比。

如果你懒得对返回数据进行手动对比的话,你也可以使用JavaScript脚本来完成这个任务。我在这里要跟大家分享一个小秘诀:当你在研究的过程中,最好使用window.open方法来修改iframe的location,尽量不要使用iframe.location。如果我们使用常规的修改方法,例如location.href和location.replace等方法,那么IE浏览器很可能会拒绝加载资源,此时浏览器将会返回一个“about:blank”页面。

关键代码如下所示:

<iframe name="ifr"></iframe>  <script>  // No errors, about:blank loaded in iFrame, very slow.ifr.location = "res://testing.dll";  // Access Denied, nothing changes in the iFrame, super-fast.window.open("res://testing.dll", "ifr");  // This last option can be used with a try/catch creating// a battery of tests that will immediately return// the result.</script>  

总结

没错,即使是官方发布了某一漏洞的修复补丁,也并不意味着这个漏洞就无法再被利用了。我之所以要撰写这篇文章,其中一个原因就是我想要将我所发现的东西分享给大家,以供大家学习和参考。但是我最重要的一个目的就是为了让微软公司认识到这个漏洞的严重性,希望他们能够更加重视这种类型的漏洞,并提升这类漏洞的威胁等级。

攻击者就是这样,当某个漏洞“被修复”之后,他们又会立刻尝试去寻找新的漏洞利用方法。在信息安全这个领域内,这种“猫捉老鼠”的游戏几乎是永无止境的。最后,安全客祝大家挖洞愉快!

本文分享自微信公众号 - Seebug漏洞平台(seebug_org),作者:WisFree

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2016-10-27

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Seebug 联合“女娲计划”推出最新 0day/1day 漏洞奖励升级模式

    Seebug是知道创宇旗下著名的老牌通用漏洞社区平台,从2006年上线以来已运营14年多之久了,聚集了大量安全研究者及相关漏洞信息资料。“赋予漏洞灵魂,打造权威...

    Seebug漏洞平台
  • 从补丁到漏洞分析——记一次joomla漏洞应急

    2018年1月30日,joomla更新了3.8.4版本,这次更新修复了4个安全漏洞,以及上百个bug修复。

    Seebug漏洞平台
  • Sebug 联合 i 春秋&谷安网校全网首发KCon 2015视频干货

    还记得今年夏天黑客周的高潮吗?——知道创宇在北京举办的“黑无止境”KCon大会上,来自全国的黑客高手和白帽爱好者们,一起经历了三天的狂欢。 这是一个难忘的夏天,...

    Seebug漏洞平台
  • ActiveMQ 的 三台服务器高可用集群搭建方案

    节点A: 与 节点B 节点C 进行消息同步, 所以节点A 节点B 节点C 都可用作消费者访问节点

    北漂的我
  • Django实战-小程序服务端登录验证-上

    Django网络应用开发的5项基础核心技术包括模型(Model)的设计,URL 的设计与配置,View(视图)的编写,Template(模板)的设计和Form(...

    小团子
  • 三省吾身:我真的懂 CAP 吗

    想写这个是源于微信交流群里面的一个讨论。在讨论分布式系统的时候,有群友明确地如下说:

    kirito-moe
  • LeetCode 2. 两数相加

    给出两个 非空 的链表用来表示两个非负的整数。其中,它们各自的位数是按照 逆序 的方式存储的,并且它们的每个节点只能存储 一位 数字。

    freesan44
  • 你真的懂CAP吗?

    这把我惊起了一身冷汗,赶紧去查了一下是不是分布式系统理论界又有新的论文来推翻了之前的CAP定理了。后来深入讨论以后,才发现是他对CAP的理解有误。

    用户5397975
  • html+css学习笔记018-H5弹性盒模型

    Mr. 柳上原
  • 100 行写一个 go 的协程池 (任务池)

    go 的 goroutine 提供了一种较线程而言更廉价的方式处理并发场景, go 使用二级线程的模式, 将 goroutine 以 M:N 的形式复用到系统线...

    会呼吸的Coder

扫码关注云+社区

领取腾讯云代金券