日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間:8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
Hacking Team安卓瀏覽器攻擊過程中的漏洞分析Stage0

一、漏洞簡介

宣城ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場景,ssl證書未來市場廣闊!成為創(chuàng)新互聯(lián)公司的ssl證書銷售渠道,可以享受市場價格4-6折優(yōu)惠!如果有意向歡迎電話聯(lián)系或者加微信:13518219792(備注:SSL證書合作)期待與您的合作!

Hacking team今年爆出了針對android4.0.x-4.3.x android瀏覽器的漏洞攻擊利用代碼。該漏洞攻擊代碼,通過連續(xù)利用多個瀏覽器與內(nèi)核漏洞,完成通過javascript向虛擬內(nèi)存寫數(shù)據(jù),執(zhí)行代碼,提升至root權(quán)限,并最終達(dá)到向目標(biāo)手機(jī)中植入惡意程序的目的。

該利用過程分為5個復(fù)雜的Stage,本文首先分析了第1個Stage,即Stage0。 攻擊代碼的Stage0階段通過一個0Day地址泄露漏洞,為后續(xù)數(shù)據(jù)填充操作完成定位地址定位的任務(wù)。此漏洞位于android-src\external\libxslt模塊中。

二、漏洞詳細(xì)信息

概述

Stage0利用的0Day漏洞原理如下:

該漏洞屬于未經(jīng)正確性檢查,就直接錯誤地進(jìn)行強(qiáng)制類型轉(zhuǎn)換,從而導(dǎo)致一個用于內(nèi)存讀(實際用于字符串比較)的指針可以被操控。漏洞利用的思路是:通過在JS分配的大片內(nèi)存空間中,填充字符串:http://www/w3.org/1999/XSL/Transform,程序的后續(xù)邏輯會將該字符串會與那個可控內(nèi)存指針?biāo)赶虻淖址M(jìn)行比較,一旦字符串對比不成功,則javascript的一個對象會記錄下“Error”,由于指針?biāo)赶虻牡刂肥强煽刂频?,一旦發(fā)現(xiàn) “Error”,就重新調(diào)整地址,直到?jīng)]有發(fā)生Error,這樣就得到了javascript開辟的可控空間的內(nèi)存地址信息。

1. 數(shù)據(jù)結(jié)構(gòu)背景

圖1展示了hacking team所使用的觸發(fā)漏洞代碼:

圖1 漏洞觸發(fā)代碼與其內(nèi)存結(jié)構(gòu)

在瀏覽器中,我們可以使用javascript引用如圖1所示的xsl文件,通過此文件,即可引發(fā)stage0所使用的漏洞。圖1中的xsl語句,在libxml2解析后,會形成如圖1中右圖所示結(jié)構(gòu)。其中,xsl描述的cdent節(jié)點,即為觸發(fā)漏洞的ENTITY類型節(jié)點。

此漏洞發(fā)生在瀏覽器引擎對xsl文件的解析過程中。因此,我們先簡述一下圖1中代碼,與右圖節(jié)點的對應(yīng)關(guān)系。右圖的myDoc節(jié)點為虛的根節(jié)點,在左圖xsl描述中并沒有對應(yīng)。xsl描述的最外層adoc和ata節(jié)點,同為根節(jié)點的下的一級子節(jié)點,由于adoc是第一個子節(jié)點,被myDoc的數(shù)據(jù)結(jié)構(gòu)中得children指針指向,ata則被adoc的next指針指向。同理,x節(jié)點,cdent節(jié)點和y節(jié)點,同為adoc的子節(jié)點一級,形成如上圖所示結(jié)構(gòu)。#p#

2. 漏洞成因

程序出現(xiàn)異常的根本原因是由于libxslt在對圖1中的cdent(xmlEntity類型)節(jié)點進(jìn)行操作時,并未對此節(jié)點的類型進(jìn)行比較,導(dǎo)致對cdent節(jié)點進(jìn)行了不正確的類型轉(zhuǎn)換(轉(zhuǎn)換為xmlNode類型),并對轉(zhuǎn)換后的節(jié)點進(jìn)行了非法操作。libxslt(android瀏覽器在對xsl進(jìn)行解析時所使用的模塊)在對xsl操作的過程中,會對大部分節(jié)點的namespace進(jìn)行比較,判斷節(jié)點是否為一個合法的xsl節(jié)點。

但當(dāng)節(jié)點類型為xmlEntity類型時,由于xmlEntity沒有ns(用來比較namespace信息的數(shù)據(jù)結(jié)構(gòu))字段,所以不對xmlEntity類型進(jìn)行比較namespace操作(xmlEntity類型、xmlNode類型的詳細(xì)信息請看圖5)。而libxslt在判斷節(jié)點類型是否為xmlEntity時,libxslt的判斷并不完全,最終導(dǎo)致xmlEntity可被轉(zhuǎn)換為xmlNode進(jìn)行操作。從而引發(fā)程序崩潰。

