Android應(yīng)用權(quán)限泄露漏洞的測試方法及系統(tǒng)的制作方法
【專利摘要】本發(fā)明提供一種Android應(yīng)用權(quán)限泄露漏洞的測試方法，包括：步驟一、從Android應(yīng)用程序包中的Manifest文件提取所有對外公開的Service和Broadcast?Receiver組件；步驟二、針對Android應(yīng)用中Service和Broadcast?Receiver兩種模塊間通訊組件接口，提取Action、Data和Extras信息，構(gòu)造作為模糊測試輸入的Intent對象；步驟三、通過ICC機制，由代理應(yīng)用向應(yīng)用目標(biāo)組件通訊接口發(fā)送構(gòu)造好的Intent對象；和步驟四、通過修改Android系統(tǒng)中的權(quán)限檢查函數(shù)，監(jiān)控權(quán)限檢查日志情況，基于日志作出是否發(fā)生權(quán)限泄露的判斷。本發(fā)明還提供一種Android應(yīng)用權(quán)限泄露漏洞的測試系統(tǒng)。本發(fā)明提供的方法和系統(tǒng)無需人工參與，為大規(guī)模自動化發(fā)現(xiàn)Android應(yīng)用中權(quán)限泄露安全漏洞提供了有力支持，并且具有無誤報和低漏報的優(yōu)點。
【專利說明】Android應(yīng)用權(quán)限泄露漏洞的測試方法及系統(tǒng)
【技術(shù)領(lǐng)域】
[0001 ] 本發(fā)明涉及計算機程序測試【技術(shù)領(lǐng)域】，尤其涉及一種Android (安卓系統(tǒng))應(yīng)用權(quán)限泄露漏洞的測試方法及系統(tǒng)。
【背景技術(shù)】
[0002]Android智能手機已經(jīng)越來越普及，Android應(yīng)用市場也增長迅猛,給用戶帶來方便的同時，用戶敏感數(shù)據(jù)也面臨被惡意竊取的威脅。谷歌引入一種權(quán)限模型對用戶手機中的各種敏感數(shù)據(jù)加以保護，然而某些惡意應(yīng)用可以在不申請任何權(quán)限的情況下，通過調(diào)用有漏洞應(yīng)用的公開接口來訪問敏感數(shù)據(jù)，這種現(xiàn)象稱為權(quán)限泄露，也叫做權(quán)限重委托。為了減少對用戶個人敏感數(shù)據(jù)的威脅，谷歌設(shè)計了一種基于權(quán)限的模型，默認(rèn)情況下Android應(yīng)用被禁止獲得任何危險權(quán)限，安裝過程中應(yīng)用向用戶申請所需權(quán)限，得到用戶許可后，運行時方可訪問敏感數(shù)據(jù)和調(diào)用相關(guān)系統(tǒng)API。
[0003]關(guān)于權(quán)限泄露漏洞檢測的研究方面，目前已經(jīng)存在一些檢測技術(shù)，主要采用靜態(tài)分析的方法，在對應(yīng)用反編譯后得到的Java源代碼或Dalvik字節(jié)碼中根據(jù)某些特征查找權(quán)限泄露漏洞。以上靜態(tài)分析方法主要依賴于程序控制流圖技術(shù)，通過這種技術(shù)繪制Android應(yīng)用程序可能的執(zhí)行路徑，結(jié)合數(shù)據(jù)流分析和污點標(biāo)記技術(shù)，從執(zhí)行入口函數(shù)動態(tài)跟蹤相關(guān)數(shù)據(jù)直到權(quán)限泄露觸發(fā)點。例如DroidChecker將Android應(yīng)用反編譯到Java源代碼級別，提取具有潛在權(quán)限泄露漏洞的組件，針對每個組件構(gòu)造程序控制流圖，利用靜態(tài)污點標(biāo)記技術(shù)跟蹤數(shù)據(jù)傳輸路徑，依據(jù)相關(guān)特征定位權(quán)限泄露觸發(fā)點。Woodpecker提取Android應(yīng)用Dalvik字節(jié)碼，構(gòu)造程序控制流圖確定潛在的執(zhí)行路徑，采用過程間數(shù)據(jù)流分析技術(shù)，定位觸發(fā)敏感權(quán)限泄露的路徑。
[0004]現(xiàn)有技術(shù)僅停留在對Android應(yīng)用靜態(tài)代碼進(jìn)行分析，沒有考慮動態(tài)的測試方法。使用的反匯編技術(shù)在正確性方面存在一定的障礙，目前無法實現(xiàn)將Android應(yīng)用完全正確地反編譯成Java代碼。程序控制流圖技術(shù)雖然是研究較為成熟的技術(shù)，但Android應(yīng)用程序的Java繼承機制和異步回調(diào)特性導(dǎo)致Android控制流圖的構(gòu)造存在一定的難度。除此之外，靜態(tài)分析技術(shù)依據(jù)的權(quán)限泄露漏洞特征定義模糊，沒有嚴(yán)格規(guī)范的特征定義模式，在一定程度上導(dǎo)致漏洞檢測誤報和漏報現(xiàn)象。

