FuzzerAPP：Android應(yīng)用程序組件通信魯棒性測(cè)試

張 密 楊 力 張俊偉

(西安電子科技大學(xué)網(wǎng)絡(luò)與信息安全學(xué)院 西安 710071) (zmic@sina.cn)

FuzzerAPP：Android應(yīng)用程序組件通信魯棒性測(cè)試

張 密 楊 力 張俊偉

(西安電子科技大學(xué)網(wǎng)絡(luò)與信息安全學(xué)院 西安 710071) (zmic@sina.cn)

針對(duì)Android應(yīng)用程序的安全性問(wèn)題，提出一種基于模糊測(cè)試方法的組件通信魯棒性測(cè)試方案.首先構(gòu)造測(cè)試集和測(cè)試用例，隨后將測(cè)試用例發(fā)送給目標(biāo)應(yīng)用程序并收集測(cè)試數(shù)據(jù)，最后對(duì)測(cè)試數(shù)據(jù)進(jìn)行分析.依據(jù)測(cè)試方案設(shè)計(jì)并實(shí)現(xiàn)了模糊測(cè)試工具FuzzerAPP，進(jìn)而對(duì)常用應(yīng)用程序進(jìn)行魯棒性測(cè)試.通過(guò)對(duì)測(cè)試數(shù)據(jù)的分析，發(fā)現(xiàn)發(fā)送特殊Intent可以導(dǎo)致應(yīng)用程序的崩潰，甚至引發(fā)系統(tǒng)服務(wù)的級(jí)聯(lián)崩潰.此外，發(fā)現(xiàn)測(cè)試集中多款應(yīng)用程序存在測(cè)試模塊暴露的問(wèn)題，可能會(huì)導(dǎo)致隱私泄露、拒絕服務(wù)等嚴(yán)重安全問(wèn)題.最后，通過(guò)與其他工具的對(duì)比，表明測(cè)試方法的有效性和測(cè)試工具的實(shí)用性.

安卓；組件通信；模糊測(cè)試；魯棒性；測(cè)試模塊暴露

隨著Android系統(tǒng)的飛速發(fā)展，Android APP(application)的數(shù)量也隨之不斷增長(zhǎng).現(xiàn)有APP分發(fā)平臺(tái)包括Google Play等，通常情況下允許任何開(kāi)發(fā)者在其平臺(tái)上傳應(yīng)用，導(dǎo)致APP質(zhì)量參差不齊，安全性難以保障.數(shù)量眾多的Android APP在為用戶提供更多應(yīng)用和更豐富體驗(yàn)的同時(shí)，也會(huì)為用戶帶來(lái)一系列的安全與隱私問(wèn)題[1].

為了應(yīng)對(duì)安全與隱私問(wèn)題，Android系統(tǒng)已提供了沙箱模型、權(quán)限保護(hù)等機(jī)制[2].這些安全機(jī)制通常情況下是有效的，但是，當(dāng)系統(tǒng)中某一APP組件發(fā)送錯(cuò)誤或者異常信息給其他APP組件時(shí)，可能會(huì)引起目標(biāo)組件的錯(cuò)誤行為，從而使上述一系列保護(hù)措施效果大大削弱.保護(hù)機(jī)制的削弱，極大地影響了APP組件間通訊的魯棒性，使APP組件間進(jìn)行通信時(shí)，可能會(huì)遇到信息竊聽(tīng)、組件欺騙、拒絕服務(wù)等安全問(wèn)題.隨著Android APP數(shù)量的飛速增長(zhǎng)以及程序間通信可能存在的上述問(wèn)題，對(duì)APP組件間通信魯棒性研究需求越來(lái)越迫切.

通常情況下，Android APP在正式對(duì)外發(fā)布前會(huì)經(jīng)過(guò)一系列的基本測(cè)試.在對(duì)APP的測(cè)試方面，Android官方提供了Monkey[3]工具，供開(kāi)發(fā)者對(duì)APP進(jìn)行基礎(chǔ)測(cè)試.其他工具如MonkeyRunner[4]，DroidPilot[5]，Dynodroid[6]等，均可針對(duì)某一方面對(duì)APP進(jìn)行測(cè)試.

模糊測(cè)試[7]是一種通過(guò)向目標(biāo)系統(tǒng)提供非預(yù)期輸入并監(jiān)視異常結(jié)果來(lái)發(fā)現(xiàn)軟件漏洞的方法.在對(duì)Windows和Unix等操作系統(tǒng)的魯棒性驗(yàn)證方面，模糊測(cè)試的方法已取得有效結(jié)果[8-10].將模糊測(cè)試的方法用于Android系統(tǒng)安全的研究，同樣得到研究者的廣泛重視.Mulliner等人[11]通過(guò)構(gòu)造異常輸入數(shù)據(jù)來(lái)測(cè)試Android系統(tǒng)的SMS模塊，并在其運(yùn)行時(shí)檢測(cè)異常.Android Kernel Fuzzer[12]被用來(lái)發(fā)現(xiàn)Android Linux的核心漏洞.與此同時(shí)，模糊測(cè)試的方法也被用來(lái)研究Android APP組件間通信的安全性.由iSEC partners開(kāi)發(fā)的Intent Fuzzer[13]使用模糊測(cè)試的方式來(lái)測(cè)試在系統(tǒng)中注冊(cè)組件的健壯性.Maji等人[14]利用模糊測(cè)試的方法測(cè)試Android系統(tǒng)的IPC機(jī)制時(shí)構(gòu)建的，主要通過(guò)構(gòu)造不同類型的顯式和隱式Intent測(cè)試Android系統(tǒng)預(yù)留APP IPC的魯棒性.DroidFuzzer[15]使用MIME等數(shù)據(jù)對(duì)APP組件中的Activity進(jìn)行模糊測(cè)試.Sasnauskas等人[16]使用靜態(tài)分析和模糊測(cè)試結(jié)合的方法測(cè)試Google核心APP以及少量第三方APP，測(cè)試過(guò)程中出現(xiàn)APP重啟，甚至是操作系統(tǒng)重啟的現(xiàn)象.

