回顧一下，前兩篇概述了一下IE的以下內容：IE的歷史，各個版本新增的功能、簡單的HTML渲染邏輯和網站掛馬對IE安全帶來的挑戰。

從這章開始，將繼續以網馬為契機，逐漸深入講述IE的漏洞分析與安全對抗的相關知識。 指令碼先鋒系列將持續4章，前2章內會介紹網馬中常見的加密方式和處理對策。後續會介紹對Shellcode的分析，共2章。

III.1 HTML與網馬攻擊2 — 許可權問題

---

網馬是離不開指令碼的，上一章中也介紹了最基礎的混淆，或者更準確的說是編碼，因為escape的確就是為了編碼用的。

我想從實際發生過的網馬的例子來介紹這章的內容。

請看以上程式碼。這個是發生在真實世界中的掛馬頁面。這些掛馬的伺服器隨時有可能停止，所以我已將該頁面存檔，請見參考資料(1]（解壓密碼www.wooyun.org），附件1。由於是由掛馬頁面直接抓取，防毒軟體可能會報告病毒，如果擔心安全問題，建議在虛擬環境內處理樣本。

這個網馬利用了VBScript整數溢位的漏洞（CVE-2014-6332）。這個著名的漏洞網上也已經有很多分析，如果不瞭解的話，大家可以參考下這些分析文章。 本章由於只是介紹指令碼層面的內容，所以二進位制分析將在後續章節進行，視所佔篇幅挑選部分漏洞進行分析。

一下將對這一部分涉及到的指令碼和攻擊點進行簡單講解。

在頁面最開始可以看到有一串ME他的標記，這是因為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感染的例子

該病毒感染的檔案幾乎可以被所有防毒軟體修復。

III.2 HTML與網馬攻擊3 — 反混淆

---

以上針對簡單的例子進行了講解，現在我們將看一些帶有混淆的例子。

這一節中的例子並不是十分困難，只要仔細觀察，是一定可以輕鬆解開的。一些比較難解的例子將在下一章中介紹。

1. JS壓縮後的結果；

---

讓我們看一看這個例子，詳情見附件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壓縮。

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），可以發現頁面結構類似：

#!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的一些知識。

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月最後一版，已不再維護

(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