【發(fā)明內(nèi)容】

[0005]本發(fā)明要解決的技術(shù)問題是，針對現(xiàn)有技術(shù)的不足，提供一種Android應(yīng)用權(quán)限泄露漏洞的測試方法及系統(tǒng)，降低權(quán)限泄露檢測漏報率。
[0006]根據(jù)本發(fā)明一個方面，提供一種Android應(yīng)用權(quán)限泄露漏洞的測試系統(tǒng)，包括:控制端和位于Android系統(tǒng)上的代理端；其中，代理端包括:系統(tǒng)權(quán)限檢查模塊，適于通過修改Android系統(tǒng)中的權(quán)限檢查函數(shù)，將通過檢查的權(quán)限相關(guān)信息記錄到系統(tǒng)日志中；Extra信息獲取模塊，適于通過修改Android系統(tǒng)中的獲取Extras信息函數(shù),將所獲取的Extras信息的鍵和值數(shù)據(jù)類型相關(guān)信息記錄到系統(tǒng)日志中；和代理應(yīng)用模塊，適于接收控制端構(gòu)造好的Intent對象,然后通過Android ICC機制發(fā)送至待測試應(yīng)用的目標(biāo)組件；其中，控制端包括:Intent構(gòu)造模塊，分別與所述Extra信息獲取模塊和代理應(yīng)用模塊連接，適于通過所述代理應(yīng)用模塊從待測試應(yīng)用中提取Action、Data信息，適于利用從所述Extra信息獲取模塊得到Android系統(tǒng)反饋的Extras信息的鍵和值數(shù)據(jù)類型,構(gòu)造合適的Extras鍵值對信息，還適于基于以上得到的ActioruData和Extras信息構(gòu)造Intent對象，并通過代理應(yīng)用模塊發(fā)送至待測試應(yīng)用的目標(biāo)組件；和權(quán)限泄露檢測模塊，與所述系統(tǒng)權(quán)限檢查模塊連接，適于獲取所述系統(tǒng)權(quán)限檢查模塊對所述待測試應(yīng)用的權(quán)限檢查輸出的日志，判斷所述待測試應(yīng)用是否存在權(quán)限泄露漏洞。
[0007]根據(jù)本發(fā)明另一個方面，提供一種Android應(yīng)用權(quán)限泄露漏洞的測試方法，包括:步驟一、從Android應(yīng)用程序包中的Manifest文件提取所有對外公開的Service和Broadcast Receiver 組件；步驟二、針對 Android 應(yīng)用中 Service 和 Broadcast Receiver兩種模塊間通訊組件接口，提取Action、Data和Extras信息，構(gòu)造作為模糊測試輸入的Intent對象；步驟三、通過ICC機制，由代理應(yīng)用向應(yīng)用目標(biāo)組件通訊接口發(fā)送構(gòu)造好的Intent對象；和步驟四、通過修改Android系統(tǒng)中的權(quán)限檢查函數(shù),監(jiān)控權(quán)限檢查日志情況，基于日志作出是否發(fā)生權(quán)限泄露的判斷。
[0008]可選的，在步驟四后還包括:步驟五、重復(fù)以上步驟直至遍歷完成步驟二中所有的Action、Data 域、Extras 域?qū)嵗?br> [0009]可選的,步驟二中構(gòu)造Intent對象進(jìn)一步包括:從應(yīng)用程序包Manifest文件中的intent-filter標(biāo)簽中提取顯式Action,以及從應(yīng)用程序包反編譯后的smali代碼里提取以包名為前綴的隱式Action ;根據(jù)intent-filter中相應(yīng)Data規(guī)則定義預(yù)先生成合適的Data域數(shù)據(jù)；和通過修改手機系統(tǒng)中獲取Extras信息的API函數(shù)監(jiān)控獲取Extras鍵和值數(shù)據(jù)類型。
[0010]可選的，步驟三進(jìn)一步包括:通過向Started Service和Broadcast Receiver兩種目標(biāo)組件發(fā)送顯示Intent的方式來進(jìn)行權(quán)限泄露檢測。
[0011]可選的，步驟四修改Android系統(tǒng)中的權(quán)限檢查函數(shù)進(jìn)一步包括:通過修改Android系統(tǒng)ActivityManagerService服務(wù)中的權(quán)限檢查函數(shù),將Android系統(tǒng)服務(wù)對應(yīng)用程序執(zhí)行過程中通過權(quán)限檢查的權(quán)限名稱和Uid號輸出到系統(tǒng)日志中。
[0012]眾所周知，Android應(yīng)用是用Java高級程序設(shè)計語言開發(fā)的，Java語言的繼承和多態(tài)機制在Android程序開發(fā)中廣泛應(yīng)用，這兩種機制的使用在一定程度上影響了權(quán)限泄露靜態(tài)分析的正確性。面對越來越多的Android應(yīng)用，需要發(fā)明一種自動化的Android應(yīng)用權(quán)限泄漏漏洞測試方法，無需大量的人力手工參與，即可準(zhǔn)確的發(fā)現(xiàn)權(quán)限泄露漏洞。
[0013]與現(xiàn)有技術(shù)相比，本發(fā)明的優(yōu)點在于:
[0014]本發(fā)明無需人工參與，為大規(guī)模自動化發(fā)現(xiàn)Android應(yīng)用中權(quán)限泄露安全漏洞提供了有力支持。與現(xiàn)有技術(shù)相比，存在兩個方面的優(yōu)勢:無誤報和低漏報。
[0015]現(xiàn)有技術(shù)采用靜態(tài)分析的方法，只在靜態(tài)代碼級進(jìn)行分析，并非動態(tài)的實際測試，檢測結(jié)果不免會出現(xiàn)誤報情況。本發(fā)明將模糊測試技術(shù)應(yīng)用到權(quán)限泄露檢測中，采用動態(tài)的測試方法檢測權(quán)限泄露，檢測到的權(quán)限泄露結(jié)果均為實際的Intent對象觸發(fā)，并可以根據(jù)日志中的記錄信息還原重現(xiàn)權(quán)限泄露過程。
[0016]本發(fā)明設(shè)計了一套啟發(fā)式的系統(tǒng)反饋機制，利用從Android系統(tǒng)反饋的Extras信息，對Intent對象進(jìn)行修整,構(gòu)造更加完善的Intent對象,進(jìn)行多輪Fuzz測試,可以覆蓋更廣的執(zhí)行路徑，有效地降低檢測漏報率。
【專利附圖】