在本文中，我們針對(duì)Android第三方APP組件間通信的魯棒性展開(kāi)測(cè)試，探究當(dāng)輸入數(shù)據(jù)多樣化時(shí)可能導(dǎo)致的問(wèn)題.本文設(shè)計(jì)了一種基于模糊測(cè)試的方案，該方案使用Android SDK提供的數(shù)據(jù)，按照本文中指定的規(guī)則自動(dòng)化構(gòu)造測(cè)試用例.然后，綜合時(shí)間、效率等因素，將測(cè)試用例發(fā)送給待測(cè)APP組件，最后對(duì)目標(biāo)組件在測(cè)試過(guò)程中的交互信息以及輸出數(shù)據(jù)進(jìn)行統(tǒng)計(jì)分析.根據(jù)該方法設(shè)計(jì)實(shí)現(xiàn)了測(cè)試工具FuzzerAPP，并對(duì)大量APP進(jìn)行測(cè)試.

通過(guò)對(duì)大量常用第三方APP的測(cè)試和對(duì)測(cè)試數(shù)據(jù)的進(jìn)一步分析，我們發(fā)現(xiàn)對(duì)APP組件發(fā)送特殊Intent不僅可以導(dǎo)致APP崩潰，甚至可以導(dǎo)致Android框架層服務(wù)的級(jí)聯(lián)崩潰，進(jìn)而造成Dalvik子系統(tǒng)重啟.我們發(fā)現(xiàn)的另一個(gè)重要的問(wèn)題是，包括國(guó)內(nèi)某著名購(gòu)物APP在內(nèi)的多款A(yù)PP存在測(cè)試模塊暴露的問(wèn)題.測(cè)試模塊的暴露會(huì)造成用戶隱私泄露、APP拒絕服務(wù)以及聯(lián)合其他漏洞對(duì)服務(wù)器發(fā)動(dòng)DDoS攻擊等嚴(yán)重的安全問(wèn)題.對(duì)測(cè)試數(shù)據(jù)結(jié)果的分析以及與類似工具的對(duì)比均證明了所提出方案的有效性以及測(cè)試工具的實(shí)用性.

1 背景知識(shí)

1.1 Android APP組件

Android APP的組件主要包括4種類型：Activity，Service，Broadcast Receiver，Content Provider.

1) Activity.Android APP與用戶交互的每個(gè)界面都屬于Activity.Activity可以通過(guò)Intent啟動(dòng)其他組件，也可以被其他組件啟動(dòng).

2) Service.Service在后臺(tái)運(yùn)行，通常用于為其他組件提供后臺(tái)服務(wù)等比較耗時(shí)的操作，比如音樂(lè)播放、文件下載等.

3) Broadcast Receiver.Broadcast是一種廣泛使用的在APP間傳輸信息的機(jī)制.而B(niǎo)roadcast Receiver是對(duì)發(fā)送來(lái)的廣播進(jìn)行過(guò)濾接受并響應(yīng)的一類組件.

4) Content Provider.Content Provider是Android提供的一種標(biāo)準(zhǔn)共享數(shù)據(jù)的機(jī)制.

1.2 組件通信

Android系統(tǒng)中APP組件間通信主要依靠Intent和Binder.在實(shí)際使用中，由于Intent可以動(dòng)態(tài)地選擇和綁定目標(biāo)組件，使得它具有更好的靈活性和多樣性，可以更有效地構(gòu)建測(cè)試用例，因此本文選擇使用Intent進(jìn)行測(cè)試工作.

在組件通信中，Intent作為需要傳遞信息的載體存在.Intent負(fù)責(zé)描述APP中單次操作的動(dòng)作、動(dòng)作涉及的數(shù)據(jù)以及附加數(shù)據(jù)等內(nèi)容，Android框架層服務(wù)則根據(jù)Intent的描述，負(fù)責(zé)找到處理Intent的對(duì)應(yīng)組件，然后將Intent發(fā)送給目標(biāo)組件完成信息的傳遞.Intent不僅可用于APP內(nèi)組件間的通信，也可用于APP間組件的通信.在組件通信中，Intent Filter用于描述APP組件所能響應(yīng)Intent請(qǐng)求的能力，即該組件可以處理的Intent的行為類型和數(shù)據(jù)類型等.

在Android系統(tǒng)中，組件之間通過(guò)Intent信息和Intent Filter來(lái)完成信息的交換.Intent信息包含了對(duì)組件通信信息的具體描述，在本文所提供的方案中，我們通過(guò)對(duì)通信信息——Intent信息中各種描述信息的更改，達(dá)到對(duì)目標(biāo)組件魯棒性測(cè)試的目的.通過(guò)對(duì)組件通信魯棒性的測(cè)試，可以發(fā)現(xiàn)組件通信中潛在的問(wèn)題.

1.3 組件暴露

Android APP的組件分為私有組件和公有組件2類.如果某組件只能接收同一APP內(nèi)組件發(fā)送的Intent，則該組件為私有組件.如果一個(gè)組件可以接收到來(lái)自其他APP組件發(fā)送的Intent，則此組件為公有組件，或稱其為暴露組件.公有組件把自身的功能暴露給其他APP的組件，可能會(huì)帶來(lái)包括信息竊聽(tīng)、組件欺騙、拒絕服務(wù)等在內(nèi)的一系列安全問(wèn)題[17-19].

2 方案設(shè)計(jì)

本方案主要為了展開(kāi)對(duì)Android第三方APP公有組件間通信的魯棒性測(cè)試.組件通信的魯棒性是指當(dāng)Android APP組件接收到攜帶各類異?；蛘叻穷A(yù)期數(shù)據(jù)的Intent時(shí)，APP能否有效處理.魯棒性通常是系統(tǒng)在異常和危險(xiǎn)情況下生存的關(guān)鍵.對(duì)數(shù)據(jù)處理的魯棒性同樣也是APP正常提供服務(wù)的關(guān)鍵.本方案需要構(gòu)建高覆蓋面的Intent作為測(cè)試用例，以測(cè)試目標(biāo)組件的魯棒性.所謂高覆蓋面是指構(gòu)造的Intent要盡可能完全覆蓋被測(cè)組件的Intent Filter，即在所構(gòu)造的測(cè)試用例中存在完全匹配(成功啟動(dòng))被測(cè)組件的Intent.

