回顧一下，前兩篇概述了一下IE的以下內容：IE的歷史，各個版本新增的功能、簡單的HTML渲染邏輯和網站掛馬對IE安全帶來的挑戰。
從這章開始，將繼續以網馬為契機，逐漸深入講述IE的漏洞分析與安全對抗的相關知識。 腳本先鋒系列將持續4章，前2章內會介紹網馬中常見的加密方式和處理對策。后續會介紹對Shellcode的分析，共2章。
網馬是離不開腳本的，上一章中也介紹了最基礎的混淆，或者更準確的說是編碼，因為escape的確就是為了編碼用的。
我想從實際發生過的網馬的例子來介紹這章的內容。
請看以上代碼。這個是發生在真實世界中的掛馬頁面。這些掛馬的服務器隨時有可能停止，所以我已將該頁面存檔，請見參考資料(1]（解壓密碼www.wooyun.org），附件1。由于是由掛馬頁面直接抓取，殺毒軟件可能會報告病毒，如果擔心安全問題，建議在虛擬環境內處理樣本。
這個網馬利用了VBScript整數溢出的漏洞（CVE-2014-6332）。這個著名的漏洞網上也已經有很多分析，如果不了解的話，大家可以參考下這些分析文章。 本章由于只是介紹腳本層面的內容，所以二進制分析將在后續章節進行，視所占篇幅挑選部分漏洞進行分析。
一下將對這一部分涉及到的腳本和攻擊點進行簡單講解。
在頁面最開始可以看到有一串META的標記，這是因為Internet Explorer 11中（Edge模式）已經不支持VBScript，可以看到為了兼容，掛馬代碼在最前面要求IE模擬IE8，這樣就可將渲染模式強行改為IE8，從而支持VBScript的執行。
#!html
<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感染的例子
該病毒感染的文件幾乎可以被所有殺毒軟件修復。
以上針對簡單的例子進行了講解，現在我們將看一些帶有混淆的例子。
這一節中的例子并不是十分困難，只要仔細觀察，是一定可以輕松解開的。一些比較難解的例子將在下一章中介紹。
讓我們看一看這個例子，詳情見附件3。這個腳本是CVE-2004-0204的一個利用代碼，取自以前的某個網馬記錄，乍一看這個東西代碼復雜而惡心無從下手，但是其實如果你記得上一章所說的，eval最終會執行第一個參數內的函數，而這里第一個參數就是一個function，因此只需要將eval替換為alert，執行即可得到內容：
紅框處即為木馬要下載的文件地址。
不過知其然不知其所以然不太好，讓我們簡單閱讀一下代碼：
可以看出來函數實際為：
#!javascript
eval(
function (p,a,c,k,e,d){} (p, a , c ,k ,e ,d)
)
這實際上是把這個擁有6個參數的匿名函數的返回值傳給了eval執行，因此返回值至少是解密過1次的代碼。
如果還是不了解，這么看你就明白了：
#!javascript
var a = function(){return 1}();
alert(a.toString());
最初（2007），除了極少的JS庫之外，這種代碼大多數都被用在掛馬上，不過之后，jspack倒是由于它有壓縮代碼的功能，被很多網站采用了。如果你也想生成這樣的代碼，不妨百度搜索一下eval壓縮。
這個頁面中（附件4），我們看到有一段加密的代碼十分奇怪，
通過閱讀代碼可知這段代碼其實就兩段：
定義函數xViewState()；
調用函數xViewState()。
通過閱讀函數xViewState，我們可以發現前半段都是在解密數據，而與頁面或者腳本有交互的地方僅有document.write一處，因此，將document.write替換成alert即可知道最后它要寫入頁面的內容。
請注意，document.write寫入DOM的內容會立即被渲染執行。
看來它是在寫入一段style信息，將.nemonn移動到-9999px top的地方，這表示這個內容將不在頁面的可視范圍內。為什么要這么做呢？想必你也知道了：掛黑鏈。
該頁面中另一處隱藏的地方，閱讀這個代碼也許你就更清楚它想干什么了：
圖：黑鏈不顯示在首頁的代碼
這種方式已經被Google列為打擊對象。用腳本加密的方式倒是可以算作是與Google的一個“對抗”。
鑒于javascript中可以輕易地劫持一個對象，因此我提供的工具中也有簡單的替換功能：
這是臭名昭著的Nuclear Exploit Kit的載入頁（學名Landing Page）一個較簡單的例子。
圖：Nuclear EP的Landing Page 觀察頁面（附件5），可以發現頁面結構類似：
#!html
<SCRIPT> ... </SCRIPT>
<ELEMENTS> DATA </ELEMENTS>
<SCRIPT> ... </SCRIPT>
三段，由于ELEMENTS的內容必然是不能執行的，所以分析的重點應該放在SCRIPT中間的內容。
先對第一段去混淆。可以發現代碼中注釋占了一半的篇幅，所以先批量刪除。
然后將JS代碼格式化，
然后稍作整理（附件6），可以看到此時幾乎已經很容易就能知道這段代碼做的什么了：
頁面的第三個SCRIPT塊（附件6， LN78）
#!html
<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的一些知識。
在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月最后一版，已不再維護
(3] https://www.blackhat.com/presentations/bh-usa-08/Kim/BH_US_08_Kim_Vista_and_ActiveX_control_WhitePaper.pdf
(4] http://blogs.msdn.com/b/ie/archive/2015/01/22/project-spartan-and-the-windows-10-january-preview-build.aspx