【漏洞分析】關於 OLE 漏洞的簡單總結

OLE 全稱是對象鏈接和嵌入，
OLE 漏洞的產生一般也來自鏈接對象和嵌入對象兩個方面，
談 OLE 漏洞可以從 OLE文檔的加載過程開始講：
比如你打開一個 OLE文檔，那麼其加載過程分爲兩步，
① 初始化 OLE 對象(包括兩個攻擊面)
② 執行 Verb 動作(包括一個攻擊面)

兩個步驟中共包括了三個攻擊面（如上三個步驟都可以被攻擊）：
第一步：初始化 OLE對象：
如何初始化 OLE 對象呢，
是通過 OLE32 這個 DLL 中的 OleLoad() 函數實現的(自己看下導出表)
該函數的執行包含6個步驟，
其中有兩步分別調用了 CoCreateInstance() 和 IpersistStorage::Load 方法
CoCreateInstance() 函數（攻擊點一）：
第一個參數是 CLSID，指定了具體是哪一個 OLE 對象，
這個 CLSID 可以首先在文檔的二進制數據中讀取到一個 ProgID，
然後將 ProgID 轉換成 CLSID，具體轉換方法是通過兩個函數 ProgIDFromCLSID CLSIDFromProgID，
也可以在註冊表中直接搜索 ProgID ： Package或者OLE2Link ，
可以很快定位到ProgID是 Package或OLE2Link 的 CLSID，
這樣 CocreateInstance() 函數就獲取到了 CLSID，
可以創建一個用來初始化該 OLE 對象的處理器handler，
CoCreateInstance() 的作用和結果就是加載了與 CLSID 相關聯的 DLL 到進程中，
這也是很多 OLE 漏洞產生的原因，
只要給這個函數一個 CLSID，那麼它就會無腦加載該 CLSID 所屬的DLL到進程空間中，
後果就是攻擊者完全可以修改二進制數據中的ProgID 值，
以加載任何 DLL，只要這個DLL有關聯的 CLSID 在註冊表中，
這就大大增加了攻擊面,許多攻擊手段發生在“加載CLSID相關聯的DLL到進程中這一步”
比如說有這麼幾種利用手段：
1) 可以加載未開啓 ASLR 的 DLL 到 WOrd Excel PPT 的進程中，
配合堆棧溢出等漏洞進行攻擊
這裏需要注意的一點是：不光 CLSID關聯的 DLL會被加載進程中，
加載的 DLL 相關聯的未開啓ASLR的DLL也可以被自動加載到進程中
不過從 Office2013 開始強制開啓了 ASLR，這種利用手段就失效了
舉例：mscormmc.dll
這個 Win7 上的 DLL 默認沒有開啓 ASLR，
但是有很多 CLSID 與這個 DLL關聯，
構造一個帶有其中 CLSID 的含有 OLE對象的Office或者 RTF文檔，
就可以加載這個未開啓 ASLR 的 DLL 到進程當中
2) 可以造成內存破壞
3) 可以進行 DLL劫持
IpersistStorage::Load() 函數（攻擊點二）：
當 OLE 對象被確定之後，
也就是找到了對應的 CLISD，加載了 CLSID關聯的DLL到進程中，
OLE對象的 IPersistStorage 接口中的 Load() 函數被調用，
用來初始化 OLE 對象的初始狀態
這個“初始化”在我理解就是將序列化的 Storage Data進行分片讀取，獲取具體字段的值

第二步：執行“Verb”動作（攻擊點三）：
觸發“Verb”動作有兩種方法：
① 用戶點擊、雙擊插入的 OLE 對象，比如圖片、鏈接等
② “Verb”自動執行，比如 PPT中的某些動畫事件，又比如PPSX文檔一打開就是自動執行
這一步通常爲邏輯漏洞，
Verb 動作本質上是調用 IOleObject::DoVerb 方法完成的
IOleObject的 CLSID爲：00000112-0000-0000-C000-000000000046
可以在註冊表中搜索到，其實這可以被當做一個接口，
IOleObject 這個接口提供了24個方法，DoVerb只是其中一個方法。
容易受到攻擊的是DoVerb() 方法的第一個參數 iVerb,
iVerb的值可以在一些攻擊者可以控制的地方被定義，比如 PowerPoing Show 的 Animations 字段。