在方案的設(shè)計(jì)過(guò)程中，我們參考了Intent Fuzzer[13]工具.Intent Fuzzer工具僅發(fā)送空Intent給目標(biāo)Broadcast Receiver和Service組件，并且只能測(cè)試單個(gè)Activity，其功能受限且測(cè)試覆蓋率不高.我們對(duì)其改進(jìn)后提出本方案，并根據(jù)本方案形成新的測(cè)試工具FuzzerAPP，F(xiàn)uzzerAPP不僅能全面測(cè)試各種Activity，也能測(cè)試其他相關(guān)組件，構(gòu)造的Intent種類也大大增多.在Android系統(tǒng)中，F(xiàn)uzzerAPP與其他APP的交互關(guān)系如圖1所示.在圖1中，F(xiàn)uzzerAPP作為用戶層APP運(yùn)行于應(yīng)用程序?qū)?

Fig. 1 Interaction between FuzzerAPP and other APPs圖1 FuzzerAPP與其他APP的交互

本方案由5個(gè)模塊組成，分別為信息獲取模塊、測(cè)試用例生成模塊、測(cè)試用例發(fā)送模塊、待測(cè)組件選擇模塊以及結(jié)果收集模塊.這5個(gè)模塊的總體架構(gòu)如圖2所示.在圖2中，矩形表示組成本方案的各個(gè)模塊；橢圓表示各模塊生成的信息或者是各模塊正常工作所需要的信息，比如：圖中的Intent信息，既作為測(cè)試用例生成模塊產(chǎn)生的信息，又是測(cè)試用例發(fā)送模塊所必須的信息.圖2中各個(gè)模塊的功能如下:

1) 信息獲取模塊.以待測(cè)APP的apk安裝文件為輸入，使用靜態(tài)分析的方法，通過(guò)對(duì)反編譯文件的分析，輸出待測(cè)APP的詳細(xì)組件信息.

2) 測(cè)試用例生成模塊.以待測(cè)APP的組件信息和Android SDK提供的標(biāo)準(zhǔn)Action等數(shù)據(jù)為輸入，根據(jù)測(cè)試用例生成策略，構(gòu)建Intent消息.

Fig. 2 Architecture of the test scheme圖2 測(cè)試方案總體架構(gòu)

3) 待測(cè)組件選擇模塊.根據(jù)待測(cè)APP的詳細(xì)組件信息，判斷每一個(gè)組件是否為暴露組件.若是暴露組件,則加入待測(cè)組件列表.若為私有組件，則略過(guò)處理.

4) 測(cè)試用例發(fā)送模塊.按照一定的發(fā)送策略，將構(gòu)建的Intent消息發(fā)送給待測(cè)組件.

5) 結(jié)果收集模塊.在測(cè)試APP時(shí)，收集Android系統(tǒng)、被測(cè)APP、測(cè)試APP的輸出.

接下來(lái)，將對(duì)本方案中的核心模塊和功能進(jìn)行詳細(xì)介紹.

2.1 組件詳細(xì)信息獲取

待測(cè)APP組件詳細(xì)信息的獲取在信息獲取模塊完成.該模塊主要負(fù)責(zé)使用靜態(tài)分析方法對(duì)待測(cè)APP安裝包進(jìn)行分析.對(duì)待測(cè)組件詳細(xì)信息的獲取，主要通過(guò)以下方式獲得：

1) 反編譯待測(cè)試應(yīng)用程序安裝包；

2) 使用XML分析技術(shù)分析AndroidManifest.xml文件；

3) 使用關(guān)鍵詞搜索方法分析反編譯后的應(yīng)用程序代碼.

通過(guò)對(duì)AndroidManifest.xml文件的分析，可以獲得在APP中使用靜態(tài)注冊(cè)方式注冊(cè)的所有組件詳細(xì)信息.通過(guò)對(duì)反編譯后應(yīng)用程序代碼的分析，可以獲得在APP中使用動(dòng)態(tài)注冊(cè)方式注冊(cè)的Broadcast Receiver組件.因此，同時(shí)使用2種方法可以獲得待測(cè)APP的詳細(xì)組件信息，這些信息包括：

1) 待測(cè)APP組件列表信息；

2) 待測(cè)APP組件是否定義exported屬性，若定義則記錄其屬性值；

3) 待測(cè)APP組件的Intent Filter信息；

4) 訪問(wèn)待測(cè)應(yīng)用程序組件是否需要權(quán)限，若需要?jiǎng)t記錄訪問(wèn)權(quán)限.

信息獲取模塊將以上獲得信息，以APP為單位，以組件為索引，分別創(chuàng)建exported，Action，Data，權(quán)限數(shù)據(jù)集.這些組件信息有以下2個(gè)作用：1)使用這些組件信息供待測(cè)組件選擇模塊使用，用來(lái)確定待測(cè)組件；2)在測(cè)試用例生成階段使用，將這些待測(cè)組件詳細(xì)信息與其他數(shù)據(jù)相結(jié)合，共同生成測(cè)試用例.

2.2 測(cè)試用例生成策略

通過(guò)構(gòu)建策略創(chuàng)建的Intent是否能夠匹配第三方APP組件中的Intent Filter以及是否能夠成功啟動(dòng)第三方APP組件等，對(duì)測(cè)試結(jié)果的準(zhǔn)確性有著重要影響.這里的準(zhǔn)確性是指，使用測(cè)試用例對(duì)待測(cè)組件的測(cè)試結(jié)果是否符合其原本情況.準(zhǔn)確性越高，則測(cè)試結(jié)果的可信度越高，測(cè)試結(jié)果更具有說(shuō)服力.為了確保測(cè)試結(jié)果的準(zhǔn)確性，我們需要構(gòu)建覆蓋面盡可能高的Intent作為測(cè)試用例.

Intent消息包含Action，Data，Type，Component，Extras等字段.Action和Data是表現(xiàn)Intent動(dòng)作以及動(dòng)作所涉及數(shù)據(jù)的主要字段，在組件通信中的使用頻率極高，能表現(xiàn)出組件間通信的特性;Extras字段值具有很好的隨機(jī)性，可以很好地測(cè)試組件間通信的魯棒性.本方案只創(chuàng)建顯式的Intent，因此我們需要設(shè)定Component域的值.綜上，在測(cè)試過(guò)程中需指定Intent的Action，Data，Extras，Component域的值，其余字段則默認(rèn)為空.