【附圖說明】
[0017]圖1是根據(jù)本發(fā)明一個實施例提供的Android應(yīng)用權(quán)限泄露漏洞的測試系統(tǒng)的結(jié)構(gòu)示意圖；
[0018]圖2是根據(jù)本發(fā)明另一個實施例提供的Android應(yīng)用權(quán)限泄露漏洞的測試系統(tǒng)的工作方法流程圖；
[0019]圖3是根據(jù)本發(fā)明另一個實施例提供的Android應(yīng)用權(quán)限泄露漏洞的測試系統(tǒng)的工作方法中，構(gòu)造Intent對象方法的流程圖。
【具體實施方式】
[0020]為了使本發(fā)明的目的、技術(shù)方案及優(yōu)點更加清楚明白，以下結(jié)合附圖，對本發(fā)明進(jìn)一步詳細(xì)說明。應(yīng)當(dāng)理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。
[0021]發(fā)明人經(jīng)研究發(fā)現(xiàn):ICC(InterComponent Communication)是一種 Android 應(yīng)用組件間進(jìn)行通信的機制。Android應(yīng)用中使用ICC機制通信的有三種組件Activity、Service和Broadcast Receiver。這三種組件之間可以通過Intent對象進(jìn)行通信，Intent對象中包含通信過程中傳輸?shù)臄?shù)據(jù)信息。Intent有顯式和隱式兩種，顯式Intent中包含組件名稱來指定目標(biāo)組件，隱式Intent不指定目標(biāo)組件，由Android系統(tǒng)根據(jù)其包含的其他數(shù)據(jù)信息匹配合適的目標(biāo)組件。
[0022]開發(fā)者可以通過設(shè)置組件的“exported”屬性為“true”允許接收其它應(yīng)用向其發(fā)送 Intent 對象，設(shè)置為“false”則拒絕。Intent 對象包括 Action、Data、Category、Extras和Flags五種信息。其中Action表示所要執(zhí)行的某種動作，除了系統(tǒng)定義的Action外，開發(fā)者也可自定義Action，自定義的Action需要使用應(yīng)用程序包名作為前綴以免沖突；Data用來指定組件間通信所使用的數(shù)據(jù)，通常以URI的形式呈現(xiàn)；Categ0ry說明接收Intent對象的組件類型，只有隱式Intent才包含此信息；ExtraS是組件間通信過程中使用的其他數(shù)據(jù)信息，以鍵值對的形式表不；Flags是一些系統(tǒng)預(yù)定義的值,用以表不Android系統(tǒng)啟動Activity組件的方式。
[0023]當(dāng)有漏洞的應(yīng)用代理無權(quán)限的應(yīng)用執(zhí)行相應(yīng)的特權(quán)操作時，發(fā)生權(quán)限泄露行為。例如，已經(jīng)成功申請權(quán)限P的應(yīng)用程序的一個組件C對其它應(yīng)用公開，且沒有對外部調(diào)用者進(jìn)行相應(yīng)的權(quán)限檢查保護，于是惡意應(yīng)用便可以通過特意構(gòu)造Intent對象發(fā)送至組件C，來執(zhí)行未經(jīng)授權(quán)的操作。為避免權(quán)限泄露，組件C應(yīng)該通過在Manifest文件添加組件權(quán)限保護屬性或者調(diào)用checkPermission API進(jìn)行權(quán)限檢查，以確保外部調(diào)用者已經(jīng)被用戶授予相應(yīng)的權(quán)限方可訪問。然而，Android開發(fā)者并不十分了解這種ICC機制中的潛在風(fēng)險，會無意地對外公開某些應(yīng)用程序組件，或者因特殊需求有意對外公開組件卻沒用采取相應(yīng)的權(quán)限保護措施。
[0024]發(fā)明人經(jīng)研究還發(fā)現(xiàn):模糊測試(以下簡稱Fuzz)技術(shù)，是一種通過向目標(biāo)系統(tǒng)提供非預(yù)期輸入并監(jiān)視異常結(jié)果來發(fā)現(xiàn)軟件漏洞的方法；可以將Fuzz技術(shù)應(yīng)用到Android應(yīng)用權(quán)限泄露檢測中，動態(tài)地給目標(biāo)應(yīng)用程序發(fā)送構(gòu)造好的測試數(shù)據(jù)，同時查看是否觸發(fā)權(quán)限泄露現(xiàn)象。
[0025]基于上述發(fā)現(xiàn)，發(fā)明人提出對Android應(yīng)用權(quán)限泄露漏洞進(jìn)行自動化模糊測試，可完成對第三方市場Android應(yīng)用和第三方手機ROM預(yù)裝應(yīng)用自動化測試，采用控制端和代理端協(xié)同工作的模式，控制端運行在PC主機上、測試主機或測試服務(wù)器上，代理端核心部件是一個代理應(yīng)用程序，運行在Android手機或模擬器上。
[0026]根據(jù)本發(fā)明一個實施例，提供一種Android應(yīng)用權(quán)限泄露漏洞的測試系統(tǒng)。如圖1所示，測試系統(tǒng)包括:控制端11和安卓系統(tǒng)上的代理端12。
[0027]代理端12包括:
[0028](I)系統(tǒng)權(quán)限檢查模塊121，適于通過修改Android系統(tǒng)中的權(quán)限檢查函數(shù)，將通過檢查的權(quán)限相關(guān)信息記錄到系統(tǒng)日志中；
[0029](2) Extra信息獲取模塊122,適于通過修改Android系統(tǒng)中的獲取Extras信息函數(shù)，將所獲取的Extras信息的鍵和值數(shù)據(jù)類型相關(guān)信息記錄到系統(tǒng)日志中；
[0030](3)代理應(yīng)用程序123 (或代理應(yīng)用模塊123)，適于接收控制端11 (即Intent構(gòu)造模塊112)構(gòu)造好的Intent對象,然后通過Android ICC機制發(fā)送至待測試應(yīng)用目標(biāo)組件。
[0031]控制端11包括:
[0032](I) Intent構(gòu)造模塊112，分別與Extra信息獲取模塊122和代理應(yīng)用程序123連接，適于(a)通過代理應(yīng)用程序123從應(yīng)用程序包(即待測試應(yīng)用程序21)中提取Action、Data信息，(b)利用從Extra信息獲取模塊122得到Android系統(tǒng)反饋的Extras信息的鍵和值數(shù)據(jù)類型，構(gòu)造合適的Extras鍵值對信息，(C)基于以上得到的Action、Data和Extras信息構(gòu)造Intent對象,通過代理端應(yīng)用123發(fā)送至被測試應(yīng)用的目標(biāo)組件；
[0033](2)權(quán)限泄露檢測模塊111，與系統(tǒng)權(quán)限檢查模塊121連接，適于獲取Android系統(tǒng)權(quán)限檢查模塊121對當(dāng)前被測試應(yīng)用的權(quán)限檢查輸出的日志，判斷當(dāng)前被測應(yīng)用是否存在權(quán)限泄露漏洞。
[0034]需要注意的是，代理應(yīng)用程序123與Intent構(gòu)造模塊112之間的數(shù)據(jù)連接是雙向數(shù)據(jù)連接。
[0035]根據(jù)本發(fā)明一個實施例，修改Android系統(tǒng)源代碼或手機ROM完成以上日志輸出功能。
[0036]系統(tǒng)執(zhí)行過程描述如下:Intent構(gòu)造模塊112構(gòu)造好Intent對象后，發(fā)送至代理端12，代理端12的代理應(yīng)用程序123將Intent對象發(fā)送至待測試應(yīng)用程序21，此時，測試前已經(jīng)準(zhǔn)備好的系統(tǒng)權(quán)限檢查模塊121會輸出當(dāng)前被測試應(yīng)用通過檢查的權(quán)限至Android系統(tǒng)日志中，測試前已經(jīng)準(zhǔn)備好的獲取Extra信息模塊122會輸出當(dāng)前被測試應(yīng)用獲取的Extra信息到系統(tǒng)日志中。權(quán)限泄露檢測模塊111獲取系統(tǒng)日志中通過檢查的權(quán)限作為泄露權(quán)限，即權(quán)限泄露結(jié)果，Intent構(gòu)造模塊112獲取系統(tǒng)日志中的Extra信息構(gòu)造下一輪測試的Intent對象。
[0037]根據(jù)本發(fā)明一個實施例，如圖2所示，上述系統(tǒng)的檢測方法包括:
[0038]SlUIntent構(gòu)造模塊從Android應(yīng)用程序包中的Manifest文件提取所有對外公開的 Service 和 Broadcast Receiver 組件。[0039]S12、針對Android應(yīng)用中Service和Broadcast Receiver兩種模塊間通訊組件接口，Intent構(gòu)造模塊提取ActioruData和Extras信息,構(gòu)造作為模糊測試輸入的Intent對象。
[0040]因為Intent對象的Category用來說明接收Intent對象的組件類型，只有隱式Intent才包含此信息,而本發(fā)明只發(fā)送顯式Intent ；Flags是系統(tǒng)預(yù)定義的值,用以表示Android系統(tǒng)啟動Activity組件的方式,所以本實施例中構(gòu)造Intent對象時只需考慮Action、Data和Extras三種數(shù)據(jù)信息。
[0041]S13、由手機端代理程序通過ICC機制向應(yīng)用目標(biāo)組件通訊接口發(fā)送構(gòu)造好的Intent 對象。
[0042]本實施例通過向Started Service和Broadcast Receiver兩種目標(biāo)組件發(fā)送顯不Intent的方式來進(jìn)行權(quán)限泄露檢測。只針對以上兩種目標(biāo)組件進(jìn)行Fuzz測試，主要因為Activity組件是與用戶交互的界面,惡意應(yīng)用無法隱蔽地進(jìn)行攻擊而容易被發(fā)現(xiàn),而BoundService與Started Service不同，不通過Intent對象進(jìn)行通信。之所以使用顯示Intent而不是隱式Intent，是因為顯示Intent的發(fā)送具有更高的目標(biāo)性，可以更準(zhǔn)確的對目標(biāo)組件進(jìn)行權(quán)限泄露檢測?？刂贫俗鳛镕uzz測試的控制中心，將構(gòu)造好的Intent對象通過套接字連接發(fā)送至代理端。代理端作為運行在Android系統(tǒng)上的應(yīng)用程序，負(fù)責(zé)將控制端構(gòu)造的Intent對象通過ICC機制發(fā)送給當(dāng)前被測試的應(yīng)用目標(biāo)組件，完成對Android應(yīng)用的動態(tài)模糊測試。
[0043]S14、通過修改Android系統(tǒng)中的權(quán)限檢查函數(shù),監(jiān)控權(quán)限檢查日志情況，控制端獲取日志并作出是否發(fā)生權(quán)限泄露的判斷。
[0044]通過修改Android系統(tǒng)ActivityManagerService服務(wù)中的權(quán)限檢查函數(shù)checkPermission (String permission, int pid, iht uid),將 Android 系統(tǒng)服務(wù)對應(yīng)用程序執(zhí)行過程中通過權(quán)限檢查的權(quán)限名稱和uid號輸出到系統(tǒng)日志中，控制端的權(quán)限泄露檢測模塊根據(jù)當(dāng)前被檢測應(yīng)用程序Uid號通過adb 1gcat操作提取對應(yīng)的權(quán)限作為權(quán)限泄露檢測結(jié)果，并將當(dāng)前應(yīng)用名稱、組件名稱、Intent對象和泄露權(quán)限記錄到日志中。
[0045]S15、重復(fù)以上步驟直至遍歷完成步驟S12中所有的ActioruData域、Extras域?qū)嵗?br> [0046]根據(jù)本發(fā)明另一個實施例,如圖3所示,上述步驟S12中構(gòu)造Intent對象進(jìn)一步包括:
[0047]S121、從應(yīng)用程序包Manifest文件中的intent-filter標(biāo)簽中提取顯式Action,以及從應(yīng)用程序包反編譯后的smali代碼里提取以包名為前綴的隱式Action。
[0048]構(gòu)造Intent的Action域包括兩部分，一方面對于開發(fā)者有意公開的組件來說，會在Manifest文件中定義其可以處理的intent-filter過濾規(guī)則,其中包括Action屬性，于是可以從應(yīng)用程序包Manifest文件中的intent-filter標(biāo)簽中提取Action信息,稱為顯示Action ;另一方面對于無意公開的組件,沒有相應(yīng)的intent-filter過濾規(guī)則可以使用，但是程序開發(fā)者會在代碼中比較接收Intent中的Action和程序中定義的Action,以此決定是否執(zhí)行進(jìn)一步的操作。于是可以從應(yīng)用程序包反編譯后的smali代碼里提取以包名為前綴的字符串，稱為隱式Action。
[0049]S122、從intent-filter中提取Data域信息并根據(jù)其規(guī)則定義預(yù)先生成合適的Data域數(shù)據(jù)。
[0050]對于顯示Action,所在的intent-filter中可能有相應(yīng)的Data域規(guī)則說明，可以根據(jù)其定義的Data域說明預(yù)先在Android系統(tǒng)中生成合適的數(shù)據(jù)。Data以URI格式表示，如scheme://host:port/path。在Fuzz測試之前,預(yù)先定義通用的數(shù)據(jù)類型，比如http://example, com/a.1pg 和 content://media/external/images/media/l,并在相應(yīng)的網(wǎng)站目錄和系統(tǒng)content provider中存儲圖片等數(shù)據(jù)。對于隱式Action,因沒有相應(yīng)的依據(jù)構(gòu)造Data,所以在構(gòu)造Intent時不考慮Data域。
[0051]S123、通過修改Android系統(tǒng)中獲取Extras信息的API函數(shù)監(jiān)控其(即Android系統(tǒng))獲取Extras的鍵和值數(shù)據(jù)類型。
[0052]Extras是Intent對象中的鍵值對信息,鍵是字符串類型，值是Java基本數(shù)據(jù)類型或Class類型。目標(biāo)組件接收Intent后,根據(jù)其中的Extras信息做出是否執(zhí)行進(jìn)一步操作的判斷。例如，某應(yīng)用組件接收Intent對象后，在其入口函數(shù)onStartCommandO中調(diào)用getStringExtraO函數(shù)提取Intent中“sms”鍵對應(yīng)的字符串類型數(shù)值，即所要發(fā)送的sms消息內(nèi)容，然后對此數(shù)值進(jìn)一步判斷，如果此值為NULL或空字符串，則不會執(zhí)行sendTextMessageO函數(shù)進(jìn)行sms消息發(fā)送操作，于是潛在的權(quán)限泄露漏洞就不會被檢測至IJ。由此可見，構(gòu)造合適的Extras信息可以覆蓋更廣的執(zhí)行路徑，有效地降低檢測漏報率。
[0053]通過修改手機系統(tǒng)中獲取Extras信息的API,比如getStringExtra (Stringname), getlntExtra (String name, int defaultValue)等，將獲取 Extras 的鍵和值數(shù)據(jù)類型以及對應(yīng)的應(yīng)用程序uid號輸出到Android系統(tǒng)日志中，控制端的Intent構(gòu)造模塊根據(jù)日志中的Extras信息構(gòu)建新的Extras鍵值對,再次構(gòu)造Intent對象進(jìn)行下一輪Fuzz測試，以達(dá)到更高的執(zhí)行路徑覆蓋率。
[0054]與上述一種Android應(yīng)用權(quán)限泄露漏洞的測試系統(tǒng)相對應(yīng)地，根據(jù)本發(fā)明一個實施例，提供一種Android應(yīng)用權(quán)限泄露漏洞的測試方法。該方法包括:
[0055]S31、從Android應(yīng)用程序包中的Manifest文件提取所有對外公開的Service和Broadcast Receiver 組件；
[0056]S32、針對Android應(yīng)用中Service和Broadcast Receiver兩種模塊間通訊組件接口，提取Action、Data和Extras信息,構(gòu)造作為模糊測試輸入的Intent對象；
[0057]S33、通過ICC機制，由代理應(yīng)用向應(yīng)用目標(biāo)組件通訊接口發(fā)送構(gòu)造好的Intent對象；
[0058]S34、通過修改Android系統(tǒng)中的權(quán)限檢查函數(shù),監(jiān)控權(quán)限檢查日志情況，基于日志作出是否發(fā)生權(quán)限泄露的判斷；
[0059]S35、重復(fù)以上步驟直至遍歷完成步驟S32中所有的ActioruData域、Extras域?qū)嵗?br> [0060]其中，S32可以進(jìn)一步包括:
[0061]S321、從應(yīng)用程序包Manifest文件中的intent-filter標(biāo)簽中提取顯式Action,以及從應(yīng)用程序包反編譯后的smali代碼里提取以包名為前綴的隱式Action ；
[0062]S322、從intent-filter中提取Data域信息并根據(jù)其規(guī)則定義預(yù)先生成合適的Data域數(shù)據(jù)；
[0063]S323、通過修改Android系統(tǒng)中荻取Extras信息的API函數(shù)監(jiān)控其(即Android系統(tǒng))獲取Extras鍵和值數(shù)據(jù)類型。
[0064]本發(fā)明上述實施例提供的方法和系統(tǒng)無需人工參與，為大規(guī)模自動化發(fā)現(xiàn)Android應(yīng)用中權(quán)限泄露安全漏洞提供了有力支持。與現(xiàn)有技術(shù)相比，存在兩個方面的優(yōu)勢:無誤報和低漏報。
[0065]現(xiàn)有技術(shù)采用靜態(tài)分析的方法，只在源代碼級進(jìn)行分析，并非動態(tài)的實際測試，檢測結(jié)果不免會出現(xiàn)誤報情況。本發(fā)明將模糊測試技術(shù)應(yīng)用到權(quán)限泄露檢測中，采用動態(tài)的測試方法檢測權(quán)限泄露，檢測到的權(quán)限泄露結(jié)果均為實際的Intent對象觸發(fā)，并可以根據(jù)日志中的記錄信息還原重現(xiàn)權(quán)限泄露過程。
[0066]本發(fā)明設(shè)計了一套啟發(fā)式的系統(tǒng)反饋機制，利用從Android系統(tǒng)反饋的Extras信息，對Intent對象的Extra域進(jìn)行修整,構(gòu)造更加完善的Intent對象,進(jìn)行多輪Fuzz測試，可以覆蓋更廣的執(zhí)行路徑，有效地降低檢測漏報率。
[0067]應(yīng)該注意到并理解，在不脫離后附的權(quán)利要求所要求的本發(fā)明的精神和范圍的情況下，能夠?qū)ι鲜鲈敿?xì)描述的本發(fā)明做出各種修改和改進(jìn)。因此，要求保護的技術(shù)方案的范圍不受所給出的任何特定示范教導(dǎo)的限制。
【權(quán)利要求】
1.一種Android應(yīng)用權(quán)限泄露漏洞的測試系統(tǒng),包括: 控制端和位于Android系統(tǒng)上的代理端； 其中，代理端包括: 系統(tǒng)權(quán)限檢查模塊，適于通過修改Android系統(tǒng)中的權(quán)限檢查函數(shù)，將通過檢查的權(quán)限相關(guān)信息記錄到系統(tǒng)日志中； Extra信息獲取模塊,適于通過修改Android系統(tǒng)中的獲取Extras信息函數(shù),將所獲取的Extras信息的鍵和值數(shù)據(jù)類型相關(guān)信息記錄到系統(tǒng)日志中；和 代理應(yīng)用模塊,適于接收控制端構(gòu)造好的Intent對象,然后通過Android ICC機制發(fā)送至待測試應(yīng)用的目標(biāo)組件； 其中，控制端包括: Intent構(gòu)造模塊，分別與所述Extra信息獲取模塊和代理應(yīng)用模塊連接，適于通過所述代理應(yīng)用模塊從待測試應(yīng)用中提取Action、Data信息，適于利用從所述Extra信息獲取模塊得到Android系統(tǒng)反饋的Extras信息的鍵和值數(shù)據(jù)類型,構(gòu)造合適的Extras鍵值對信息，還適于基于以上得到的ActioruData和Extras信息構(gòu)造Intent對象，并通過代理應(yīng)用模塊發(fā)送至待測試應(yīng)用的目標(biāo)組件；和 權(quán)限泄露檢測模塊，與所述系 統(tǒng)權(quán)限檢查模塊連接，適于獲取所述系統(tǒng)權(quán)限檢查模塊對所述待測試應(yīng)用的權(quán)限檢查輸出的日志，判斷所述待測試應(yīng)用是否存在權(quán)限泄露漏洞。
2.根據(jù)權(quán)利要求1所述的Android應(yīng)用權(quán)限泄露漏洞的測試系統(tǒng)，其中，所述控制端位于測試服務(wù)器。
3.根據(jù)權(quán)利要求1所述的Android應(yīng)用權(quán)限泄露漏洞的測試系統(tǒng)，其中，所述Intent構(gòu)造模塊還適于從所述待測試應(yīng)用的Manifest文件提取所有對外公開的Service和Broadcast Receiver 組件。
4.一種Android應(yīng)用權(quán)限泄露漏洞的測試方法，包括: 步驟一、從Android應(yīng)用程序包中的Manifest文件提取所有對外公開的Service和Broadcast Receiver 組件； 步驟二、針對Android應(yīng)用中Service和Broadcast Receiver兩種模塊間通訊組件接口，提取Action、Data和Extras信息,構(gòu)造作為模糊測試輸入的Intent對象； 步驟三、通過ICC機制，由代理應(yīng)用向應(yīng)用目標(biāo)組件通訊接口發(fā)送構(gòu)造好的Intent對象；和 步驟四、通過修改Android系統(tǒng)中的權(quán)限檢查函數(shù)，監(jiān)控權(quán)限檢查日志情況，基于日志作出是否發(fā)生權(quán)限泄露的判斷。
5.根據(jù)權(quán)利要求4所述的Android應(yīng)用權(quán)限泄露漏洞的測試方法，在步驟四后還包括: 步驟五、重復(fù)以上步驟直至遍歷完成步驟二中所有的ActioruData域、Extras域?qū)嵗?br> 6.根據(jù)權(quán)利要求4所述的Android應(yīng)用權(quán)限泄露漏洞的測試方法，其中，步驟二中構(gòu)造Intent對象進(jìn)一步包括: 從應(yīng)用程序包Manifest文件中的intent-filter標(biāo)簽中提取顯式Action,以及從應(yīng)用程序包反編譯后的smali代碼里提取以包名為前綴的隱式Action ； 從intent-filter中提取Data域信息并根據(jù)其規(guī)則定義預(yù)先生成合適的Data域數(shù)據(jù)；和 通過修改手機系統(tǒng)中獲取Extras信息的API函數(shù)監(jiān)控獲取Extras鍵和值數(shù)據(jù)類型。
7.根據(jù)權(quán)利要求4所述的Android應(yīng)用權(quán)限泄露漏洞的測試方法，其中，基于Action、Data和Extras三種數(shù)據(jù)信息來構(gòu)造Intent對象。
8.根據(jù)權(quán)利要求4所述的Android應(yīng)用權(quán)限泄露漏洞的測試方法，其中，步驟三進(jìn)一步包括: 通過向Started Service和Broadcast Receiver兩種目標(biāo)組件發(fā)送顯不Intent的方式來進(jìn)行權(quán)限泄露檢測。
9.根據(jù)權(quán)利要求4所述的Android 應(yīng)用權(quán)限泄露漏洞的測試方法，其中，步驟四修改Android系統(tǒng)中的權(quán)限檢查函數(shù)進(jìn)一步包括: 通過修改Android系統(tǒng)ActivityManagerService服務(wù)中的權(quán)限檢查函數(shù)，將Android系統(tǒng)服務(wù)對應(yīng)用程序執(zhí)行過程中通過權(quán)限檢查的權(quán)限名稱和uid號輸出到系統(tǒng)日志中。
【文檔編號】G06F21/57GK103996007SQ201410232423
【公開日】2014年8月20日 申請日期:2014年5月29日 優(yōu)先權(quán)日:2014年5月29日
【發(fā)明者】諸葛建偉, 楊坤, 王永科, 魏克, 段海新 申請人:諸葛建偉