阿里基礎安全威脅情報中心

0x01 漏洞概述

---

今年4月份微軟修補了一個名為CVE-2015-1641的word型別混淆漏洞，攻擊者可以構造嵌入了docx的rtf文件進行攻擊。word在解析docx文件處理displacedByCustomXML屬性時未對customXML物件進行驗證，可以傳入其他標籤物件進行處理，造成型別混淆，導致任意記憶體寫入，最終經過精心構造的標籤以及對應的屬性值可以造成遠端任意程式碼執行。

根據微軟官方MS15-33安全公告裡顯示，這個漏洞覆蓋Office 2007 SP3，Office 2010 SP2（32位和64位），Office 2013 SP1（32位和64位），Office 2013RT SP1，Word for Mac 2011以及Office在SharePoint伺服器上的Office 2010/2013和Office Web 2010/2013應用，除此之外，經過驗證Office 2010 SP1也受該漏洞的影響，但是微軟針對該漏洞在2010上的補丁KB2553428並未推出SP1版本，因此SP1版本的Office 2010到目前即使更新所有補丁仍然存在該漏洞。

CVE-2015-1641這個漏洞的觸發非常穩定，幾乎影響微軟目前所支援的所有office版本（最新推出的Office 2016除外），影響範圍十分廣泛。目前無論是在VirusTotal還是在野外抓到的樣本，利用這個漏洞的攻擊樣本已經開始逐漸增加。根據以上原因可以推斷，在今後很長的一段時間內都會存在該漏洞的攻擊，並且有替代CVE-2012-0158的趨勢。

0x02 漏洞原因分析

---

使用阿里諦聽引擎掃描RTF文件，解析出其中的一個word文件的document.xml中有如下程式碼，包含了4個smartTag標籤，每個smartTag中又有permStart標籤，而在permStart標籤中的則是帶有displacedByCustomXml屬性的moveFromRangeStart和moveFromRangeEnd標籤：

首先來說明一下幾個標籤及屬性的作用。smartTag標籤是用於word和excel中的智慧標籤，針對人名、日期、時間、地址、電話號碼等進行智慧識別並允許使用者執行特定操作的標籤。比如如果Steve Jobs被識別為人名，則smartTag標籤可以執行諸如開啟通訊錄、新增到聯絡人、預約會議等操作，給office使用者提供更多自定義的智慧選擇。displacedByCustomXml在很多標籤中都可以使用，目的是當前標籤處需要被一個customXML中的內容代替，它的值是next表示被下一個customXML代替，prev則表示被上一個代替。

這個漏洞是一個型別混淆漏洞，本來帶有displacedByCustomXml的標籤會被上一個或下一個customXML代替，但是word沒有對傳入的customXML物件進行嚴格的校驗，導致可以傳入諸如smartTag物件，然而smartTag物件的處理流程和customXML並不相同，上述特殊處理的smartTag標籤中的element屬性值會被當作是一個地址，隨後經過簡單的計算得到另一個地址。最後處理流程會將moveFromRangeEnd的id值覆蓋到之前計算出來的地址中，導致任意記憶體寫入，漏洞程式碼如下：

透過下面的補丁對比可以很容易看到打上最新補丁的word程式碼增加了對customXML物件處理函式的校驗：

0x03 漏洞利用分析

---

利用的分析環境為win7 64位+office2010 sp2 32位。

雖然這上面有4個smartTag標籤，但就目前分析來看，前兩個標籤是漏洞利用的關鍵。首在解析第一個smartTag標籤時會把其moveFromRangeEnd子標籤的id進行解析，然後寫到0x7c38bd74這個地址中去，這個地址是根據smartTag的element即0x7c38bd50計算出來的：

然後解析第二個smartTag標籤，esi指向的記憶體就是smartTag的結構體，esi+4的內容是element屬性值：

而eax的值為0x7C376FC3，剛好就是moveFromRangeEnd物件id "2084007875"的十六進位制值：

然後覆蓋MSVCR71.dll中0x7c38a428，這是一個虛擬函式的指標，而0x7c38a428這個地址是透過當前smartTag的element屬性值即0x7c38bd68和第一個smartTag標籤中moveFromRangeStart的id共同計算出來的：

除錯可以看到如下記憶體，ecx的記憶體如下，ecx+0xc就是上面解析第一個smartTag標籤時寫入的值，最終計算得到的被覆蓋的地址便是0x7c38a428：

而在覆蓋之前0x7c38a428處的指標指向kernel32! FlsGetValue:

最後呼叫memcpy函式進行覆蓋：

覆蓋之後的0x7c38a428指向的便是攻擊者想要執行的程式碼位置：

總結一下利用流程如下：首先smartTag_1（第一個smartTag標籤）的element屬性值進行簡單計算得到一個地址addr1，然後將其moveFromRangeEnd_1子標籤的id寫入到addr1中備用；然後解析smartTag_2，根據他的element屬性值和前面計算出來的addr1共同計算出另一個地址addr2，並將其子標籤moveFromRangeEnd_2的id寫入到addr2，而addr2是一個虛擬函式表中的地址，這樣原本是這個虛擬函式的地址就被覆蓋成攻擊者想要執行的任意程式碼的地址，漏洞利用成功。

word在office2010的環境下沒有打補丁的情況下執行的堆噴射後的地址為0x0900080C，如下：

看到這段記憶體想必都已經清楚了，這裡就是RTF文件釋放的activeX.bin檔案的內容，而0x7c342404處的程式碼是ret，因此這裡會一直執行ret直到到達最終ROP的位置，ROP鏈如下：

毫無疑問ROP的作用還是呼叫VirtualProtect函式對當前這塊記憶體新增可執行許可權：

獲得執行許可權之後開始執行shellcode：

0x04 漏洞利用檢測

---

想要檢測這個漏洞的攻擊樣本必須要先從rtf文件提取出docx然後獲取到document.xml，yara規則如下：

rule CVE_2015_1641
{
    meta:
        description="Word Type Confusion Vulnerability"
        output="Nday & CVE-2015-1641"
    strings:
    $smart_tag=/<w:smartTag[\w\W]+?w:element=\"(&#x[a-zA-Z0-9]{4};){2}\">[\w\W]+?<w:permStart[\w\W]+?w:displacedByCustomXml=\"prev\"\/>[\w\W]+?<w:permEnd[\w\W]+?<\/w:smartTag>/
    condition:
        $smart_tag
}

上面的規則匹配其實就是一個正則匹配，從左到右流程如下：1.匹配到smartTag標籤，檢視其element屬性是否為十六進位制數值作為地址；2.在smartTag標籤中匹配到permStart標籤，在它的屬性或子標籤的屬性中存在displacedByCustomXml="prev"。滿足上述兩個條件則認為就是這個漏洞的攻擊樣本。依據上面的yara規則檢測該攻擊樣本的document.xml結果如下：

0x05 參考連結

---

1. 微軟MS15-033安全公告
2. Fortinet對CVE-2015-1641的簡要分析報告
3. Office Smart Tag標籤說明
4. Office permStart標籤及displacedByCustomXml屬性

關於阿里基礎安全威脅情報中心

阿里基礎安全威脅情報中心是2015年6月新成立的部門，以沉澱阿里的安全資料、安全能力和建設阿里安全的威脅情報體系為使命,歡迎志同道合的小夥伴們加盟。