您好,登錄后才能下訂單哦!
今天就跟大家聊聊有關利用Office公式編輯器特殊處理邏輯的最新技術分析是怎樣的,可能很多人都不太了解,為了讓大家更加了解,小編給大家總結了以下內容,希望大家根據這篇文章可以有所收獲。
2018年8月24日,360威脅情報中心捕獲到一個專門為烏克蘭語使用者設計的釣魚文檔:該文檔為RTF文件格式,且有詳細的文檔內容。經過分析確認這是首次發現的針對Office公式編輯器特殊處理邏輯而專門設計的用于繞過殺毒軟件查殺的漏洞利用樣本,涉及的漏洞正是CVE-2017-11882。
由于漏洞觸發后的Payload已失效,360威脅情報中心在本文中專門針對樣本使用的特殊免殺技術進行詳細分析,并提醒各殺毒軟件廠商做好針對該利用方式的檢測。由于該免殺技術已經出現在在野利用的樣本中,后續可能會有大量實際攻擊樣本使用該免殺手段逃過殺軟檢測,形成新的威脅。
文檔內容
Google內容翻譯
捕獲到的樣本在VirusTotal上查殺效果如下,首次上傳時僅有4家殺軟可以查殺,且僅有兩家殺軟能正確識別漏洞,如果稍加改動幾乎可以躲過所有殺軟的查殺:
捕獲到的特殊樣本在RTF控制字“\objdata”的header后面居然不是一個CompoundFile 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 // version02000000 // format_id (embed)0b0000004571756174696f6e2e3300 // "Equation.3" could be anything0000000000000000410f0000 // data length
在“\objdata”的header后緊跟OLE對象流,可以看到其特殊的CompoundFile Binary Format(復合二進制文檔)標識:D0 CF 11 E0 …
緊跟的OLE對象流是一個復合二進制文件(Compound File Binary Format),通過解析可以看到這是一個Office 公式3.0編輯器對象,RootEntry帶有一個公式編輯器的CLSID {0002CE02-0000-0000-C000-000000000046}:
包含的Office 公式3.0編輯器對象由公式頭+公式數據組成:
360威脅情報中心針對該特殊的漏洞利用技術進行了詳細分析,整個分析過程如下。
帶著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、ClassName(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為準:
最后,Office將公式對象數據傳遞給Equation處理:
EquEdt32.exe進程能夠處理兩種流,分別是Equation Native和01Ole10Native流,Equation Native是較為常見的流格式,一般以0x1C開頭。而01Ole10Native流在EquEdt32.exe打開Equation Native流失敗的情況下才使用:
隨后會根據打開的流讀取流內容, 如果是01Ole10Native流則先讀取4字節流大小,如果不是則讀取0x1C字節大小的EquationNative頭,然后才從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通過\objdataheader中的流名字(Equation.3)來查找對應處理的clsid,轉入處理流程。
2、 由于附帶的是公式對象的01Ole10Native流(030101…部分數據),所以EquEdt32.exe進程打開EquationNative流失敗,轉而以\objdata header中指定的數據長度直接處理01Ole10Native流,觸發漏洞利用。
由于該免殺樣本\objdata后附帶非CFB格式的數據(D0 CF 11…),而正常情況必然是攜帶的CFB數據,并且以CFB數據中獲取的clsid為準尋找處理該對象的程序(如Equation),這直接導致繞過大部分殺軟的檢測邏輯。并且后續的公式數據沒有公式對象頭等特征,也使得部分殺軟抓瞎,這是該樣本繞過殺軟檢測的主要原因。
看完上述內容,你們對利用Office公式編輯器特殊處理邏輯的最新技術分析是怎樣的有進一步的了解嗎?如果還想了解更多知識或者相關內容,請關注億速云行業資訊頻道,感謝大家的支持。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。