圖2 未對所有節(jié)點的類型進(jìn)行判斷

觸發(fā)崩潰的第一步,是由于對節(jié)點類型的比較不完全導(dǎo)致的。libxslt在成功構(gòu)建節(jié)點樹(如圖2中右圖)后,會循環(huán)對myDoc的子節(jié)點進(jìn)行namespace比較操作,圖2中左側(cè)代碼,是在循環(huán)中當(dāng)對當(dāng)前節(jié)點的所有操作完成時,將循環(huán)操作中的節(jié)點指針指向下一個需要操作的節(jié)點的代碼。根據(jù)圖2中第4967行的代碼,我們可以發(fā)現(xiàn),libxslt是希望當(dāng)目標(biāo)節(jié)點子節(jié)點或next節(jié)點的類型不為xmlEntity類型時,將目標(biāo)節(jié)點子節(jié)點或next節(jié)點賦值給cur指針,再由cur指針進(jìn)入下一次循環(huán)。但是,libxslt只對cur指針的第一個子節(jié)點進(jìn)行了數(shù)據(jù)類型的比較操作,并沒有對cur指針的next節(jié)點進(jìn)行數(shù)據(jù)類型的比較。而在我們構(gòu)建的節(jié)點結(jié)構(gòu)中,cdent(xmlEntity類型)節(jié)點,正是被x的next指針指向的,導(dǎo)致cdent節(jié)點不正確的進(jìn)入了循環(huán)。

圖3 對namespace進(jìn)行比較的函數(shù)

觸發(fā)崩潰的第二步,是xmlEntity節(jié)點被轉(zhuǎn)換為xmlNode節(jié)點。圖3為第一步中所說的循環(huán)的開始位置(圖3代碼的4893行),我們可以清晰的看到第一步所用的cur指針的數(shù)據(jù)類型為xmlNode類型。而第一步的xmlEntity類型被賦值給了xmlNode類型的指針,這就導(dǎo)致了類型轉(zhuǎn)換的錯誤。

圖4 IS_XSLT_ELEM宏的定義

觸發(fā)崩潰的第三步,是對不正確的數(shù)據(jù)類型進(jìn)行了非法操作。圖4為圖3中IS_XSLT_ELEM宏的展開。IS_XSLT_ELEM宏的操作是比較節(jié)點的namespace,判斷xmlNode結(jié)構(gòu)體中的ns字段(此字段指向一個xmlNs的數(shù)據(jù)類型)中的href字段所指向的地址是否存儲了字符串“http://www.w3.org/1999/XSL/Transform”。

圖5 相互轉(zhuǎn)換的兩種數(shù)據(jù)類型

當(dāng)IS_XSLT_ELEM宏的輸入?yún)?shù)為一個xmlEntity類型時,宏就會將orig字符串當(dāng)作xmlNs類型的數(shù)據(jù)結(jié)構(gòu)來操作。由于程序中的orig字符串存儲的是xmlEntity節(jié)點內(nèi)的字符串信息,所以在觸發(fā)漏洞的代碼這個例子中,此處存儲的字符串為:

'XX';

toascii(addr); // ns->href

toascii(addr); // ns->prefix

'XXXX' // ns->_private

'XXXX' // ns->context

' xmlns:xsl=\'http://www.w3.org/1999/XSL/Transform\' terminate=\'yes\'/>

而在宏中,會把這串字符串當(dāng)作xmlNs類型來操作。

圖6 xmlNs的數(shù)據(jù)結(jié)構(gòu)

因此可以通過此漏洞達(dá)到地址泄漏的目的。可以注意到,當(dāng)宏將字符串當(dāng)作xmlNs節(jié)點來處理時,代碼中轉(zhuǎn)換為ascii碼的addr就可以被當(dāng)作比較的字符串指針(href)來處理(詳細(xì)信息見圖4)所以我們可以將任何可以轉(zhuǎn)化為ascii碼的地址寫入href指針,從而讓這些指針?biāo)赶虻淖址c“http://www.w3.org/1999/XSL/Transform”進(jìn)行比較。

如果比較結(jié)果為真,則繼續(xù)后續(xù)操作,否則,libxslt將返回一個可被javascript接收的error信息。攻擊者通過接受的error信息,就可判定輸入的地址是否有指定的字符串,再結(jié)合大量的數(shù)據(jù)填充,就可以打到地址泄漏的目的。(詳見“三、利用方式”)#p#

3. 調(diào)試過程

調(diào)試過程在nexus 7+android4.3上進(jìn)行。

由于在webkit解析xsl文件時,如果標(biāo)簽為

圖7 程序在xmlParseEntityDecl停下時的狀態(tài)

myDoc節(jié)點:0x400d9768最終程序崩潰時,調(diào)用棧中會顯示是由于處理這個對象而導(dǎo)致崩潰。