本方案基于模糊測(cè)試方法，結(jié)合測(cè)試目標(biāo)，考慮覆蓋面等因素設(shè)計(jì)如下Intent構(gòu)建策略：

1) 空Intent.僅指定處理該Intent的目標(biāo)組件，其余字段為空.例如：Intent{cmp=com.example.appcom.example.app.someComponent}.

2) Action域與Data域的交叉.同時(shí)指定Intent的Action域和Data域的值，二者均不能為空.Action和Data域的值設(shè)置為每一個(gè)標(biāo)準(zhǔn)Action[20]的值與每一個(gè)系統(tǒng)支持的Data值組合.例如：Intent{act=ACTION_EDIT;dat=geo:***,***;cmp=com.example.appcom.example.app.someComponent}.

3) 僅指定Action域、Data域?yàn)榭栈驗(yàn)殡S機(jī)值.Action域的值來(lái)自Android SDK提供的標(biāo)準(zhǔn)Action值，Data域?yàn)榭栈驈臉?gòu)建的Data數(shù)據(jù)庫(kù)中隨機(jī)選擇.例如：Intent{act=ACTION_EDIT;cmp=com.example.appcom.example.app.someComponent}.

4) 僅指定Data域、Action域?yàn)榭栈驗(yàn)殡S機(jī)值.Data域的值來(lái)自構(gòu)建的Data數(shù)據(jù)庫(kù)，Action域值為隨機(jī)標(biāo)準(zhǔn)Action，Action可以為空.例如：Intent{dat=http:www.***.com;cmp=com.example.appcom.example.app.someComponent}.

5) 執(zhí)行策略2～4的同時(shí)，添加隨機(jī)Extras值.我們?cè)趫?zhí)行策略2～4后，對(duì)產(chǎn)生的每一個(gè)Intent添加隨機(jī)Extras值.例如：Intent{act=ACTION_EDIT;dat=http:www.***.com;cmp=com.example.appcom.example.app.someComponent(has extras)}.

在上述構(gòu)建策略中，使用空域(策略1)、交叉值(策略2)、隨機(jī)值(策略5)方法，以及這3種方法的結(jié)合(策略3和策略4)來(lái)確保FuzzerAPP構(gòu)建的Intent中包含可以與目標(biāo)組件完全有效匹配(Action域與Data域均匹配)、半有效匹配(Action域與Data域只匹配1個(gè))以及完全不匹配(Action域與Data域均不匹配)的Intent.基于上述策略構(gòu)建的Intent，可以更大限度地測(cè)試目標(biāo)組件針對(duì)各種有效和無(wú)效輸入處理的魯棒性.

2.3 測(cè)試算法

測(cè)試流程的算法如算法1所示.將使用測(cè)試用例生成策略構(gòu)建的多類型Intent，按照發(fā)送策略依次發(fā)送給目標(biāo)APP的每一個(gè)公有組件，最后按照結(jié)果收集階段的方法收集數(shù)據(jù).這里僅將Intent發(fā)送給Activity，Broadcast Receiver，Service這3類組件，并沒(méi)有顯式地測(cè)試Content Provider組件.針對(duì)Content Provider的測(cè)試，是通過(guò)在其他組件測(cè)試的Intent的Data數(shù)據(jù)域中加入相關(guān)Content Provider的URI進(jìn)行的，在測(cè)試其他組件的同時(shí)測(cè)試Content Provider.

算法1. APP測(cè)試算法.

Input:exAPP-the application to be examined:

allAction=Action數(shù)據(jù)集;

allData=Data數(shù)據(jù)集;

allExtra=Extras域支持的全部數(shù)據(jù)格式;

sleepTime=測(cè)試線程成功啟動(dòng)目標(biāo)組件時(shí)休眠時(shí)間;

components=getAllExportedComponents-InexAPP(exAPP).

start a new ThreadsendThread

for every componentcmpin components

action∈allAction,data∈allData,extra∈allExtra;

intents=createIntent(action,data,extra,component);

for every intentintin intents

send(int,comp);

sendThread.sleep(sleepTime);

end for

end for

endsendThread

在實(shí)際測(cè)試過(guò)程中，當(dāng)出現(xiàn)以下2種情況時(shí)，需要手動(dòng)干預(yù)測(cè)試過(guò)程：1)APP崩潰產(chǎn)生的系統(tǒng)警告.因?yàn)镕uzzerAPP工具屬于用戶層APP，所以不能隱藏系統(tǒng)級(jí)別的警告.2)Activity在新棧啟動(dòng).此時(shí)，調(diào)用者不能使用finishActivity()結(jié)束它.雖然在上述2種情況下，需要手動(dòng)干預(yù)測(cè)試過(guò)程，但并不影響實(shí)驗(yàn)結(jié)果的準(zhǔn)確性.

3 FuzzerAPP實(shí)現(xiàn)

根據(jù)所設(shè)計(jì)的方案，實(shí)現(xiàn)測(cè)試工具FuzzerAPP，并進(jìn)一步明確其功能.

在信息獲取模塊，F(xiàn)uzzerAPP選擇使用Apktool工具反編譯后獲取待測(cè)APP的AndroidManifest.xml文件，隨后使用DOM(document object model)解析文件，獲取在AndroidManifest.xml文件中的組件詳細(xì)信息.使用dex2jar工具將APP的可執(zhí)行文件Classes.dex文件反編譯為Jar格式文件，然后使用關(guān)鍵代碼搜索的方法獲取在程序代碼中動(dòng)態(tài)注冊(cè)廣播接收者詳細(xì)信息.

在測(cè)試用例生成模塊，F(xiàn)uzzerAPP需要設(shè)置相應(yīng)Intent的Action，Data，Extras，Component域的值.Component域?yàn)榇郎y(cè)組件選擇的待測(cè)試組件.Action，Data域來(lái)自信息獲取模塊獲取的組件詳細(xì)信息和Android SDK提供的標(biāo)準(zhǔn)數(shù)據(jù)的結(jié)合.Data域的值由一系列不同意義的Uri組成，如“http:”，“mailto:”，“tel:”，“geo:”，“content:”等.Extras域的值是根據(jù)Android SDK規(guī)定的Extras支持的所有數(shù)據(jù)類型逐一構(gòu)造的，如int，String，ArrayList等.確定了這4個(gè)域值的來(lái)源后，F(xiàn)uzzerAPP將按照所述策略構(gòu)建相應(yīng)Intent.

