Equation漏洞混淆利用分析總結(上)
Office Equation類型的漏洞從2017年底開始被發現，到目前一共可用的有11882，0802，0798三個漏洞，可以說2018年office中使用最多的也是這三個漏洞，也是office中混淆利用最繁雜的一類漏洞（應該沒有之一），由於equation本身的問題導致這三個漏洞的在利用的混淆上有很多的變種，有意思的是這些混淆的技巧在三個漏洞中基本是通用的，本文通過幾個樣本來對這幾個漏洞的混淆利用進行一次總結。
首先無論是11882，0802，還是0798，一個正常的利用樣本的結構如下所示，即eqnolefilehdr，mtef head，mtef byte stread（這是EquationNative流的形式），當為Ole10Native流時，結構變為4字節+ mtef head，mtef byte stread。
mtef head正常情況如下所示，如上圖中的03 01 01 03 0A
之後的mtef record按類型一共包含14類，其中漏洞出在其中的type 5（matrix，0798），type 8（font，11882/0802中）
樣本一
Vt上也是報的11882，但是vt上大多報的不準，因此我決定確認一下到底是不是11882.
上調試器，來個斷點，11882溢出點斷下。
覆蓋返回地址。
進入shellcode。
現在基本確認是11882，如下紅框部分就是對應的equation head，mtef head，之後是對應的shellcode部分，長度47，符合11882的溢出長度，接下來一步一步看這個樣本是如何進行的混淆。
首先是equation head部分，在有Equationnative 流的情況下，這部分的長度為0x1c，以0x1c開頭，而值得註意的是綠色部分的值。
通過對比解析equation的流程就可以知道，讀取0x1c長度的頭部之後，會判斷其第二個字節開始的四字節的值是否小於0x20000，因此這個地方是一個混淆點，只要保證值小於0x20000即可。
可以看到之後的比較，之後的equation head中的內容實際是沒有太多要求的（至少在解析代碼的流程中是沒有看到對應的作用的）。
之後到metf head，這個和之前熟悉的03 01 01 03 0A完全不一致（之前的報告裏也遇到過，但第一個和第三個字節從文檔來看是不能變的，難道文檔有毒？）。
Metfhead的解析在以下函數。
進去之後發現，確實2，4，5位是沒有檢驗的，第一位是version，但是version是可以有多個值的，只要不小於2，不大於3即可，甚至當你大於了3，還有貼心的減掉100的機會，也就是說第一位可用的值有02，03，102，103，而該樣本中用的是02，因此符合判斷條件，而位於第三位的值如果不為01，則會進入到函數sub_4184A0中，該函數比較復雜，但是卻沒有相關異常的操作，即應該是可以正常返回的。
調試樣本可以看到metf第三位的值為a4，不等於1，會進入對應的函數流程。
但是該函數直接運行之後，似乎並不影響之後的程序。
因此可知，metf除了第一個字節有所要求外，其余字節也是可變的。
之後就對應的font部分，正常的情況一般為0A 08 00 00，可以看到這個地方基本都變了。
Metfhead check之後繼續往後讀取值，此時可以看到直接讀取的是01，之後進入正常的11882漏洞執行流程。
判斷前一步中讀取的是否為font的type 8，如果不是分兩個流程如果大於9，則依次再讀取下一個字節的內容（這也是之前11882普遍喜歡使用的一個混淆方式，即在08 type前插入任意大於9的字節，皆可起到混淆的作用，同時不影響漏洞的利用），第二種流程即小於9則直接返回，很明顯這個樣本屬於第二中情況，結合上面的調試，我們知道該樣本11882是利用成功的，即攻擊者使用了另外的執行流程來利用該漏洞（這樣做的好處是可以繞過hook指定函數檢測漏洞利用的方式）。
由於fun_CheckrecordHead是唯一的入口，因此我們在這個函數下斷點，看看到底還有哪個地方能導致漏洞觸發，結果如下所示，可以看到，入口是0798這個漏洞的入口。
那是如何進入到這個0798的觸發點的了？如上述所示正常流程的11882函數由於值為01，會直接返回，返回值為01，直接進入到switch中。
可以看到當case等於1時，進入到0798的漏洞函數。
繼續往裏。
此時可知，實際在進入0798的漏洞派發函數前，還有一次調用1188/0802的機會，熟悉0798的漏洞就應該知道，實際上前面的地方除了01外，04也是可以導致進入0798的，因此這個地方的混淆可以有01，04兩種選擇，本質上確是通過0798中MATRIX record觸發的11882/0802漏洞。
08之後的兩個字節實際上也沒用，因此也是可混淆的。
樣本二
這個樣本中可以看到metf的第一位為被設為66（102），比較有趣的是藍色部分，可以看到其使用了01的標記用於進入到0798的流程，通過0798進入對應的11882.此時中間有11，22，33，44四個字節的混淆字節，F8為font tag。
校驗完meft head頭，讀取type類型，由於此處的類型為01，所以正常的11882漏洞流程直接將其返回，進入之後的case 1流程。
在case1流程中，進入0798函數。
0798函數中包含了11882流程，進入並傳入11參數，11882直接返回1，dispatch函數進入case 0流程。
Case 0 流程進入的函數如下所示，if 判斷成功，直接返回，需要註意的是else中實際也是一處可供利用點，下兩處紅框中的函數都是可以進入到11882/0802漏洞觸發流程的（需要註意的是這樣利用依賴與a4的值，因此需要特殊構造）。
Case 0流程執行完畢，dispatch函數返回，循環再次讀取下一位，此時讀取22，並再次進入dispatch函數。
22作為11882漏洞函數流程參數，直接返回2，進入dispatch 1流程。
Case 1流程的處理函數如下，首先通過函數sub_43B449A再次往下讀取一位，即33，函數中通過判斷讀取的值減掉0x80的值來判斷返回1還是其他（依賴於一塊內存變量word_45ABE6），此處返回0，之後判斷版本，及sub_43B449A的返回值，由於返回值為0，這將導致if 判斷失敗，進入else流程，else中再次讀取一位，即44，最終進入最後的0798流程，此時0798中讀取F8，最終進入到11882的利用流程。
sub_43B449A函數如下，可以看到通過33這個位置的值是可以在一定程度上控制返回值的，0x89，0x90可以保證返回1，其余情況則依賴於word_45ABE6這個位置的值。
實際上如果能控制sub_43B449A，及sub_420AE3 ，sub_44B324的返回值，進入if同樣也是一條11882的觸發流程，但是目前來看難度較高。主要是首先需要保證sub_43B449A的返回值小於0，這就要求word_45ABE6這個位置可控。
word_45ABE6引用的地方如下，在fun_shell1_11882進行了設置。
但是需要註意的是該函數是在11882流程裏，且在利用返回後設置，因此word_45ABE6的值控制起來沒有任何意義。
由上文的分析可知，11882/0802這兩個函數有多種可能的觸發方式，除了常規的ParseMTEFData外，其實大部分都集中在0798的dispatch函數中。
轉載請註明出處
Equation漏洞混淆利用分析總結(上)