Input:0x59988c18通過查看input信息,可知對xsl對象所解析到那個節(jié)點。

查看input信息:

圖8 Input中的信息

圖9 程序的解析狀態(tài)

如圖9顯示,正在解析!ENTITY節(jié)點。(base表示所解析的字符串,cur表示當(dāng)前解析到的位置。)

函數(shù)entityDecl會創(chuàng)建引發(fā)錯誤的ENTITY對象:

圖10 xmlEntity節(jié)點的創(chuàng)建(此時節(jié)點的數(shù)據(jù)類型為xmlNode)

如圖10中所示,新生成的next節(jié)點,為通過entityDecl函數(shù)所得到的entity節(jié)點(type=0×11,0×11表示為entity節(jié)點,為圖2中XML_ENTITY_DECL的實際值)。此時此節(jié)點的compression字段(在xmlEntity中此字段為orig字段)為0。

函數(shù)xmlParseEntityValue會將節(jié)點中的字符串存儲于orig字符串指針中。

圖11 獲取xmlEntity節(jié)點中的字符串信息

如圖11所示,程序?qū)?ENTITY節(jié)點中解析出的字符串傳給了orig。(input中的cur(當(dāng)前值)已向后移動,而之前的部分存入了orig中)

之后,函數(shù)會將orig賦值給xmlEntity對象的orig。

圖12 將字符串存入xmlEntity的orig字段中

函數(shù)通過cur對目標(biāo)xmlEntity節(jié)點的orig字段進(jìn)行賦值。

圖13 將之前出問題的節(jié)點轉(zhuǎn)換為xmlEntity類型

如圖13所示,被賦值的cur正是之前創(chuàng)建的xmlEntity節(jié)點。

而當(dāng)程序運行到cur->orig=orig時,目標(biāo)位置指針被重置:

圖14 字符串的傳入

如圖14所示,此時的compission字段被置為orig指針,存儲著可控的對象。而當(dāng)對此節(jié)點進(jìn)行namespace比較時,節(jié)點會類型轉(zhuǎn)換為xmlNode類型,而xmlEntity->orig字符串字段則會被當(dāng)成xmlNs類型來解釋,最終達(dá)到任意地址比較的操作。

圖15 程序崩潰時的狀態(tài)

如圖15所示,程序最終在字符串比較時發(fā)生段錯誤,此時的棧中xsltParseTemplateContext的第二個參數(shù),正是為我們在xmlParseEntityDecl停下時,myDoc所指向的地址。#p#

三、利用方式

1.向內(nèi)存中填充330頁的寫有namespace信息的頁。通過大量的數(shù)據(jù)填充,在觸發(fā)漏洞時就有更大的可能匹配成功,只有匹配成功,才能進(jìn)一步的地址泄漏。如果觸發(fā)漏洞時的addr值指向未被分配的頁,則會出現(xiàn)段錯誤導(dǎo)致程序崩潰。

圖16 內(nèi)存填充

圖17 填充namespace信息

2.通過漏洞,可以在xsl對象生成時,修改href指針的值(詳見圖6),將地址改為一個在填充過程中,有很大幾率會被填充到的地址。

圖18 漏洞利用代碼1

圖19 漏洞利用代碼2

3.函數(shù)內(nèi)部會自動對xsl對象的namespace指針進(jìn)行匹配,以確定xsl對象是否為一個合法的xsl元素。如果為非法元素,則會被javascript捕獲到異常。

圖20 javascript可獲取的異常狀態(tài)

4.若進(jìn)入if,則字符串匹配成功,之后進(jìn)入二分法查找具體頁的過程,addr為觸發(fā)漏洞時所寫入的地址。若進(jìn)入else,將猜測的地址addr進(jìn)行變化,再次進(jìn)行比較過程(此函數(shù)名即為find_spray_addr進(jìn)入else后,則會迭代查找地址)。

5.二分法查找:

a.將填充的330頁數(shù)據(jù)的前一半(165頁)數(shù)據(jù)進(jìn)行清空。

b.再次調(diào)用漏洞,判斷是否發(fā)生異常,若異常,則addr所指向的地址在前一半填充的頁中。否則,addr所指向的地址在后一半填充的頁中。

c.繼續(xù)對前一半或后一半進(jìn)行a、b兩步,直到僅剩一頁時,則可判定addr指向的是此頁中的地址。

圖21 二分法查找addr所在頁的代碼1

圖22 二分法查找addr所在頁的代碼2

6.通過獲取頁信息,即可得到一個泄露的內(nèi)存地址addr以及周圍4mb的可控內(nèi)存,達(dá)到本階段的漏洞利用目的。


本文標(biāo)題:Hacking Team安卓瀏覽器攻擊過程中的漏洞分析Stage0
URL分享:http://m.5511xx.com/article/dpjdops.html