在測(cè)試用例發(fā)送模塊，F(xiàn)uzzerAPP使用使用setComponent()為Intent確定目標(biāo)組件，使用startService()發(fā)送Intent給目標(biāo)Service，使用sendBroadcast()發(fā)送Intent給目標(biāo)Broadcast Receiver.對(duì)于Activity，使用startActivityFor-Result()和finishActivity()來(lái)確保組件成功啟動(dòng)并運(yùn)行后關(guān)閉，以減少對(duì)系統(tǒng)資源的消耗.FuzzerAPP為APP中的每一個(gè)被測(cè)組件創(chuàng)建單獨(dú)線程并為其發(fā)送Intent.對(duì)每一個(gè)線程，每1次成功啟動(dòng)組件后暫停一段時(shí)間，防止系統(tǒng)資源耗盡.

在組件抽取方面，F(xiàn)uzzerAPP使用圖3所示方法獲取在系統(tǒng)中注冊(cè)的所有APP;然后用再逐個(gè)判斷所獲取的應(yīng)用是否為第三方APP，若結(jié)果為T(mén)RUE則為第三方應(yīng)用;最后通過(guò)解析第三方APP的PackageInfo獲取對(duì)應(yīng)的暴露組件信息.

Fig. 3 PackageManager gets the APP component code fragment圖3 PackageManager獲取APP組件代碼片段

在結(jié)果收集方面，F(xiàn)uzzerAPP使用LogCat收集測(cè)試數(shù)據(jù).FuzzerAPP分類收集在測(cè)試期間的各類數(shù)據(jù)，這些數(shù)據(jù)包括被測(cè)APP和系統(tǒng)的一般日志信息、警告日志信息、錯(cuò)誤日志信息.這些數(shù)據(jù)將用于對(duì)實(shí)驗(yàn)結(jié)果的分析.

按照以上5個(gè)方面對(duì)FuzzerAPP的各模塊進(jìn)行實(shí)現(xiàn)，F(xiàn)uzzerAPP實(shí)現(xiàn)的結(jié)果如圖4所示：

Fig. 4 FuzzerAPP UI圖4 FuzzerAPP界面

圖4(a)為所有待測(cè)APP；圖4(b)為選擇待測(cè)APP后的測(cè)試界面，根據(jù)不同組件類型顯示不同組件，并可選擇3種測(cè)試方式；圖4(c)為選擇不同測(cè)試組件類型時(shí)的界面.

4 實(shí)驗(yàn)及分析

使用FuzzerAPP測(cè)試第三方APP組件通信的魯棒性.首先，從國(guó)內(nèi)較大的第三方Android APP分發(fā)平臺(tái)之一的360手機(jī)助手下載待測(cè)APP.從其平臺(tái)軟件分類排行榜中選擇13類，每類中選擇排名前20的APP，合計(jì)260款A(yù)PP.根據(jù)實(shí)驗(yàn)方案的設(shè)計(jì)，使用FuzzerAPP對(duì)所下載的260款A(yù)PP進(jìn)行測(cè)試，其中有效測(cè)試249款(因設(shè)備版本過(guò)低或不支持Add-on屬性，11款A(yù)PP未能測(cè)試).在測(cè)試的249款A(yù)PP中，共包含4 764個(gè)暴露組件(其中Activity組件2 763個(gè)，Broadcast Receiver組件1 437個(gè)，Service組件654個(gè)).在完成所有APP測(cè)試后，F(xiàn)uzzerAPP共收集了約5.1 GB的測(cè)試數(shù)據(jù).

根據(jù)從測(cè)試工作中獲取的數(shù)據(jù)，以及測(cè)試過(guò)程中發(fā)送特殊Intent后目標(biāo)APP的界面變化，從以下4個(gè)方面對(duì)實(shí)驗(yàn)結(jié)果進(jìn)行分析：

1) 對(duì)被測(cè)APP同一組件發(fā)送大量Intent時(shí)，被測(cè)APP是否發(fā)生崩潰以及崩潰的次數(shù).

2) 在模糊測(cè)試期間，Android系統(tǒng)和被測(cè)APP拋出的各類異常的種類，以及這些異常產(chǎn)生的原因.

3) 在測(cè)試過(guò)程中，發(fā)送特殊構(gòu)造Intent造成系統(tǒng)服務(wù)級(jí)聯(lián)崩潰的原因分析.

4) 待測(cè)APP測(cè)試模塊暴露給用戶帶來(lái)的安全威脅及其產(chǎn)生原因分析.

4.1 APP崩潰分布

在向組件發(fā)送依據(jù)構(gòu)造策略構(gòu)造的Intent時(shí)，組件可能會(huì)因?yàn)槲床东@異常等原因造成APP崩潰.當(dāng)APP崩潰時(shí)，會(huì)由AndroidRuntime拋出具有“Fatal Exceptoin：main”標(biāo)志的異常.相應(yīng)地，可以通過(guò)“Fatal Exception：main”標(biāo)志來(lái)統(tǒng)計(jì)APP的崩潰次數(shù)以及跟蹤造成崩潰的異常種類.

經(jīng)過(guò)對(duì)測(cè)試結(jié)果中APP崩潰數(shù)量的統(tǒng)計(jì)分析，共有153款A(yù)PP發(fā)生902次崩潰，崩潰率為62.65%.FuzzerAPP將APP分為13類進(jìn)行測(cè)試，每類APP的崩潰數(shù)量如圖5所示，每類APP的崩潰次數(shù)如圖6所示.

Fig. 5 The number of APP collapse classification statistics圖5 崩潰APP數(shù)量分類統(tǒng)計(jì)

Fig. 6 Crashing times classification statistics圖6 崩潰次數(shù)分類統(tǒng)計(jì)

