Equation漏洞混淆利用分析總結(下)

樣本三

如下所示在該樣本中，使用了Ole10Native的流，因此沒有equative head，默認讀取紅框中的4位長度。之后的metf head為01.

可以看到metf head的長度為01時，直接進入到if判斷中(該if中的函數實際是一個異常處理函數，但是當傳入的參數為45，145時不影響之后的漏洞利用)，之后讀取0A一位，因此當metf head的version為01時，實際的metf head的長度只有兩位。

往后讀取01，進入11882流程，導致直接返回，進入case流程。

進入case中的0798流程，讀取08，進入之后的fun_Matrixdispatch，此時進入fun_Matrixdispatch中的11882/0802流程。

樣本四

如下所示可以看到樣本使用的是常用的equationative流，長度為1c的字節，之后緊跟metf頭，但是咋看之下卻并不能確定其具體的漏洞cve，從metf之后的88字節來看，應該是對應的11882/0802漏洞

從vt上報的漏洞類型來看，大多數廠商的識別是0802系列，由于從上文所知，metf之后的構造擁有多種方式，因此我們就來看看這個漏洞是否真是0802.

可以看到fun_ParseMTEFData函數中，metf頭檢驗之后，向后讀取一字節，此時獲取的為0d，作為參數進入到正常的11882/0802流程，0d>09，因此函數直接跳過再次向下讀取。?

一直跳過0D 0A，直到藍色框中的01字節。

01被正常11882/0802返回，直接dispatch到case1中。

進入case1流程中的0798，向下再讀取一字節01。?

0798中由01 ?dispatch進入到case0流程。

如上文所示，在樣本二中提到進入該函數中實際上是有方法進入到對應的equation流程中，但是在當時的漏洞利用樣本中，該函數直接進入到if流程中，當時的分析中提到要進入else中需要相關的特殊構造，即a4等于1，else中實際是一個while循環，依次讀取并傳入到0798的dispatch中。

可以看到while循環中之后會讀取02的tag，在該tag中會以此處理之后的3個字節，樣本中一共構造了四對02的tag用于混淆，之后處理35tag，35tag->5，即tag 5，而tag5實際上就是0798的漏洞tag，因此基本可以證明該樣本使用的漏洞是0798.

如下所示，讀取對應的35位tag

導致dispatch到case4中，即對應的0798漏洞流程中。

0798函數中，以此向后讀取5字節的內容，其中第四，第五字節將導致溢出，即下圖中的20,80，之后分別以這兩字節內容為長度進行棧上數據的拷貝，一共調用兩次，最終兩段棧上數據連成一片，從而造成溢出。

第一次拷貝，參數為20，及0012f3fc，0012f3fc為目標棧上的地址。

第二次，拷貝，參數一為80，參數二為0012f404。可以看到第二次拷貝的地址在第一次拷貝的高地址出。

拷貝前的堆棧。

拷貝之后的堆棧，可以看到此時返回地址已經被覆蓋，但是這個覆蓋的數據是不是很奇怪，50505050這個地址并沒有意義，難道這只是測試樣本？但是從沙箱的結果來看樣本是執行成功的。

仔細再看一下漏洞函數可以發現，實際上在溢出之后，函數返回之前，還有相當一部分的操作，即之后的sub_4428F0函數，及之后的還有一次0798的操作，也就是還能向后讀取數據，結合對應的樣本數據，可以發現確實還能向后拷貝，sub_4428F0函數之后將其結果作為參數，返回給0798漏洞流程，同時也能看到第一次溢出的拷貝的數據v6，是作為第四個參數傳入到該函數中的，我們的看看這個函數具體做了啥。

首先可以看到a2，a3這兩個參數來自于sub_43b349函數，值分別為word_45B246和word_45B244

而word_45B246和word_45B244的相關引用函數如下所示，其中Headcheck引起了我們的注意

可以看到這兩個位置的數據是在metf頭檢驗中進行的設置，即函數sub_43B1D0。

可以看到sub_43B1D0中設置a2，a3的值是依賴于metf頭之后的一位的值，且在處理的過程中有ReadByte的操作，這就意味這實際上可以通過該函數來實現往metf頭之后插入混淆數據的操作。

但是實際上仔細看代碼就可以知道，上面a2，a3是取的棧上的地址，也就是說這個值實際上在溢出之后是可控的。

再次調試可以看到a2，a3的地址分別為0012f420，0012f41c。

溢出之后可以看到此時a2，a3的值被修改。

