检测网站安全隐患的软件：检测本地文件躲避安全分析

检测网站安全隐患的软件：检测本地文件躲避安全分析正如我们所看到的那样，该页面的内容来自于“res://ieframe.dll/dnserror.htm#http://invalidsite/”，其中“res:”表示的是资源，而这是IE浏览器用来从二进制文件中加载内部资源所用的方法。默认情况下，浏览器会假设资源文件存在于目录“windows/system32”之中，但是我们也可以修改这个路径。比如说，如果我们安装了Fiddler，我们就可以轻易地找出其中的一个有效资源，并将其提供给IE浏览器。接下来，我们就可以通过检测readystate事件来查看资源是否加载成功了。加载资源上个月，我们一直都在尝试弄清楚攻击者到底是如何通过检测目标系统中应用程序的相关MIME类型来对用户进行攻击的。如果目标计算机中安装了反病毒工具的话，恶意软件将拒绝下载恶意代码。这样一来，攻击者不仅可以保证恶意软件不会被检测工具所检测到，而且还可以在目标主机中潜伏很长的

翻译：WisFree

预估稿费：200RMB（不服你也来投稿啊！）

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

前言

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

漏洞概述

我们看得懂这个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事件。

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

安装补丁之前的PoC

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

关键代码如下所示，如果你愿意的话，你也可以直接下载一个可用的PoC[下载地址-密码：infected]。

1234567891011

<iframe src="https://img.aigexing.comres://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浏览器的话，你可以直接在线体验一下这个漏洞[传送门]。关键代码如下所示：

123456789

<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”页面。

关键代码如下所示：

12345678910

<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>

总结

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

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