從圖5和圖6中，發(fā)現(xiàn)發(fā)生崩潰的同類APP數(shù)量與同類APP發(fā)生總崩潰次數(shù)總體呈正比關(guān)系.其中，攝影攝像類APP的崩潰率最高，同時(shí)，攝影攝像類APP的總崩潰次數(shù)也是最高的.進(jìn)而對(duì)此類APP的崩潰時(shí)Log數(shù)據(jù)進(jìn)行分析，發(fā)現(xiàn)出現(xiàn)次數(shù)最多的3類異常分別為SQLiteCantOpenDatabaseException，F(xiàn)ileNotFoundException，IllegalStateException.這3類異常的產(chǎn)生原因多與緩沖區(qū)和文件操作有關(guān)，這也正與攝像類APP的頻繁存儲(chǔ)操作相對(duì)應(yīng).

4.2 未捕獲以及捕獲的異常分布

對(duì)同一組件發(fā)送大量包含不同數(shù)據(jù)的Intent，如果該組件對(duì)接收到的數(shù)據(jù)不加過(guò)濾地隨意使用，就會(huì)使目標(biāo)組件所屬APP或者是Android系統(tǒng)的某些服務(wù)拋出一系列異常.若在目標(biāo)APP中沒(méi)有相應(yīng)異常的處理模塊，那么這些異常就會(huì)對(duì)相應(yīng)APP甚至是Android系統(tǒng)造成包括拒絕服務(wù)在內(nèi)的一系列問(wèn)題，這些問(wèn)題會(huì)嚴(yán)重影響用戶對(duì)APP的體驗(yàn).若目標(biāo)APP包含相應(yīng)異常的處理模塊，但對(duì)這些異常只是簡(jiǎn)單的捕獲、拋出，并不進(jìn)行深度處理，在這種情況下，其他APP開(kāi)發(fā)者或者安全研究人員可以通過(guò)分析拋出的異常信息，構(gòu)造危險(xiǎn)數(shù)據(jù)，同樣可以造成包括混淆代理人在內(nèi)的一系列問(wèn)題.

1) 未捕獲異常

通過(guò)對(duì)實(shí)驗(yàn)數(shù)據(jù)的統(tǒng)計(jì)分析，共有196款A(yù)PP拋出未捕獲異常，合計(jì)11 748個(gè)38類異常，詳細(xì)的異常分布情況如表1所示:

Table 1 No Catching Exception Distribution Statistics表1 未捕獲異常分布統(tǒng)計(jì)

在表1中，其他類異常包括一些未捕獲數(shù)量較少的26種異常，如java.net.SocketException，java.lang.OutOfMemoryError等.由于這些異常拋出次數(shù)較少，在表1中將它們統(tǒng)一歸為其他類.在未捕獲的38類異常中，26類異常的產(chǎn)生原因直接或間接與FuzzerAPP構(gòu)造的Intent攜帶的數(shù)據(jù)有關(guān)，這26類異常占所有類型異常拋出次數(shù)的80%.由此可見(jiàn)，APP未捕獲異常與APP組件缺乏對(duì)輸入數(shù)據(jù)的處理有極大關(guān)系.

2) 捕獲異常

通過(guò)對(duì)實(shí)驗(yàn)數(shù)據(jù)的統(tǒng)計(jì)分析，共有241款A(yù)PP拋出異常被捕獲，其詳細(xì)異常分布如表2所示.與表1相同，其中其他項(xiàng)包括捕獲次數(shù)較少的多種異常.組件拋出的異常如果被APP捕獲則可以避免APP崩潰等一系列問(wèn)題.我們通過(guò)對(duì)捕獲到的異常進(jìn)行分析，可以更加清楚地知道在相應(yīng)APP中容易產(chǎn)生問(wèn)題的組件或模塊，可以使開(kāi)發(fā)者在對(duì)APP更新時(shí)更具有針對(duì)性，在開(kāi)發(fā)類似模塊時(shí)可以降低同類問(wèn)題產(chǎn)生的概率.

Table 2 Catching Exception Distribution Statistics表2 捕獲異常分布統(tǒng)計(jì)

4.3 System_Server崩潰

對(duì)測(cè)試數(shù)據(jù)分析的過(guò)程中，發(fā)現(xiàn)APP的崩潰可能會(huì)引發(fā)system_server(系統(tǒng)服務(wù))的崩潰，并產(chǎn)生級(jí)聯(lián)崩潰.進(jìn)一步分析，在FuzzerAPP的測(cè)試過(guò)程中，共有41款A(yù)PP引發(fā)系統(tǒng)服務(wù)崩潰，約占測(cè)試集APP數(shù)量的16.47%.而在JarJarBinks工具測(cè)試中，僅發(fā)現(xiàn)3個(gè)Activity可以導(dǎo)致系統(tǒng)服務(wù)崩潰.實(shí)驗(yàn)中，發(fā)現(xiàn)導(dǎo)致系統(tǒng)服務(wù)崩潰的APP共有41款.在一定程度上證明了第三方APP不如系統(tǒng)預(yù)留APP的魯棒性高.

分別定位到41款A(yù)PP在系統(tǒng)服務(wù)崩潰時(shí)的輸出，分析其崩潰過(guò)程以及原因.分析得出系統(tǒng)服務(wù)崩潰時(shí)的過(guò)程如圖7所示.在圖7中，在Fatal exception 處為Android系統(tǒng)框架層提供的一些關(guān)鍵性服務(wù)，如ActivityManager，WindowManager等.Exit zygote處為測(cè)試時(shí)system server在系統(tǒng)中的PID.

Fig. 7 Cascaded collapse圖7 級(jí)聯(lián)崩潰

從圖7中可以知道，正是APP的未捕獲異常引發(fā)了system_server的中斷，最終導(dǎo)致zygote的重啟.zygote為Android APP的孵化進(jìn)程，system_server進(jìn)程由zygote進(jìn)程孵化，這二者在Android系統(tǒng)體系中具有非常重要的地位.一旦system_server進(jìn)程被殺死，系統(tǒng)的Dalvik 子系統(tǒng)(運(yùn)行安卓APP的Java虛擬機(jī))就會(huì)重新啟動(dòng)，這會(huì)讓設(shè)備看上去像重新啟動(dòng)了一樣.