如下所示，該函數的調用棧，需要注意的是2,3,4參數，其中第四個參數為溢出數據的第一段內容，2,3參數的低四字節（溢出時被修改為5800,06eb）需要注意，下文中會有相關解釋。

進入函數，可以看到首先通過sub_435B4A返回了一段內存v5，之后通過傳入的參數對該段內存進行初始化，其中紅框中的三處賦值初始化是關鍵，第一二次賦值分別將二三參數的低四位分別去處并v5偏移40和42處（06rb5800），之后通過函數memory將a4的0x14長度的數據拷貝到v5偏移50處，a4就是之前0798溢出時的第一次拷貝shellcode?

此時反編譯一下00281c3c這段內存，可以看到之前第一次拷貝的06eb5800的對應反編譯源碼為pop eax，jmp 00281c6e

而00281c6e正好就是之前v5+50處拷貝的溢出shellcode的第一段，而最終00281c3c這段內存會作為參數返回。

00281c3c的作為返回值返回，并作為參數1傳入到之后的0798 dispatch函數中。

進入dispatch后，之前溢出shellcode之后的35將再次觸發0798的漏洞，函數首先分別獲取參數1偏移0x28，和0x2a處的數據，并保存到局部變量中，需要注意是獲取的是兩字節，賦值后內存中變成了00445800.?

0044實際上只之前sub_4428F0函數的返回地址。

有意思的是在漏洞函數中sub_438349中，該函數會設置對應傳入的a2，a3地址的值，此時正好將00445800設置為00440000（該值在之后的利用中被使用）.

如下所示之后35之后依次讀取的5個字節為35, 33,36,20,44（其中用于控制溢出長度的字節為20，44）。

第一次拷貝，拷貝地址為0012f35c，長度的控制參數為20.

第二次拷貝，拷貝地址為0012f376，長度的控制參數為44.

拷貝前的堆棧數據。

拷貝后的棧數據，此時返回地址已經被修改為00430bfb，需要注意的此時覆蓋的只是返回地址的第四位，即高四位并沒有被修改，返回地址后四位即為傳入的第一個參數00281c3c，同樣需要注意的還有00281c3c之后的00440000，現在來整理以下第二次漏洞利用的流程

00281c3c作為參數一傳入0798漏洞函數，之后分別獲取00281c3c偏移40,42處的內容），并賦值給v5，v6，其中v5就是0044000（其來源上文中已經說明），之后將00281c3c，v5，v6分別作為2,3,4參數傳入到dispatch函數中。

之后進入漏洞函數2,3,4參數又分別作為1,2,3參數來調用case 4處的漏洞函數。

此時函數返回，由于之前的漏洞將函數的返回地址已經修改為00430bfb，而該地址對應的反匯編代碼為ret，執行ret，將導致程序的執行流程直接進入到00430bfb之后的00281c3c中。

00281c3c向下執行，最終導致執行之后00281c3c中已經構造好的shellcode

這里可以看到在jmp前，有一條pop eax的操作，此時pop，即將之前棧上00281c3c之后的00440000賦值給eax，該值作為之后shellcode中尋址的高位地址，最終從此處進入到攻擊者控制的流程中。

由此可以看到該樣本中0798和正常0798的區別之處

首先正常進行一次0798的漏洞利用，在上布置好后續的shellcode
之后精心在函數sub_4428f0中構造出一段包含跳板shellcode的內存，并將該段內存作為參數再次調用0798函數。
再次觸發漏洞，通過ret的方式將程序的執行流程定向到之前的跳板shellcode中。

總結

如下所示即可看到11882/0802/0798這三個漏洞的混淆點了，對于這三個漏洞，除了綠色1c，*8（11882，0802），*1/*4-*5（0798）不能變，其他位置都是可變的，其中紫色指有要求的變（第一處不能大于0x20000，第二處只能為01(當為01時，metf頭由五位變成1位，即之前的后四位去掉)，02，03，102，103），當metf為五位時，之后的一位，即第六位實際上是可以導致之后有附加數據的，及下圖中的藍色部分，因此metf頭之后和tag頭之間也是可以插入混淆數據的。除此之外eqnolefilehdr，mtef head其余位置應該都是可以隨便搞的。

之后mtef byte stread中可以插入任意多的tag，只要保證最終進入08，05tag即可，因此在紫色01和綠色08之間也是可以加入混淆數據的（通過0798中的處理或標準流程中11882處理（>9,01，04會進入0798），0798中還依賴dispatch來處理，case0/case1/case5流程中是可以再次進入到0798，如上文的第2,4個樣本。