回顾一下，前两篇概述了一下IE的以下内容：IE的历史，各个版本新增的功能、简单的HTML渲染逻辑和网站挂马对IE安全带来的挑战。
从这章开始，将继续以网马为契机，逐渐深入讲述IE的漏洞分析与安全对抗的相关知识。 脚本先锋系列将持续4章，前2章内会介绍网马中常见的加密方式和处理对策。后续会介绍对Shellcode的分析，共2章。
III.1 HTML与网马攻击2 — 权限问题
网马是离不开脚本的，上一章中也介绍了最基础的混淆，或者更准确的说是编码，因为escape的确就是为了编码用的。
我想从实际发生过的网马的例子来介绍这章的内容。
请看以上代码。这个是发生在真实世界中的挂马页面。这些挂马的服务器随时有可能停止，所以我已将该页面存档，请见参考资料(1]（解压密码www.wooyun.org），附件1。由于是由挂马页面直接抓取，杀毒软件可能会报告病毒，如果担心安全问题，建议在虚拟环境内处理样本。
这个网马利用了VBScript整数溢出的漏洞（CVE-2014-6332）。这个著名的漏洞网上也已经有很多分析，如果不了解的话，大家可以参考下这些分析文章。 本章由于只是介绍脚本层面的内容，所以二进制分析将在后续章节进行，视所占篇幅挑选部分漏洞进行分析。
一下将对这一部分涉及到的脚本和攻击点进行简单讲解。
在页面最开始可以看到有一串META的标记，这是因为Internet Explorer 11中（Edge模式）已经不支持VBScript，可以看到为了兼容，挂马代码在最前面要求IE模拟IE8，这样就可将渲染模式强行改为IE8，从而支持VBScript的执行。
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" >
接着，这个页面中出现了两块SCRIPT标签：
可能有的同学会对代码执行的优先顺序产生疑惑，在IE中脚本的执行顺序是：
（1）谁的块（SCRIPT）在前面谁先执行；
（2）各个分块中，函数优先被解析，但是不执行，函数解析完成后，从最外层的Public代码的第一行开始执行；
（3）各个分块中如果没有容错语句，遇到错误的代码之后，该分块后面的代码不会运行。但是不会影响到其他分块的内容；
（4）在Javascript中，容错代码是try{}catch(...){}，在VBScript中，容错代码即为：On Error Resume Next；
这样，可以看到第一节中定义了一个函数，函数中会调用CreateObject创建wscript.shell， Microsoft.XMLHTTP，ADODB.Stream三个对象。
这三个对象的GUID分别是：
Wscript.shell: 72C24DD5-D70A-438B-8A42-98424B88AFB8
Microsoft.XMLHTTP: ED8C108E-4349-11D2-91A4-00C04F7969E8 *(progid: Microsoft.XMLHTTP.1.0)
ADODB.Stream: 00000566-0000-0010-8000-00AA006D2EA4
在注册表中查看这Wscript.shell、ADODB.Stream的guid，你会不约而同的发现：
对了，这两个ActiveX对象的Safe for script和Safe for init均被设置为了False，这使得他们无法在Internet zone被加载，而在本地域下，使用它们的话，Internet Explorer会弹出：
Internet 域默认的是中-高级别，在此级别下，这类脚本会被禁止执行（同时触发一个异常）。
漏洞如果成功执行，会把安全检查的开关关闭，导致这些原先被标记为不安全的对象全部都可以成功创建并运行，这样甚至不需要理会任何现有防御机制（例如ASLR等）即可攻击用户电脑。
可以看到该网马最后运行了这个函数。这个函数即会下载一个EXE并运行。该EXE即为木马程序。
而其他的，该网马最后还有这么一句，首先是创建一个iframe指向木马exe：hxxp://116.255.195.114/server.exe，然后又用window.open()打开一个新窗口，url也是这个exe。
这两个语句的结果都是让IE（其他浏览器也是如此）弹出来一个下载提示：
这是坑用户的最后一步，只要用户不点运行就没有问题，而且这个URL几乎被国内的所有杀软都入库了，想必也不会骗到多少人。
需要注意的是该网站还有一个1.js，这个js文件404了，内容我们不得而知。不过看前面这么明显的“js挂马”字样，也许作者是把这个js的内容也一起并到了这个网页中也说不定。
最终，我们知道了，这个网页是想要让用户下载server.exe。仅仅从杀软的报告来看，这个exe是一个远控程序。针对此类体积适中的木马程序，比较简易和方便的调试环境是Sandboxie+OllyDbg，或者VMWare+调试工具，后者可能占内存较多，前者比较轻量也很容易整理。但是需要注意不要被有些病毒样本穿出了沙箱从而影响到真实系统。这部分内容不在本系列的介绍范围内，不详细叙述了。
在搜刮今天的挂马网站列表的时候，我还看到了如下例子（附件 2），这是类似熊猫烧香的一个病毒Ramnit感染的，他就是我之前说的，给每个html都挂上一段脚本，这个脚本需要本地权限才可以提示执行，不过万一用户点击允许了呢，这样，这个病毒就会重新死而复生了（也许这段代码和上面CVE-2014-6332配合起来才更好）：
图：Ramnit感染的例子
该病毒感染的文件几乎可以被所有杀毒软件修复。
III.2 HTML与网马攻击3 — 反混淆
以上针对简单的例子进行了讲解，现在我们将看一些带有混淆的例子。
这一节中的例子并不是十分困难，只要仔细观察，是一定可以轻松解开的。一些比较难解的例子将在下一章中介绍。
1. JS压缩后的结果；
让我们看一看这个例子，详情见附件3。这个脚本是CVE-2004-0204的一个利用代码，取自以前的某个网马记录，乍一看这个东西代码复杂而恶心无从下手，但是其实如果你记得上一章所说的，eval最终会执行第一个参数内的函数，而这里第一个参数就是一个function，因此只需要将eval替换为alert，执行即可得到内容：
红框处即为木马要下载的文件地址。
不过知其然不知其所以然不太好，让我们简单阅读一下代码：
可以看出来函数实际为：
eval(
function (p,a,c,k,e,d){} (p, a , c ,k ,e ,d)
)
这实际上是把这个拥有6个参数的匿名函数的返回值传给了eval执行，因此返回值至少是解密过1次的代码。
如果还是不了解，这么看你就明白了：
var a = function(){return 1}();
alert(a.toString());
最初（2007），除了极少的JS库之外，这种代码大多数都被用在挂马上，不过之后，jspack倒是由于它有压缩代码的功能，被很多网站采用了。如果你也想生成这样的代码，不妨百度搜索一下eval压缩。
2、简单的代码阅读
这个页面中（附件4），我们看到有一段加密的代码十分奇怪，
通过阅读代码可知这段代码其实就两段：
定义函数xViewState()；
调用函数xViewState()。
通过阅读函数xViewState，我们可以发现前半段都是在解密数据，而与页面或者脚本有交互的地方仅有document.write一处，因此，将document.write替换成alert即可知道最后它要写入页面的内容。
请注意，document.write写入DOM的内容会立即被渲染执行。
看来它是在写入一段style信息，将.nemonn移动到-9999px top的地方，这表示这个内容将不在页面的可视范围内。为什么要这么做呢？想必你也知道了：挂黑链。
该页面中另一处隐藏的地方，阅读这个代码也许你就更清楚它想干什么了：
图：黑链不显示在首页的代码
这种方式已经被Google列为打击对象。用脚本加密的方式倒是可以算作是与Google的一个“对抗”。
3、工具处理
鉴于javascript中可以轻易地劫持一个对象，因此我提供的工具中也有简单的替换功能：
4、Exploit Kit示例
这是臭名昭著的Nuclear Exploit Kit的载入页（学名Landing Page）一个较简单的例子。
图：Nuclear EP的Landing Page 观察页面（附件5），可以发现页面结构类似：
<SCRIPT> ... </SCRIPT>
<ELEMENTS> DATA </ELEMENTS>
<SCRIPT> ... </SCRIPT>
三段，由于ELEMENTS的内容必然是不能执行的，所以分析的重点应该放在SCRIPT中间的内容。
先对第一段去混淆。可以发现代码中注释占了一半的篇幅，所以先批量删除。
然后将JS代码格式化，
然后稍作整理（附件6），可以看到此时几乎已经很容易就能知道这段代码做的什么了：
页面的第三个SCRIPT块（附件6， LN78）
<script>aiTsnQh(EOHCnD("iaTyv"));</script>
事实上调用了EOHCnD 这个函数，这个函数的定义是：
阅读可知，
LN29：生成对象document；
LN30：调用document[”getElementById”](divId).innerHTML[”replace”](/[ ]/g,’’)将空格删除；
LN32-33： 实际是substr的混淆；
LN37-50：从第一个字节开始，每2个字substr一下，转为数字，如果小于10原样不动，大于10的话-2，然后保存在MvBLCx变量中
LN52： 返回解密后的字符。
也就是说，很简单，这个EOHCnD就是解密的函数，因此，我们执行页面并把它的返回值输出即可。
第三个SCRIPT块改为Console.log：
得到解密后的内容（附件 7）。该脚本会将参数传给漏洞利用程序（SWF， 附件8）来执行。SWF的内容之后再提。
以上就是本章内所有解密内容，大家可以对照附件的恶意脚本进行一些解密试验。接下来，再概述一下IE中ActiveX的一些知识。
III.3 IE渲染网页时ActiveX处理方式和安全限制
在IE渲染网页时，ActiveX对象一直是漏洞挖掘者喜闻乐道的东西。ActiveX控件是指基于COM（微软的组件对象模型）设计出来的一种可以重用的组件。因为它能“Active”在各种东西上，所以大概就因此叫了这个名字。
ActiveX控件可以通过<OBJECT>标签，或者脚本中CreateObject或者new ActiveXObject的方式创建一个实例。
图：XP下CVE-2010-0886溢出漏洞的利用代码，正在向对象传入一个过长的docbase参数
ActiveX对象是一个二进制文件，那么如果这个二进制文件中包含有一些危险操作，那么必然可以对用户机器做一些不好的事情。因为ActiveX控件几乎可以做所有普通程序可以做的事情，所以恶意的ActiveX将是十分致命的，尤其是在IE中加载起网页指定的ActiveX控件，安全和便利又因此发生了冲突，是好是坏赞否两论。
关于它的反面说法其一是由于“历史问题”，XP下ActiveX与IE权限等同，且大部分人都是管理员权限登录的，所以导致ActiveX也有管理员权限。该问题在Vista引入的IE保护模式中得到改善。
简单介绍一下ActiveX的安全标记Safe For Scripting。标记为Safe For Scripting的控件理应不会被任何不信任的脚本（简单说就是别人提供的，开发者也无法预见的内容）恶意利用，比如泄露隐私，执行文件，或者干脆干扰了其他软件正常功能。
还有一个就是参数的传入，当传入的初始化数据是不可信的时候（比如我指定一个控件背景色是RGB(999, -1, "abc")的时候），插件也不能崩或者因此就不工作了（Safe For Initializing），谁知道用户会传给你什么呢。
要想让ActiveX可以参与IE的脚本互动，必须要确保对任何脚本宿主来说这个插件都能安全执行，也要把插件注册为“Safe For Scripting”。
有两种方式可以这么来，一是在注册表中写入键值，二是继承IObjectSafety接口（ATL也提供了个IObjectSafetyImpl方便你操作）。
图：一个控件使用IObjectSafety的例子
IObjectSafety有GetInterfaceSafetyOptions、SetInterfaceSafetyOptions这对函数，GetInterfaceSafetyOptions应当返回ActiveX控件的安全特性（Safe For Init？Safe For Scripting？），SetInterfaceSafetyOptions由宿主调用，告诉控件应当具有什么安全特性。
图：IObjectSafety的定义，参考VC运行库中objsafe.h的具体代码
图：GetInterfaceSafetyOptions的实现，参考VC运行库中atlctl.h的具体代码
这部分的具体内容可以参考《COM本质论》。
让我们简单讨论一下ActiveX在IE中的实现，之前说到，<XX>括起来的元素多是继承了CElement，<OBJECT>也不例外，OBJECT对应的类为CObjectElement，继承于CElement。
在解析到OBJECT时，该对象会：
1. 试图读取参数，找到CLSID和其他参数信息；
2. 读取CODEBASE的值并解析存入Property Bag，这个值可以是：
2.1 绝对URL；（http://drops.wooyun.org/xx.cab#version=xxx）
2.2 相对URL；（xx.cab#version=xxx）
2.3 无URL；（#version=xxx）
3. 读取其他参数并解析，存入Property Bag；
4. 加载该OBJECT；
在加载OBJECT时，IE会：
1. 检查缓存，这个缓存会缓存一些指向IDispatch的指针，如果已经命中缓存了，这次就不需要再去Query了；
2. 确保ActiveX控件可以安全加载（SafeForScripting）且可以访问；如果这步检测失败，IE会返回E_ACCESSDENIED。
IsSafeToScript 是COleSite的一个函数，该函数会：
1. 检查用户是否已经关闭了ActiveX的安全检测（检查域是否设置了URLACTION_ACTIVEX_OVERRIDE_SCRIPT_SAFETY）；
图：MSDN，https://msdn.microsoft.com/en-us/library/ms537178.aspx
2. 如果当前内容是Java Applet，检查用户是否允许Applet加载，不允许直接返回禁止；
3. 检查控件的IObjectSafety属性，标记为Safe For Scripting时通过；
4. 当标记为不通过且用户选择提示时，弹出提醒，告诉用户要加载的ActiveX插件不安全；
5. 安全时载入该控件。
以上就是IE加载ActiveX控件时的通用动作，下面我们再简单介绍一下IE针对ActiveX控件做的一些安全改进：
自IE7开始，引进了Activex Opt-In，这个功能的作用是：默认关闭大部分的ActiveX，当网站请求执行某个ActiveX控件的时候，IE会弹一个信息条：
图：信息条，via Google Image
图：安全警告，via Google Image
当用户确定时，这个控件才会加载。
这些插件不属于“大部分”之列：
a. 升级到IE7之前已经用过的插件；
b. IE7预存了一个白名单，这里面都是经过检验的，而且很多都是常见的ActiveX；
c. 用户在浏览器中下载并安装的控件；
图：白名单，位置：HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Ext\PreApproved
2、IE8 （+Vista）引入了Per-User (Non-Admin) ActiveX，它允许用户以非管理员权限安装ActiveX控件，微软声称此举是为了让用户更好的使用UAC特性，因为如果你以普通用户权限安装了一个恶意的ActiveX控件，除了影响当前用户，整体的系统安全倒不会受到严重影响，因为这个ActiveX控件也是和当前用户一个权限。
IE8中，ActiveX也可以按网站开启。从这个时候开始，KillBits功能还被整合进了Windows Update，这样微软就可以在ActiveX出现问题之后收拾残局。
Vista中IE还引入了保护模式，保护模式下IE运行在低完整性级别，这意味着即使ActiveX被攻破，也不能写入一些敏感数据。
3、IE9中，增加了ActiveX Filtering功能，可以让用户在所有网站禁止运行控件而不会弹出提示。
4、IE10 中ActiveX控件的加载会经历多个检测，包括组策略，权限检查等；ActiveX控件有和浏览器等同的权限。当开启EPM之后，只有支持EPM（同时有支持32/64位文件，且兼容AppContainers）的ActiveX控件才会被加载。
5、IE11 （+Windows 8）会自动扫描ActiveX并阻止恶意ActiveX运行。
同时，微软还推送了一些Out-Of-Date ActiveX功能，这个估计是学的Chrome和Firefox，把一些过时的ActiveX屏蔽掉。
6、 Spartan（IE12），不支持ActiveX和BHO。
而是用一个“扩展系统”来安装。“旧风格”（内网，需要旧版本支持的网站）网站使用IE11来渲染。(4]
可见，微软对自己的这套东西是有多爱就有多恨，至于Spartan到底能不能完成这一系列的安全进步和兼容性过渡，就要看微软之后到底怎么完善它的“扩展系统”了，是变得更安全还是又多一个烂摊子，让我们拭目以待。
附 参考资料
(1]下载地址本文中所有例子，解压密码www.wooyun.org
(2]下载地址自己写的Redoce 3解密工具，2013年3月最后一版，已不再维护