對(duì)圖7中Fatal exception處的崩潰組件進(jìn)行統(tǒng)計(jì)，如表3所示，對(duì)造成這些組件崩潰的原因進(jìn)行統(tǒng)計(jì)，如表4所示.從表3和表4中可以看出這些異常主要為非法變量異常和越界異常.同時(shí)，表內(nèi)的所有異常均為與數(shù)據(jù)變量相關(guān)的異常種類.分析認(rèn)為，這些異常主要是由組件在接收外部Intent時(shí)，對(duì)接收到的數(shù)據(jù)不加處理而直接使用造成的.

Table 3 System Component Crash Triggered by APP Crash表3 由APP崩潰引發(fā)的系統(tǒng)組件崩潰

Table 4 Exceptions that Causes APP to Crash表4 引發(fā)APP崩潰的異常

4.4 測(cè)試模塊暴露示例分析

隨著Android APP開(kāi)發(fā)機(jī)制的日益完善，大多數(shù)APP必須通過(guò)多種測(cè)試后才能正式對(duì)外發(fā)布.對(duì)Android APP的測(cè)試，可以通過(guò)其他軟件進(jìn)行測(cè)試，也可以在APP內(nèi)構(gòu)建測(cè)試模塊進(jìn)行測(cè)試.在測(cè)試過(guò)程中，我們發(fā)現(xiàn)包括多款知名購(gòu)物軟件、閱讀軟件、打車(chē)軟件等在內(nèi)的多款A(yù)PP存在測(cè)試模塊暴露的問(wèn)題.這些暴露的測(cè)試模塊包括Activity和Service組件.

測(cè)試模塊的暴露進(jìn)一步可能帶來(lái)更加嚴(yán)重的安全問(wèn)題.在發(fā)現(xiàn)測(cè)試模塊暴露的APP中，以購(gòu)物類軟件暴露出的問(wèn)題較為嚴(yán)重.由于購(gòu)物類軟件與用戶財(cái)產(chǎn)密切相關(guān)，因此帶來(lái)的問(wèn)題也更為嚴(yán)重.在多款A(yù)PP的暴露組件內(nèi)，有鏈接內(nèi)網(wǎng)的Web頁(yè)面，有未對(duì)外公開(kāi)的內(nèi)部測(cè)試框架，有多種測(cè)試引擎，有多種功能測(cè)試模塊等.這些內(nèi)容可以給開(kāi)發(fā)者大量關(guān)于APP架構(gòu)、測(cè)試、網(wǎng)絡(luò)連接甚至服務(wù)器的信息.如果惡意攻擊者獲得這些信息，可能會(huì)對(duì)該APP進(jìn)行針對(duì)性的攻擊，如利用此客戶端和其他惡意軟件合謀進(jìn)行DDoS攻擊等.

4.5 實(shí)驗(yàn)對(duì)比

在之前的研究工作中，也存在著使用模糊測(cè)試方法測(cè)試APP的工具.Intent Fuzzer[14]和JarJarBinks[10]就是這樣的工具.Intent Fuzzer和JarJarBinks與FuzzerAPP具有類似之處，因此我們將對(duì)這三者在功能、性能以及測(cè)試結(jié)果等方面進(jìn)行對(duì)比，結(jié)果如表5～8所示.

Table 5 Component Support表5 對(duì)組件的支持

Table 6 Test Performance and Test Objectives表6 測(cè)試性能和測(cè)試對(duì)象

Table 7 Intent Construction Category表7 Intent 構(gòu)建類別

Table 8 Test Results表8 測(cè)試結(jié)果

在表5～8中，“√”表示工具支持相應(yīng)功能或者測(cè)試結(jié)果包含相應(yīng)方面.Intent Fuzzer提供對(duì)Android APP的基本測(cè)試功能，在官方網(wǎng)站并沒(méi)有提供對(duì)APP的測(cè)試結(jié)果，因此，在表5～8中對(duì)應(yīng)條目用“-”表示不包含該項(xiàng).

FuzzerAPP與JarJarBinks在功能上具有一定的相似性，因此我們?cè)敿?xì)比對(duì)這2種測(cè)試工具.在JarJarBinks中得出以下結(jié)論：APP組件缺乏對(duì)異常的處理；當(dāng)發(fā)送特殊Intent時(shí)可以從用戶層造成Android運(yùn)行時(shí)的崩潰.對(duì)于FuzzerAPP，除了JarJarBinks中發(fā)現(xiàn)的問(wèn)題外，還發(fā)現(xiàn)在測(cè)試集中4.02%的APP存在測(cè)試模塊暴露的問(wèn)題.測(cè)試模塊的暴露會(huì)帶來(lái)包括拒絕服務(wù)在內(nèi)的一系列安全問(wèn)題.

綜上所述，F(xiàn)uzzerAPP與Intent Fuzzer相比，提供了更加豐富的功能.FuzzerAPP與JarJarBinks相比，不僅二者測(cè)試目標(biāo)不同，而且在測(cè)試結(jié)果方面，F(xiàn)uzzerAPP比JarJarBinks發(fā)現(xiàn)了更多APP存在的問(wèn)題.

5 結(jié)束語(yǔ)

本文提出了一種對(duì)Android第三方APP組件通信魯棒性進(jìn)行測(cè)試的方案.該方法使用Android SDK提供的數(shù)據(jù)構(gòu)建高覆蓋面的測(cè)試用例，并將其發(fā)送給目標(biāo)組件，最后對(duì)收集到的數(shù)據(jù)進(jìn)行分析.我們根據(jù)所提出的方法實(shí)現(xiàn)了FuzzerAPP工具.最終的實(shí)驗(yàn)結(jié)果表明了測(cè)試方法的有效性以及測(cè)試工具的實(shí)用性.

[1]Zhang Yuqing, Wang Kai, Yang Huan, et al. Survey of Android OS security[J]. Journal of Computer Research and Development, 2015, 52(7): 1385-1396 (in Chinese)(張玉清, 王凱, 楊歡, 等. Android 安全綜述[J]. 計(jì)算機(jī)研究與發(fā)展, 2015, 52(7): 1385-1396)

[2]Google Inc. Android security[EB/OL]. [2015-10-10]. https://source.android.com/devices/tech/s-ecurity/index.html

[3]Google Inc. UI/application exerciser monkey[EB/OL]. [2015-10-10]. http://developer.android.com/tools/help/monkey.html

