IE安全系列：腳本先鋒（I）

blast · 2015/04/22 10:11

回顧一下，前兩篇概述了一下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的執行。

#!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壓縮。

二、簡單的代碼閱讀

---

這個頁面中（附件4），咱們看到有一段加密的代碼十分奇怪，

經過閱讀代碼可知這段代碼其實就兩段：

定義函數xViewState()；
調用函數xViewState()。
複製代碼

經過閱讀函數xViewState，咱們能夠發現前半段都是在解密數據，而與頁面或者腳本有交互的地方僅有document.write一處，所以，將document.write替換成alert便可知道最後它要寫入頁面的內容。

請注意，document.write寫入DOM的內容會當即被渲染執行。

看來它是在寫入一段style信息，將.nemonn移動到-9999px top的地方，這表示這個內容將不在頁面的可視範圍內。爲何要這麼作呢？想必你也知道了：掛黑鏈。

該頁面中另外一處隱藏的地方，閱讀這個代碼也許你就更清楚它想幹什麼了：

圖：黑鏈不顯示在首頁的代碼

這種方式已經被Google列爲打擊對象。用腳本加密的方式卻是能夠算做是與Google的一個「對抗」。

三、工具處理

---

鑑於javascript中能夠輕易地劫持一個對象，所以我提供的工具中也有簡單的替換功能：

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

二、IE8 （+Vista）引入了Per-User (Non-Admin) ActiveX，它容許用戶以非管理員權限安裝ActiveX控件，微軟聲稱此舉是爲了讓用戶更好的使用UAC特性，由於若是你以普通用戶權限安裝了一個惡意的ActiveX控件，除了影響當前用戶，總體的系統安全倒不會受到嚴重影響，由於這個ActiveX控件也是和當前用戶一個權限。

IE8中，ActiveX也能夠按網站開啓。從這個時候開始，KillBits功能還被整合進了Windows Update，這樣微軟就能夠在ActiveX出現問題以後收拾殘局。

Vista中IE還引入了保護模式，保護模式下IE運行在低完整性級別，這意味着即便ActiveX被攻破，也不能寫入一些敏感數據。

三、IE9中，增長了ActiveX Filtering功能，可讓用戶在全部網站禁止運行控件而不會彈出提示。

四、IE10 中ActiveX控件的加載會經歷多個檢測，包括組策略，權限檢查等；ActiveX控件有和瀏覽器等同的權限。當開啓EPM以後，只有支持EPM（同時有支持32/64位文件，且兼容AppContainers）的ActiveX控件纔會被加載。

五、IE11 （+Windows 8）會自動掃描ActiveX並阻止惡意ActiveX運行。

同時，微軟還推送了一些Out-Of-Date ActiveX功能，這個估計是學的Chrome和Firefox，把一些過期的ActiveX屏蔽掉。

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