又出新玩法？微軟公式編輯器系列漏洞新利用方式

前言

此前，微軟發布的月度安全更新中修復了多個最新的Office漏洞(CVE-2017-11882，CVE-2018-0798 和CVE-2018-0802)。該漏洞為Office公式編輯器的最新漏洞，微軟對此的處理方式是將該模塊刪掉。

然而即使模塊在最新版本中被刪掉，仍然有大量攻擊者在利用CVE-2017-11882+CVE-2018-0802的漏洞文檔進行攻擊。

而就在3月18日，安全研究團隊捕獲到一些奇怪的RTF樣本。這批樣本相比較CVE-2018-0802傳統利用方式而言，採用了一種新的利用方式，能夠繞過市面上大多數殺軟，並且即使部分殺軟能查殺，也無法正確識別漏洞。

下圖為VT報警信息。

首先，經過分析，我們發現這批樣本有一個通用特徵：都內嵌了一個CFBF(Compound File Binary Format)對象，將該文件提取後發現只有一個「x01Ole10Native」流。

在文本編輯器中瀏覽該文件也未發現明文的URL，文件路徑或是命令等信息。

經過分析，我們發現這批樣本是公式編輯器系列漏洞的新利用方式。可以用於構造和CVE-2017-11882，CVE-2018-0802相同觸發機制，但靜態特徵更少的惡意樣本。

首先可以觀察到，這個CFBF對象的Root Entry帶有一個CLSID 。

而這個CLSID對應的對象是Microsoft Equation 3.0，即該對象是一個公式3.0編輯器對象。

而在[MS-OLEDS]中可以查到「x01Ole10Native」流的結構。前四個位元組表示數據長度，後面的位元組流均為對應的數據。但是可以發現，這段數據的含義並不顯然。也許是shellcode，但是shellcode的頭部並不在偏移量為0的位置。

我們來回顧一下之前在CVE-2017-11882中，公式數據被載入和讀取的過程。

通過Unicode字元串」Equation Native」可以定位到數據流載入的過程。如下圖所示。

注意到這裡可能是對虛函數表的調用，28行的s_EquationNative是流名，則v10這個唯一的out變數應該對應於IStream，那麼a2應該對應於IStorage。

進行標註後得到以下結果。

我們來梳理一下圖中這一段的邏輯。

在第26~29行，公式編輯器首先嘗試從CFBF對象中讀取名為」Equation Native」的流。如果失敗(v11不為0)，則嘗試讀取名為「x01Ole10Native」的流。

在第35行，公式編輯器根據流的類型，從流中讀取不同大小的數據到一個變數中。如果流的類型是「Equation Native」，則讀取0x1C個位元組；如果流的類型是「x01Ole10Native」，則讀取4個位元組。根據之前對於CVE-2017-11882等漏洞的分析，可以得知這裡是在處理公式對象的OLE頭。

在第38行，判斷了數據的頭部是否正確。如果流的類型是「x01Ole10Native」，則不作任何檢查；如果流的類型是「Equation Native」，則判斷OLE頭的前兩個位元組是不是0x001C(小端序)，及隨後的四個位元組是不是0×00020000(小端序)。

在第4~43行，根據流的類型為接下來的公式數據分配內存空間。如果流的類型是「x01Ole10Native」，則流的前4個位元組([v9+0])就是數據大小；如果流的類型是「Equation Native」，則流的第8個位元組處的DWORD就是數據大小，而圖中的v14([esp+0x3C])正好是v13([esp+0x34])偏移量為8的位置。

在第5~53行，根據流的類型來讀入公式數據。對兩種流的處理實際是相同的。而在第66行的函數調用中，程序對讀入的公式數據開始進行處理。

也就是說，兩種不同的流，對應的數據，區別僅僅是數據頭：「EquationNative「流的數據頭是0x1C個位元組，而」x01Ole10Native」流的數據頭僅僅是4個位元組。

我們繼續回到樣本數據處進行查看。