[4]Google Inc. MonkeyRunner[EB/OL]. [2015-10-10]. http://developer.android.com/tools/help/mon-keyrunner_concepts.html

[5]Yunmai Co.Ltd.DroidPilot[EB/OL]. [2015-10-10]. https://droidpilot.wordpress.com

[6]MacHiry A, Tahiliani R, Naik M. Dynodroid: An input generation system for Android apps[C] //Proc of the 9th Joint Meeting on Foundations of Software Engineering. New York: ACM, 2013: 1-12

[7]Koski D, Lee C P, Maganty V, et al. Fuzz revisited: A re-examination of the reliability of UNIX utilities and services[R]. Madison:University of Wisconsin-Madison, Computer Sciences Department, 1995

[8]Miller B P, Fredriksen L, So B. An empirical study of the reliability of UNIX utilities[J]. Communications of the ACM, 1990, 33(12): 32-44

[9]Forrester J E, Miller B P. An empirical study of the robustness of Windows NT applications using random testing[C] //Proc of the 4th USENIX Windows System Symp. Berkeley, CA: USENIX Association, 2000: 59-68

[10]Miller B P, Cooksey G, Moore F. An empirical study of the robustness of MACOS applications using random testing[C] //Proc of the 1st Int Workshop on Random Testing. New York: ACM, 2006: 46-54

[11]Mulliner C, Miller C. Fuzzing the phone in your phone[J/OL]. Black Hat USA, 2009 [2015-10-10]. http://mulliner.org/security/sms/feed/smsfuzz_26c3.pdf

[12]Dismfyp. Android kernel fuzzer[EB/OL]. [2015-10-10]. https://androidfuzzing.wordpress.c-om

[13]iSEC. Intent fuzzer[EB/OL]. [2016-03-22]. https://www.isecpartners.com/tools/mobile-se-curity/intent-fuzzer.aspx

[14]Maji A K, Arshad F A, Bagchi S, et al. An empirical study of the robustness of inter-component communication in Android[C] //Proc of the 42nd Annual IEEE/IFIP Int Conf on Dependable Systems and Networks. Piscataway, NJ: IEEE, 2012: 1-12

[15]Ye H, Cheng S, Zhang L, et al. Droidfuzzer: Fuzzing the Android apps with intent-filter tag[C] //Proc of Int Conf on Advances in Mobile Computing & Multimedia. New York: ACM, 2013: 68

[16]Sasnauskas R, Regehr J. Intent fuzzer: Crafting intents of death[C] //Proc of the 2014 Joint Int Workshop on Dynamic Analysis (WODA) and Software and System Performance Testing, Debugging, and Analytics (PERTEA). New York: ACM, 2014: 1-5

[17]Chin E, Felt A P, Greenwood K, et al. Analyzing inter-application communication in Android[C] //Proc of the 9th Int Conf on Mobile Systems Applications and Services. New York: ACM, 2011: 239-252

[18]Kantola D, Chin E, He W, et al. Reducing attack surfaces for intra-application communication in Android[C] //Proc of the 2nd ACM Workshop on Security and Privacy in Smartphones and Mobile Devices. New York: ACM, 2012: 69-80

[19]Fu Jianming, Li Pengwei, Yi Qiao, et al. A static detection of security defects between inter-components’ communication[J]. Journal of Huazhong University of Science and Technology: Natural Science Edition, 2013, 12(41): 259-264 (in Chinese)(傅建明, 李鵬偉, 易喬, 等. Android 組件間通信的安全缺陷靜態(tài)檢測(cè)方法[J]. 華中科技大學(xué)學(xué)報(bào):自然科學(xué)版, 2013, 12(41): 259-264)

[20]Google Inc. Intent class overview[EB/OL].[2015-10-10]. http://developer.android.com/reference/android/content/Intent.html

Zhang Mi, born in 1990. Master in the School of Cyber Engineering at Xidian University. His current research interests include mobile security and vulnerability discovery.

Yang Li, born in 1977. Associate professor in the School of Cyber Engineering at Xidian University. Senior member of CCF. His current research interests include network security and mobile security.

Zhang Junwei, born in 1982. Associate professor in the School of Cyber Engineering at Xidian University. His current research interests include cryptography and network security (jwzhangxd@126.com).

FuzzerAPP：The Robustness Test of Application Component Communication in Android

Zhang Mi, Yang Li, and Zhang Junwei

(SchoolofCyberEngineering,XidianUniversity,Xi’an710071)

The study of Android security has attracted wide attention because of the huge share in operation system market for mobile devices. Aiming at the security issues of Android application, this paper presents a robustness test scheme of application components based on fuzzy testing method. Firstly, a test set and the corresponding test cases are designed. These cases are sent to a target application for collecting and analyzing the test data. Considering the time, efficiency and other factors, the test case is sent to the application components to be tested. Then, the interaction information of the target component in the test process and the statistical analysis of the output data are analyzed. According to the design of test scheme, a platform named as FuzzerAPP is implemented which can test the robustness of the common applications in Android system. Many applications in some famous Android application markets are tested under FuzzerAPP, and the experiments results are collected. By the analysis of the test data, we find that if FuzzerAPP sends a particular Intent to the target application, it will make the application crash or even lead to the cascading breakdown of system services. Besides, there is a test module exposure problem in many applications of the test set, which can cause serious security problems such as privacy leaks and DoS (denial of service attacks). Finally, on contrast of other similar plans in component supporting, test performance, test objectives and Intent construction categories, the results show the effectiveness of the test method and the practicability of the test platform.

Android; components communication; fuzzy test; robustness; test module exposure

2015-11-23；

2016-03-22

國(guó)家自然科學(xué)基金項(xiàng)目(61671360,61672409,61672415,61672413,61472310,U1135002);中央高?；究蒲袠I(yè)務(wù)費(fèi)項(xiàng)目(JB161505,BDZ011402)；信息保障重點(diǎn)實(shí)驗(yàn)室開(kāi)放課題(KJ-14-109) This work was supported by the National Natural Science Foundation of China (61671360, 61672409, 61672415, 61672413, 61472310, U1135002), the Fundamental Research Funds for the Central Universities (JB161505, BDZ011402), and the Foundation of Science and Technology on Information Assurance Laboratory (KJ-14-109).

楊力(yangli@xidian.edu.cn)

TP39