張 密 楊 力 張俊偉

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

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

張 密 楊 力 張俊偉

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

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

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

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

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

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

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

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

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

1 背景知識

1.1 Android APP組件

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

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

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

3) Broadcast Receiver.Broadcast是一種廣泛使用的在APP間傳輸信息的機制.而Broadcast Receiver是對發(fā)送來的廣播進行過濾接受并響應(yīng)的一類組件.

4) Content Provider.Content Provider是Android提供的一種標準共享數(shù)據(jù)的機制.

1.2 組件通信

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

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

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

1.3 組件暴露

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

2 方案設(shè)計

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

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

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

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

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

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

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

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

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

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

接下來，將對本方案中的核心模塊和功能進行詳細介紹.

2.1 組件詳細信息獲取

待測APP組件詳細信息的獲取在信息獲取模塊完成.該模塊主要負責使用靜態(tài)分析方法對待測APP安裝包進行分析.對待測組件詳細信息的獲取，主要通過以下方式獲得：

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

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

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

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

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

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

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

4) 訪問待測應(yīng)用程序組件是否需要權(quán)限，若需要則記錄訪問權(quán)限.

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

2.2 測試用例生成策略

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

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

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

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

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

3) 僅指定Action域、Data域為空或為隨機值.Action域的值來自Android SDK提供的標準Action值，Data域為空或從構(gòu)建的Data數(shù)據(jù)庫中隨機選擇.例如：Intent{act=ACTION_EDIT;cmp=com.example.appcom.example.app.someComponent}.

4) 僅指定Data域、Action域為空或為隨機值.Data域的值來自構(gòu)建的Data數(shù)據(jù)庫，Action域值為隨機標準Action，Action可以為空.例如：Intent{dat=http:www.***.com;cmp=com.example.appcom.example.app.someComponent}.

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

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

2.3 測試算法

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

算法1. APP測試算法.

Input:exAPP-the application to be examined:

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

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

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

sleepTime=測試線程成功啟動目標組件時休眠時間;

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

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

3 FuzzerAPP實現(xiàn)

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

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

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

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

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

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

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

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

Fig. 4 FuzzerAPP UI圖4 FuzzerAPP界面

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

4 實驗及分析

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

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

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

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

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

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

4.1 APP崩潰分布

在向組件發(fā)送依據(jù)構(gòu)造策略構(gòu)造的Intent時，組件可能會因為未捕獲異常等原因造成APP崩潰.當APP崩潰時，會由AndroidRuntime拋出具有“Fatal Exceptoin：main”標志的異常.相應(yīng)地，可以通過“Fatal Exception：main”標志來統(tǒng)計APP的崩潰次數(shù)以及跟蹤造成崩潰的異常種類.

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

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

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

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

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

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

1) 未捕獲異常

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

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

在表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%.由此可見，APP未捕獲異常與APP組件缺乏對輸入數(shù)據(jù)的處理有極大關(guān)系.

2) 捕獲異常

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

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

4.3 System_Server崩潰

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

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

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

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

對圖7中Fatal exception處的崩潰組件進行統(tǒng)計，如表3所示，對造成這些組件崩潰的原因進行統(tǒng)計，如表4所示.從表3和表4中可以看出這些異常主要為非法變量異常和越界異常.同時，表內(nèi)的所有異常均為與數(shù)據(jù)變量相關(guān)的異常種類.分析認為，這些異常主要是由組件在接收外部Intent時，對接收到的數(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 測試模塊暴露示例分析

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

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

4.5 實驗對比

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

Table 5 Component Support表5 對組件的支持

Table 6 Test Performance and Test Objectives表6 測試性能和測試對象

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

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

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

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

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

5 結(jié)束語

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

[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]. 計算機研究與發(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)檢測方法[J]. 華中科技大學學報:自然科學版, 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

國家自然科學基金項目(61671360,61672409,61672415,61672413,61472310,U1135002);中央高校基本科研業(yè)務(wù)費項目(JB161505,BDZ011402)；信息保障重點實驗室開放課題(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