作者:360威脅情報中心
公眾號:360威脅情報中心

背景

2018年8月24日,360威脅情報中心捕獲到一個專門為烏克蘭語使用者設計的釣魚文檔:該文檔為RTF文件格式,且有詳細的文檔內容。360威脅情報中心經過分析確認這是首次發現的針對Office公式編輯器特殊處理邏輯而專門設計的用于繞過殺毒軟件查殺的漏洞利用樣本,涉及的漏洞正是CVE-2017-11882。

由于漏洞觸發后的Payload已失效,360威脅情報中心在本文中專門針對樣本使用的特殊免殺技術進行詳細分析,并提醒各殺毒軟件廠商做好針對該利用方式的檢測。由于該免殺技術已經出現在在野利用的樣本中,后續可能會有大量實際攻擊樣本使用該免殺手段逃過殺軟檢測,形成新的威脅。

文檔內容

Google內容翻譯

免殺效果及樣本特點

免殺效果

捕獲到的樣本在VirusTotal上查殺效果如下,首次上傳時僅有4家殺軟可以查殺,且僅有兩家殺軟能正確識別漏洞,如果稍加改動幾乎可以躲過所有殺軟的查殺:

樣本特點-特殊的公式對象OLE

捕獲到的特殊樣本在RTF控制字“\objdata”的header后面居然不是一個Compound File Binary Format(復合二進制文檔)流,其緊跟的直接就是公式對象的數據(MTEF data),甚至連公式對象的頭部數據(Equation Native Header)都沒有:

而這樣一個“畸形”的CVE-2017-11882漏洞利用文檔,竟然能成功觸發漏洞利用。

我們先復習一下正常的RTF文檔中利用Office公式編輯器漏洞的方式,以CVE-2017-11882為例:

首先,RTF文檔中會被插入一個objdata,緊跟在RTF控制字“\objdata”后,隨后的數據結構為4字節的版本標識、format_id(embed代表嵌入式)、OLE流名字(Equation.3)等等:

Header:

01050000                    // version

02000000                    // format_id (embed)

0b000000

4571756174696f6e2e3300      // "Equation.3" could be anything

0000000000000000

410f0000                        // data length

在“\objdata”的header后緊跟OLE對象流,可以看到其特殊的Compound File Binary Format(復合二進制文檔)標識:D0 CF 11 E0 …

緊跟的OLE對象流是一個復合二進制文件(Compound File Binary Format),通過解析可以看到這是一個Office 公式3.0編輯器對象,Root Entry帶有一個公式編輯器的CLSID {0002CE02-0000-0000-C000-000000000046}:

包含的Office 公式3.0編輯器對象由公式頭+公式數據組成:

360威脅情報中心針對該特殊的漏洞利用技術進行了詳細分析,整個分析過程如下。

Office處理RTF中\objdata對象的流程

帶著Office為什么可以正確處理嵌入的非OLE對象(且該對象是一個沒有公式頭的公式對象)這一疑問,我們詳細分析了Office處理RTF文檔中嵌入的\objdata對象的過程,整個處理過程可以用以下流程圖表示:

從整個流程來看,當WINWORD.EXE加載RTF文件并解析RTF文件格式后會調用函數ole32!OleConvertOLESTREAMToIStorage將指定的對象從OLE 1存儲模型轉換為OLE 2結構化存儲對象。其內部調用的ole32!wConvertOLESTREAMTOIStorage負責從RTF文件中解析、轉換OLE 1對象到OLE 2存儲對象,最后ole32! GenericObjectToIStorage函數負責將OLE 2存儲對象通過剪切板的方式傳送給EquEdt32.exe進程處理:

首先ole32!wConvertOLESTREAMTOIStorage函數將具體事務交給Ole32! OLESTREAMToGenericObject:

Ole32! OLESTREAMToGenericObject函數會完成OLE 1對象讀取及轉換,內部會調用OLE1StreamToUL和OLE1StmToString(內部也調用OLE1StreamToUL函數)讀取OLE1對象Version、format_id、Class Name(Prog ID)、static object、linked nor an embedde、topic、Item、NativeData等信息,也就是處理\objdata的header部分:

同樣可以通過oletools的rtfobj工具查看對應的\objdata得到相同信息:

進一步會判斷format_id是否為FMTID_EMBED(linked nor embedde),然后調用wCLSIDFromOle1Class函數讀取Ole1對象的CLSID:

wCLSIDFromOle1Class函數判斷傳入的szProgID是否是名字為“OLE2Link”的對象,如果是則返回CLSID_StdOleLink,否則交給代理函數CLSIDFromOle1Class轉換Ole1的流名字到對應的CLSID(也就是轉換流名稱Equation.3到對應的clsid):

CLSIDFromOle1Class交給代理函數wCLSIDFromOle1Class處理:

wCLSIDFromOle1Class函數將打開注冊表HKEY_CLASSES_ROOT\[szProgID](此處為HKEY_CLASSES_ROOT\Equation.3)查詢其CLSID,如果查詢成功則調用wGUIDFromString函數得到GUID返回:

如果通過流名稱查詢不到CLSID則調用Ole10_CLSIDFromString函數遍歷OLE32中內置的Object名稱,發現相同則返回其CLSID:

ole32! GenericObjectToIStorage函數根據返回的CLSID注冊剪切板,并把OLE 2數據寫入剪切板:

隨后WINWORD.EXE會調用ole32!Load函數加載該CLSID對應的對象,最終定位到函數ole32!CoIsOle1Class,該函數判斷CLSID是不是有效的Ole1Class對象,不是有效的Ole1Class對象則直接返回,是有效的Ole1Class對象則調用接口處理剪切板數據,以下是加載處理公式對象的過程:

特別注意的是,WINWORD.EXE在調用ole32!OleLoad函數前,會解析CFB文件將CFB文件的流對象寫入剪切板并且將Embedded對象數據塊(即d0cf11e0a1b11ae10對應的塊)的Clsid值覆蓋之前通過ProgID獲取的Clsid,也就是最終以Embedded對象數據塊內的clsid為準:

公式編輯器(Equation)處理公式數據的特殊邏輯

最后,Office將公式對象數據傳遞給Equation處理:

EquEdt32.exe進程能夠處理兩種流,分別是Equation Native和01Ole10Native流,Equation Native是較為常見的流格式,一般以0x1C開頭。而01Ole10Native流在EquEdt32.exe打開Equation Native流失敗的情況下才使用:

隨后會根據打開的流讀取流內容, 如果是01Ole10Native流則先讀取4字節流大小,如果不是則讀取0x1C字節大小的Equation Native頭,然后才從Equation Native頭解析流01Ole10Native大小,最后分配內存用于讀取01Ole10Native流數據:

可以看到,本次捕獲到的免殺樣本在處理過程中,由于讀取Equation Native失敗,所以Equation通過讀取01Ole10Native流大小來直接處理后面附加的公式數據(03010103…):

隨后再次調用IStream::Read(coml2!CExposedStream::Read)函數讀取流數據:

最后將流數據傳入sub_42F8FF函數實現具體01Ole10Native流處理,最終成功觸發漏洞:

總結免殺原理

我們回顧Office處理RTF中\objdata對象的流程可以總結出該免殺樣本觸發Equation漏洞的過程:

  1. 攻擊者在\objdata后附帶非CFB格式的數據(只有公式數據的01Ole10Native流),迫使Office通過\objdata header中的流名字(Equation.3)來查找對應處理的clsid,轉入處理流程。

  2. 由于附帶的是公式對象的01Ole10Native流(030101…部分數據),所以EquEdt32.exe進程打開Equation Native流失敗,轉而以\objdata header中指定的數據長度直接處理01Ole10Native流,觸發漏洞利用。

由于該免殺樣本\objdata后附帶非CFB格式的數據(D0 CF 11…),而正常情況必然是攜帶的CFB數據,并且以CFB數據中獲取的clsid為準尋找處理該對象的程序(如Equation),這直接導致繞過大部分殺軟的檢測邏輯。并且后續的公式數據沒有公式對象頭等特征,也使得部分殺軟抓瞎,這是該樣本繞過殺軟檢測的主要原因。

IOC

MD5
0a8efb742ef488bcb8ccd6b616125eea

參考

[1].https://ti.360.net

[2].https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-11882

[3].https://github.com/Paolo-Maffei/OpenNT/blob/5c5b979ec08c17d3ca2eb70e8aad62d26515d01c/com/ole32/ole232/ole1/ostm2stg.cpp


Paper 本文由 Seebug Paper 發布,如需轉載請注明來源。本文地址:http://www.bjnorthway.com/699/