周 敏，周安民，劉 亮，賈 鵬，譚翠江

(四川大學 電子信息學院，成都 610065)

組件拒絕服務漏洞自動挖掘技術(shù)

周 敏，周安民*，劉 亮，賈 鵬，譚翠江

(四川大學 電子信息學院，成都 610065)

針對Android應用對獲取到的數(shù)據(jù)沒有進行空數(shù)據(jù)和異常數(shù)據(jù)的安全驗證，會發(fā)生崩潰導致組件拒絕服務的問題，提出了一種組件拒絕服務漏洞自動化挖掘框架。通過逆向分析和靜態(tài)數(shù)據(jù)流分析技術(shù)獲取安卓應用的包名和組件信息，同時跟蹤應用對Intent對象的數(shù)據(jù)訪問，提取Intent對象攜帶的數(shù)據(jù)信息，并且識別公開組件啟動私有組件的路徑信息，輔助動態(tài)模糊測試挖掘漏洞。為了增大測試用例的覆蓋范圍和實現(xiàn)自動化，該框架增加了對Intent的Action、Category、Data和Extra屬性的畸變，并且采用Accessibility技術(shù)自動關閉應用崩潰彈窗，大幅提高了檢測效率。為了驗證框架的有效性和實用性，利用所提的框架設計實現(xiàn)了工具——DroidRVMS，并與Intent Fuzzer工具進行了對比。實驗結(jié)果表明，DroidRVMS能夠有效地發(fā)現(xiàn)動態(tài)廣播組件的拒絕服務漏洞和大部分類型異常導致的拒絕服務攻擊。

組件通信；拒絕服務；靜態(tài)分析；動態(tài)分析；漏洞挖掘

0 引言

移動平臺上各式各樣的應用程序呈指數(shù)式爆炸增長，其中，基于Android系統(tǒng)的應用程序更是占據(jù)了絕對優(yōu)勢。但是，由于Android應用開發(fā)門檻較低，開發(fā)者水平良莠不齊，一些應用往往會因為開發(fā)者的安全意識不強、邏輯不夠嚴謹或者沒有對應用進行異常處理而存在安全漏洞。因此，安卓應用很容易出現(xiàn)安全漏洞。

安卓應用是由功能豐富的組件構(gòu)成的。這些組件可以實現(xiàn)用戶交互界面、后臺服務、廣播通知等功能。同時，安卓系統(tǒng)提供了Intent機制來幫助這些組件實現(xiàn)應用間通信和應用內(nèi)通信。借助Intent，開發(fā)者研發(fā)的任意應用可以和軟件中的開放組件進行通信并傳遞任意類型的數(shù)據(jù)。但是如果應用在解析通過Intent獲取的數(shù)據(jù)時沒有進行異常捕獲，畸形數(shù)據(jù)就可能使應用崩潰，導致應用的部分功能不可用，更甚者會導致整個應用癱瘓。利用這種漏洞，攻擊者對應用發(fā)起拒絕服務攻擊，不僅能夠直接影響用戶體驗，而且還能導致安全防護應用的防護功能被繞過或失效，進而危害用戶的隱私和財產(chǎn)安全。如何有效地實現(xiàn)對該類漏洞的挖掘，保障Android用戶的權(quán)益是亟待解決的問題[1]。

在漏洞挖掘方面，目前通用的方法是靜態(tài)挖掘和動態(tài)挖掘。靜態(tài)挖掘方法主要是使用了代碼審計的思想，結(jié)合應用的函數(shù)調(diào)用圖、控制流圖以及敏感數(shù)據(jù)的傳播路徑對Android程序的源代碼進行靜態(tài)分析來進行漏洞挖掘，具有速度快，覆蓋率全的優(yōu)點，可用于組件劫持漏洞挖掘[2]、隱私泄露漏洞挖掘[3-5]、Intent注入漏洞挖掘[6]等研究工作，但是誤報率比較高。動態(tài)挖掘方法目前主要以fuzzing技術(shù)[7]為主，廣泛地應用于挖掘應用組件間通信機制和系統(tǒng)短信應用的漏洞，如Yang等[8]使用模糊測試技術(shù)對應用的功能泄露漏洞進行挖掘，Mulliner等[9]使用模糊測試技術(shù)對系統(tǒng)短信的漏洞進行挖掘。與靜態(tài)挖掘方法相比，動態(tài)挖掘方法提高了準確率和自動化程度，但存在樣本覆蓋率低、效率不高的缺點。

本文在研究Intent機制的基礎上提出了一種面向Android組件拒絕服務漏洞的自動化漏洞挖掘框架。該框架主要由動態(tài)分析模塊和靜態(tài)分析模塊兩部分組成。其中，靜態(tài)分析使用了逆向分析技術(shù)和數(shù)據(jù)流跟蹤技術(shù)，提取應用的組件相關信息(如公開組件信息、動態(tài)注冊的廣播等)，以及公開組件啟動私有組件的路徑信息來輔助模糊測試。而動態(tài)分析則基于靜態(tài)分析獲取的結(jié)果，使用模糊測試技術(shù)，對應用進行空Intent測試、類型錯誤Intent測試、畸變Intent測試和異常Intent測試，進一步挖掘拒絕服務漏洞。此外，本文在模糊測試過程中采用Accessibility技術(shù)將應用崩潰彈窗進行關閉，實現(xiàn)了完全自動化。

1 背景知識與相關工作

1.1 公開組件

Android應用程序通常由一個或多個基本組件共同完成其功能。而Android應用程序的組件主要有活動(Activity)、服務(Services)、廣播(Broadcast Receiver)和內(nèi)容提供者(Content Provider)。其中，前三者可以通過Intent對象啟動。

本文將應用組件分為公開組件和私有組件兩類：公開組件指應用對外暴露，能被其他應用通過Intent啟動的組件；而只能被應用內(nèi)部其他組件訪問的組件稱為私有組件[1]。

應用程序組件在AndroidManifest.xml文件中被聲明為公開組件有兩種方式：第一種是顯式聲明，即直接將組件的Android:exported屬性設為true[1]；第二種是隱式聲明，即為組件添加一個或者多個Intent-filter過濾器的方式[1]。

1.2 啟動私有組件

當私有組件被公開組件啟動時，也存在發(fā)生崩潰的情況。如下所示，應用中存在一個私有組件PrivateActivity和一個公開組件MainActivity。MainActivity能夠根據(jù)對外傳入的Intent中的內(nèi)容啟動私有組件PrivateActivity，且啟動私有組件的Intent的內(nèi)容來自于啟動公開組件的Intent的內(nèi)容。但是，私有組件PrivateActivity沒有對從Intent中獲取的內(nèi)容進行異常處理，故攻擊者精心構(gòu)造的Intent內(nèi)容可以通過公開組件MainActivity讓私有組件PrivateActivity崩潰，從而發(fā)生拒絕服務攻擊。

//私有組件PrivateActivity

public class PrivateActivity extends Activity{

private static final String SAMPLE_STRING_TEST=

"sample_string_test";

@Override

protected void onCreate(Bundle savedInstanceState){

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

String value=getIntent().getStringExtra

(SAMPLE_STRING_TEST);

String subValue=value.substring(0);

Toast.makeText(getAoolicationContext(),

subValue,Toast.LENGTH_SHORT).show();

}

}

//公開組件MainActivity

public class MainActivity extends Activity{

@Override

protected void onCreate(Bundle savedInstanceState){

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

Intent intent=this.getIntent();

if(intent.getBooleanExtra("allowed",false)){

ComponentName componentName=new ComponentName

(this, "PrivateActivity");

intent.setComponent(componentName);

this.startActivity(this.getIntent);

}

}

}

//攻擊命令

adb shell am start -n com.privatecomponent/.

MainActivity --ez "allowed" true

1.3 本地拒絕服務漏洞介紹

本文將產(chǎn)生本地拒絕服務的原因分為5種：空指針異常導致的漏洞、類型轉(zhuǎn)換異常導致的漏洞、數(shù)組訪問越界異常導致的漏洞、類未定義異常導致的漏洞以及其他異常導致的漏洞[10]。

1)當應用程序沒有對getAction()、getStringExtra()等函數(shù)獲取到的數(shù)據(jù)進行空指針判斷，從而產(chǎn)生空指針異常而導致應用崩潰，這稱為空指針異常拒絕服務漏洞(NullPointerException)[10]以getAction()函數(shù)為例，產(chǎn)生漏洞的偽代碼如下所示：

//攻擊者代碼

intent.putExtra("serializable_key", BigInteger.valueOf(1));

startActivity(intent);

//啟動受害者組件

//受害者代碼片段

Intent i=getIntent();

if(i.getAction().equals("android.intent.action.MAIN "))

{

Toast.makeText(this, "Test！", Toast.LENGTH_LONG).show();

}

2)當應用程序沒有對getSerializableExtra()等函數(shù)獲取到的數(shù)據(jù)進行類型判斷就直接進行強制類型轉(zhuǎn)換，從而產(chǎn)生類型轉(zhuǎn)換異常而導致應用崩潰，這稱為類型轉(zhuǎn)換異常拒絕服務漏洞(ClassCastException)[10]。以getSerializableExtra()函數(shù)為例，產(chǎn)生漏洞的偽代碼如下所示：

//攻擊者代碼片段

intent.putExtra("serializable_key", BigInteger.valueOf(1));

startActivity(i);

//啟動受害者組件

//受害者代碼片段

Intent i=getIntent();

String test=(String)i.getSerializableExtra("serializable_key")

3)當應用程序沒有對getIntegerArrayListExtra()等函數(shù)獲取到的數(shù)據(jù)數(shù)組元素大小進行判斷，從而產(chǎn)生數(shù)組訪問越界而導致應用崩潰，這稱為數(shù)組訪問越界異常拒絕服務漏洞(IndexOutOfBoundsExceptio)[10]。以getIntegerArrayListExtra()函數(shù)為例，產(chǎn)生漏洞的偽代碼如下所示:

//攻擊者代碼片段

ArrayList cve_id=new ArrayList();

intent.putExtra("cve_id", cve_id);

startActivity(intent);

//啟動受害者組件

//受害者代碼

Intent intent=getIntent();

ArrayList intArray=

intent.getIntegerArrayListExtra("cve_id");

if (intArray !=null) {

for (int i=0; i

intArray.get(i);

}

}

4)當應用程序無法找到從getSerializableExtra()、getParcelable()等函數(shù)中獲取到的序列化類對象的類定義，從而發(fā)生類未定義的異常而導致應用崩潰，這稱為類未定義異常拒絕服務漏洞(ClassNotFoundException)[10]。以getSerializableExtra()函數(shù)為例，產(chǎn)生漏洞的偽代碼如下所示：

//攻擊者代碼, SelfSerializableData 這個類未定義

i.putExtra("serializable_key", new SelfSerializableData());

startActivity(i);

//啟動受害者組件

//受害者代碼

Intent intent=getIntent();

intent.getSerializableExtra("serializable_key");

5)其他異常導致的拒絕服務漏洞：如IllegalArgumentException、UnsupportedOperationException異常等導致的拒絕服務。

1.4 相關研究及挑戰(zhàn)

目前，針對應用組件拒絕服務漏洞，主流的漏洞挖掘工具是iSEC Partners公司設計的Intent Fuzzer工具[11]。該工具運行在Android設備上，其工作原理是通過PackageManager獲取系統(tǒng)中所有安裝應用的信息，以及各應用中Activity、Service和Broadcast Receiver這3類暴露組件的信息，然后通過調(diào)用startActivity(Intent)、startService(Intent)、sendBroadcast(Intent)等啟動函數(shù)發(fā)送Intent消息到Activity、Service和Broadcast Receiver組件中進行測試。但該工具不支持對Activity類組件進行大量的測試。此外，Intent Fuzzer工具還存在不能完全實現(xiàn)自動化測試、沒有日志輸出和僅發(fā)送空Intent消息等問題。

Maji等[12]對Intent Fuzzer工具進行了改進，設計了JarJarBinks工具。該工具通過startActivityForResult(Intent，int)函數(shù)來啟動應用程序的Activitiy，進而可以通過調(diào)用finishActivity()函數(shù)來關閉Actvity，回收系統(tǒng)資源，實現(xiàn)了對大量的Activity進行測試。與Intent Fuzzer相比，JarJarBinks工具不僅實現(xiàn)了對Activity類組件的測試，而且Intent測試用例增加了隨機的Extras，實現(xiàn)了更廣泛的測試。但JarJarBinks工具不能準確獲得應用中Extras的type和name信息，因而仍然不能對組件進行深入有效的Fuzzing測試。

實際上，現(xiàn)有的工具都不能自動關閉應用崩潰時的系統(tǒng)彈窗，不能完全實現(xiàn)自動化測試； 而且現(xiàn)有工具都是只對AndroidManifest.xml文件中注冊的公開組件進行測試，不能對應用中動態(tài)注冊的Broadcast Receiver組件進行測試，也不能對通用型的Android應用組件拒絕服務進行測試。

因此，為了實現(xiàn)基于Fuzzing的Android組件拒絕服務漏洞的自動化挖掘，其挑戰(zhàn)在于如何在擴大測試用例覆蓋范圍的基礎上，自動關閉應用崩潰時彈出的窗口，實現(xiàn)批量應用的漏洞挖掘，提高漏洞挖掘效率。

1)如何擴大測試用例的覆蓋范圍？不僅要考慮到應用中動態(tài)注冊的Broadcast Receiver組件的測試和私有組件的測試，還要考慮對Intent更多屬性的隨機測試，以及畸變策略的多樣化。

2)如何自動關閉應用崩潰窗口，實現(xiàn)完全自動化？使用Android Accessibility機制實現(xiàn)對程序崩潰時系統(tǒng)彈窗的實時監(jiān)視和關閉，讓模糊測試在每次被彈窗阻塞后得以繼續(xù)執(zhí)行，實現(xiàn)完全自動化的應用組件拒絕服務漏洞挖掘。

2 基于逆向工程和數(shù)據(jù)流的靜態(tài)分析

靜態(tài)分析主要進行逆向分析和數(shù)據(jù)流分析的工作，挖掘私有組件導致的拒絕服務漏洞。

2.1 逆向分析

首先，需要檢測APK文件是否進行了加固處理，由于經(jīng)過加固處理的APK文件逆向分析得不到應用程序真正的代碼，所以本文不對其進行考慮。

對于未經(jīng)過加固處理的APK文件，該工作主要是將APK文件進行解壓縮，提取APK中的Dex、AndroidManifest.xml等文件。然后使用AXMLPrinter2.jar工具將二進制的AndroidManifest.xml文件解析成文本形式的xml文件，提取應用的組件和包名等信息。同時使用dex2jar工具將DEX文件轉(zhuǎn)換成jar文件，再使用cfr工具將jar文件反編譯成Java源碼文件，得到代碼中動態(tài)注冊的Broadcast Receiver信息，組件間的調(diào)用關系以及各組件接收Intent消息的Extra數(shù)據(jù)名稱和類型。將獲取的這些信息保存于info.txt文件中，后面用于動態(tài)分析時確定待測組件以及根據(jù)變異策略生成測試用例。另外，還要使用baksmali.jar工具將DEX文件反編譯成Smali文件，用于2.2節(jié)的數(shù)據(jù)流分析工作。

2.2 數(shù)據(jù)流分析

數(shù)據(jù)流分析工作主要是構(gòu)建控制流圖來表示公開組件對私有組件的啟動情況，從而得到存在拒絕服務的私有組件名稱和發(fā)生崩潰的啟動路徑。

控制流圖的構(gòu)建是基于DEX文件反編譯后的Smali代碼上的，避免了用現(xiàn)有工具生成控制流圖時引入大量無關系統(tǒng)庫函數(shù)的問題，提高了分析效率。構(gòu)圖時，以每個公開組件的入口函數(shù)作為入口點，分別構(gòu)造組件內(nèi)控制流圖和組件間控制流圖，然后將各部分控制流圖連接成一個完整的控制流圖[13]。

生成組件內(nèi)控制流圖時，根據(jù)if-else, try-catch這類跳轉(zhuǎn)指令對Smali代碼進行分塊，每一個代碼塊作為控制流圖的一個節(jié)點，代碼塊之間的跳轉(zhuǎn)作為控制流圖的有向邊，指向程序的執(zhí)行方向，其中，Intent的接收者對接收數(shù)據(jù)時可能發(fā)生的異常進行了正確處理的，其有向邊用實線表示，若沒有，就用虛線表示。為了保證完整，需要同時對與組件生命周期內(nèi)各種狀態(tài)相關的系統(tǒng)回調(diào)函數(shù)進行控制流圖的構(gòu)建。然后再根據(jù)回調(diào)函數(shù)的執(zhí)行順序，在回調(diào)函數(shù)之間添加對應的有向邊(實線還是虛線)。

生成組件間控制流圖時，根據(jù)應用組件間的Intent調(diào)用關系，包括顯式Intent調(diào)用和隱式Intent調(diào)用，將組件內(nèi)控制流圖連接起來，成為一個完整的控制流圖。

由于控制流圖是一個連通圖，本文采用深度優(yōu)先搜索(Depth First Search, DFS)[14]算法對得到的完整控制流圖進行路徑搜索，獲取控制流圖中全部的未經(jīng)try-catch指令異常處理的調(diào)用路徑。以圖1為例，說明使用深度優(yōu)先搜索算法搜索符合條件的路徑的過程，其中，v0節(jié)點表示公開組件入口函數(shù)所在節(jié)點，v4節(jié)點表示私有組件入口函數(shù)所在的節(jié)點。

圖1 深度優(yōu)先搜索算法搜索路徑的過程Fig. 1 Algorithm of searching path by DFS

1)首先建立一個存儲節(jié)點的?？臻g，將起始節(jié)點v0入棧，并將其標記為入棧狀態(tài)。

2)從v0節(jié)點出發(fā)，找到下一個相鄰的非入棧節(jié)點v1、v2或v3，假設先訪問v1節(jié)點，將v1節(jié)點入棧，并標記為入棧狀態(tài)。然后判斷v0和v1之間的有向邊是否為虛線: 若是，繼續(xù)向下來到v1節(jié)點，重復步驟2)；若不是，從棧頂彈出v1節(jié)點，并將v1節(jié)點標記為非入棧狀態(tài)，繼續(xù)對v0的下一個除v1節(jié)點外相鄰的非入棧節(jié)點重復步驟2)。

3)由于這里v0和v1之間是實線，v0和v2之間是虛線，所以此時棧頂是v2節(jié)點。

4)從v2節(jié)點出發(fā)，找到v2節(jié)點的下一個相鄰的非入棧節(jié)點v4，將v4節(jié)點入棧，并標記為入棧狀態(tài)。然后，判斷v2和v4之間的有向邊是否為虛線: 若是，繼續(xù)向下來到v4，由于v4是終止節(jié)點，因此得到一條路徑；若不是，從棧頂彈出v2節(jié)點，并將v2節(jié)點標記為非入棧狀態(tài)，繼續(xù)對v0下一個除v1,v2節(jié)點外相鄰的非入棧節(jié)點重復步驟2)。

5) 由于這里v2和v4之間是實線，v0和v3之間是虛線，所以此時棧頂是v3節(jié)點。

6)從v3節(jié)點出發(fā)，重復步驟4)，由于v3與v4之間是虛線且v4是終止節(jié)點，所以找到一條路徑v0 →v3 →v4。

7)此時棧頂是v4節(jié)點。從棧頂彈出v4節(jié)點，并將v4節(jié)點標記為非入棧狀態(tài)。

8)此時棧頂是v2節(jié)點，由于v2節(jié)點沒有除剛出棧的v4節(jié)點外的相鄰非入棧節(jié)點，因此將v2節(jié)點出棧，并標記為非入棧狀態(tài)。

9)此時棧頂是v0節(jié)點，由于與v0節(jié)點相鄰的節(jié)點都已被訪問過，因此彈出v0節(jié)點，并標記為非入棧狀態(tài)。此時?？臻g為空，結(jié)束整個路徑搜索過程。

利用深度優(yōu)先算法獲取到所有未經(jīng)異常處理的公開組件啟動私有組件的路徑后。將這些路徑以及對應的公開組件和私有組件名稱保存于VulPath.txt文件中，后續(xù)結(jié)合相關的Extra信息用來生成特殊的造成系統(tǒng)服務級聯(lián)崩潰的測試用例，用來測試私有組件。

3 基于Fuzzing和Accessibility的動態(tài)分析

3.1 模糊測試

3.1.1 測試用例生成策略

為了增大測試用例的覆蓋范圍，本文針對Intent的Component、Action、Category、Data、Extra這5種屬性構(gòu)造測試用例。其中，采用的Intent構(gòu)建策略有六類。

第一類測試用例是不攜帶任何額外數(shù)據(jù)的Intent消息，即直接使用AndroidManifest.xml文件和DEX文件分析得到的組件包名和組件名設置Intent的Component屬性，而其他屬性為空[15]。

第二類測試用例只設置了Action、Category、Data三種屬性中的任意一種，其余兩種屬性為空或隨機值。其中Action[16]和Category[16]屬性的值均取自Android提供的標準值，Data屬性的值取自構(gòu)建的幾類典型的Data URL。構(gòu)建的幾類經(jīng)典的Data URL如表1所示[15]。

表1 幾類典型Data URLTab. 1 Typical Data URL

第三類測試用例設置了Action、Category、Data三種屬性中的任意兩種，另一種屬性為空或隨機值。同樣，Action和Category屬性的值均取自Android提供的標準值，Data屬性的值取自構(gòu)建的幾類典型的Data值[15]。

第四類測試用例則同時設置了Action、Category、Data三種屬性。其中Action和Category屬性的值取自Android提供的標準值，Data屬性的值取自構(gòu)建的幾類典型的Data值[15]。

第五類測試用例是在前四類測試用例的基礎上增加對Extras屬性的設置。此時，測試用例需指定Extras屬性中的數(shù)據(jù)名稱[15]，其值已在DEX文件分析時獲取，數(shù)據(jù)值則是隨機的。為了提高效率，針對Extras屬性常攜帶的幾類數(shù)據(jù)類型，本文對不同的數(shù)據(jù)類型分別設計了典型的數(shù)值進行數(shù)據(jù)填充，如表2所示[17]。

表2 Extras屬性各數(shù)據(jù)類型的數(shù)值填充模板Tab. 2 Padding template of extras attribute for each data type

第六類測試用例是針對VulPath.txt文件中信息和Extras屬性構(gòu)建的，用來測試通過級聯(lián)反應引起的私有組件的崩潰。其中，Extra屬性名稱已在DEX文件分析時獲取到，數(shù)據(jù)值是隨機的。

通過上述的測試用例生成策略，可以生成與目標組件所接收的Intent的屬性完全匹配、半匹配以及完全不匹配的Intent測試用例，最大限度地提高了測試用例的覆蓋范圍。

3.1.2 測試過程

模糊測試的流程為：

1)基于測試用例生成策略構(gòu)造大量的多類型的Intent。

2)將待測試的應用安裝到Android模擬器上。

3)借助ADB工具將測試用例發(fā)送給目標應用的每一個公開組件和動態(tài)注冊的廣播組件。

4)使用Logcat收集測試期間的各類日志信息。

5)通過對日志信息中“Fatal Exception：main”字符串的監(jiān)控來獲取應用程序崩潰時的相關的日志信息，以及保存造成崩潰的測試用例。

這里僅將測試用例以顯式Intent的方式發(fā)送給公開組件和動態(tài)廣播組件。但是表1構(gòu)建的幾類經(jīng)典的Data URL數(shù)據(jù)中content://***數(shù)據(jù)值可以測試Content Provider組件，測試用例生成策略六可以用來測試私有組件。

3.2 應用崩潰監(jiān)控

在實際測試過程中，當應用程序發(fā)生崩潰時，Android系統(tǒng)會進行系統(tǒng)級別的彈窗以提示用戶應用程序已停止運行，需要手動關閉，這在很大程度上影響了自動化的實現(xiàn)。

本文利用Android Accessibility機制能夠?qū)崟r獲取當前Android設備窗口狀態(tài)改變信息和窗口元素信息的特點，通過監(jiān)聽窗口狀態(tài)的改變來判斷系統(tǒng)彈窗，獲取窗口的元素信息，采用模擬點擊技術(shù)關閉彈窗，成功解決了該問題，實現(xiàn)了完全自動化。其具體實現(xiàn)步驟為：

步驟1 創(chuàng)建一個MyAccessibilityService類繼承Accessibility機制提供的AccessibilityService接口類。

步驟2 注冊崩潰窗口監(jiān)聽事件。根據(jù)應用崩潰時，窗口上通常會出現(xiàn)“很抱歉，xxx已停止運行?！钡奶崾咎卣鲗帽罎棿斑M行監(jiān)聽。

步驟3 實現(xiàn)關閉窗口事件。如果出現(xiàn)了應用崩潰彈窗，則通過findAccessibilityNodeInfoByText函數(shù)找到窗口中的“確定”按鈕，執(zhí)行點擊操作將彈窗進行關閉。自動化關閉窗口事件的偽代碼如下：

List

sorry_nodes=event.getSource().

findAccessibilityNodeInfosByText("很抱歉");

if (sorry_nodes!=null && !sorry_nodes.isEmpty()){

List

ok_nodes=event.getSource().

findAccessibilityNodeInfosByText("確定");

if (ok_nodes!=null && !ok_nodes.isEmpty()){

AccessibilityNodeInfo node;

for(int i=0; i

node=ok_nodes.get(i);

if(node.getClassName().equals("android.widget.Button") &&

node.isEnabled()){

node.performAction

(AccessibilityNodeInfo.ACTION_CLICK);

}

}

}

}

4 實驗與分析

為了驗證框架的有效性，本文基于該框架設計實現(xiàn)了工具——DroidRVMS，使用該工具對從Android應用市場下載的300個應用程序進行了組件拒絕服務漏洞挖掘?qū)嶒?，同時，使用開源的組件拒絕服務漏洞挖掘工具Intent Fuzzer[11]對相同的測試樣本進行漏洞挖掘，并將測試結(jié)果與DroidRVMS的測試結(jié)果進行對比，表明DroidRVMS具有有效性和實用性。

4.1 實驗數(shù)據(jù)和實驗環(huán)境

實驗數(shù)據(jù)來源于5個主流的第三方應用市場，共300個，涵蓋了系統(tǒng)、新聞、影音、辦公、交通、社交、購物、游戲共8種類型的應用，應用的分布如表3所示。

表3 實驗數(shù)據(jù)集Tab. 3 Data set of experiment

實驗環(huán)境為安裝有Android Nexus5模擬器的64位 Windows 7系統(tǒng)計算機，Intel Xeon E3-1231 v3 3.40 GHz CPU, 8 GB內(nèi)存。

4.2 實驗結(jié)果分析

使用DroidRVMS對300個測試樣本進行測試后共發(fā)現(xiàn) 112個應用存在組件拒絕服務漏洞，其中導致應用拒絕服務的組件共674個。測試結(jié)果如表4所示。

表4 測試結(jié)果Tab. 4 Result of DroidRVMS analysis

用Intent Fuzzer工具對相同的測試樣本進行Fuzzing測試后，共發(fā)現(xiàn)78個應用中存在組件拒絕服務漏洞，419個導致應用拒絕服務的組件。圖2是兩個工具的測試結(jié)果對比。

圖2 兩個工具的整體測試結(jié)果對比Fig. 2 Overal test results of comparative tools

從總體數(shù)量上看，與Intent Fuzzer工具相比，在相同測試樣本的情況下，DroidRVMS能夠挖掘出更多的組件拒絕服務漏洞。

為進一步對實驗結(jié)果進行分析，本文對兩個工具發(fā)現(xiàn)的不同類型組件引起的組件拒絕服務漏洞數(shù)量和檢測出的組件拒絕服務漏洞的異常分布情況進行統(tǒng)計，統(tǒng)計結(jié)果分別如圖3和圖4所示。

圖3 各類組件引起的組件拒絕服務漏洞數(shù)量Fig. 3 Number of vulnerabilities caused by various components

圖4 造成組件拒絕服務漏洞的異常分布情況Fig. 4 Distribution of various exceptions causing vulnerabilities

從圖3可以看出，與Intent Fuzzer工具相比， DroidRVMS能夠發(fā)現(xiàn)除了Activity組件、Service組件和靜態(tài)Broadcast Receiver組件的拒絕服務漏洞外，還能發(fā)現(xiàn)動態(tài)Broadcast Receiver組件的拒絕服務漏洞。此外，DroidRVMS發(fā)現(xiàn)其他三類組件的拒絕服務漏洞數(shù)量都比Intent Fuzzer工具多，說明DroidRVMS能夠挖掘出更深層次的組件拒絕服務漏洞。

從圖4可以看出，與Intent Fuzzer工具相比，DroidRVMS能夠發(fā)現(xiàn)除空指針異常外的更多類型異常導致的組件拒絕服務漏洞，說明DroidRVMS的覆蓋范圍更廣。

由上述實驗結(jié)果可知，本文設計實現(xiàn)的DroidRVMS能夠有效地挖掘出應用中存在的組件拒絕服務漏洞，且比Intent Fuzzer挖掘的層次更深，覆蓋范圍更廣。

5 結(jié)語

針對Android應用組件中影響范圍廣、危害嚴重的組件拒絕服務漏洞，本文提出了一種結(jié)合靜態(tài)分析技術(shù)和動態(tài)分析技術(shù)的自動化漏洞挖掘框架。該框架通過逆向工程技術(shù)和靜態(tài)數(shù)據(jù)流分析技術(shù)得到組件信息、Intent攜帶的數(shù)據(jù)信息和公開組件啟動私有組件的路徑信息，然后基于此基礎上，采用Fuzzing技術(shù)和Accessibility技術(shù)，使用大量覆蓋范圍廣泛的畸變樣本對漏洞進行測試，實現(xiàn)自動挖掘組件拒絕服務漏洞的目標。最后，設計實驗與著名組件漏洞挖掘工具Intent Fuzzer進行了比較，實驗結(jié)果表明，DroidRVMS比現(xiàn)有的組件漏洞挖掘工具具有自動化、覆蓋范圍廣、挖掘?qū)哟紊睢蚀_率高的優(yōu)勢，具有一定的有效性和實用性。

但是本文提出的漏洞挖掘方法仍然存在一些問題：

1)在對應用進行Fuzzing測試時，本文根據(jù)靜態(tài)分析結(jié)果構(gòu)造的測試用例存在大量無效的情況，影響了測試的效率。故后面需要對應用進行更精確的靜態(tài)分析來指導測試用例的生成，提供測試效率。

2)本文只對未加固應用進行了組件拒絕服務漏洞的自動化挖掘，沒有考慮加固應用，下一步需要研究對加固應用的漏洞挖掘。

References)

[1] 肖衛(wèi), 張源, 楊珉. 安卓應用軟件中Intent數(shù)據(jù)驗證漏洞的檢測方法[J]. 小型微型計算機系統(tǒng), 2017, 38(4):813-819.(XIAO W, ZHANG Y, YANG M. Find Intent data validation vulnerability in Android application automatically and efficiently[J]. Journal of Chinese Computer Systems, 2017, 38(4): 813-819.)

[2] LU L, LI Z, WU Z, et al. CHEX: statically vetting Android apps for component hijacking vulnerabilities[C]// Proceedings of the 2012ACM Conference on Computer and Communications Security. New York: ACM, 2012:229-240.

[3] GIBLER C, CRUSSELL J, ERICKSON J, et al. AndroidLeaks: automatically detecting potential privacy leaks in Android applications on a large scale[C]// Proceedings of the 5th International Conference on Trust and Trustworthy Computing. Berlin: Springer-Verlag, 2012:291-307.

[4] VALL, E-RAI R, CO P, et al. Soot: a Java bytecode optimization framework[C]// Proceedings of CASCON 1st Decade High Impact Papers. Riverton, NJ: IBM, 2010:214-224.

[5] ARZT S, RASTHOFER S, FRITZ C, et al. FlowDroid: precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for Android apps [J]. ACM SIGPLAN Notices, 2014, 49(6):259-269.

[6] 王允超, 魏強, 武澤慧. 基于靜態(tài)污點分析的Android應用Intent注入漏洞檢測方法[J]. 計算機科學, 2016, 43(9):192-196.(WANG Y C, WEI Q, WU Z H. Approach of Android applications Intent injection vulnerability detection based on static taint analysis [J]. Computer Science, 2016, 43(9):192-196.)

[7] 李紅輝, 齊佳, 劉峰,等. 模糊測試技術(shù)研究[J]. 中國科學: 信息科學, 2014, 44(10):1305-1322.(LI H H, QI J, LIU F, et al. The research progress of fuzz testing technology[J]. Science China: Information Sciences, 2014, 44(10):1305-1322.)

[8] YANG K, ZHUGE J, WANG Y, et al. Intent Fuzzer: detecting capability leaks of Android applications[C]// Proceedings of the 9th ACM Symposium on Information, Computer and Communications Security. New York: ACM, 2014:531-536.

[9] MULLINER C, MILLER C. Fuzzing the phone in your phone[EB/OL].[2015- 01- 08].http://mulliner.org/security/sms/feed/smsfuzz_26c3.pdf.

[10] The analysis report on generic denial of service vulnerability in Android APP[EB/OL].[2015- 01- 08].http://www.secpulse.com/archives/3859.html.

[11] iSEC Partners. Intent Fuzzer[EB/OL]. [2016- 12- 23].https://www.isecpartners.com/tools/mobile-security/intentfuzzer.aspx.

[12] MAJI A K, ARSHAD F A, BAGCHI S, et al. An empirical study of the robustness of Inter-component communication in Android[C]// Proceedings of the 2012 IEEE/IFIP International Conference on Dependable Systems and Networks. Piscataway, NJ: IEEE, 2012:1-12.

[13] 湯楊, 曾凡平, 王健康,等. 基于靜態(tài)分析的Android GUI遍歷方法[J]. 計算機應用, 2016, 36(10):2811-2815. (TANG Y, ZENG F P, WANG J K, et al. Android GUI traversal method based on static analysis [J]. Journal of Computer Applications, 2016, 36(10): 2811-2815.)

[14] 王敏, 陳少敏, 陳亞光. 基本路徑測試用例設計算法[J]. 計算機應用, 2013, 33(11):3262-3266.(WANG M, CHEN S M, CHEN Y G. Test case design algorithm for basic path test [J]. Journal of Computer Applications, 2013, 33(11): 3262-3266.)

[15] 張密, 楊力, 張俊偉. FuzzerAPP:Android應用程序組件通信魯棒性測試[J]. 計算機研究與發(fā)展, 2017, 54(2):338-347.(ZHANG M, YANG L, ZHANG J W. FuzzerAPP: the robustness test of application component communication in Android[J]. Journal of Computer Research and Development, 2017, 54(2):338-347.)

[16] Intent class overview [EB/OL]. [2016- 11- 09].https://developer.android.com/reference/android/content/Intent.html.

[17] 李曉洲. Android應用程序組件漏洞測試方法研究[D]. 太原: 太原理工大學, 2015:38-47. (LI X Z. Study of Android application component vulnerability testing method [D]. Taiyuan: Taiyuan University of Technology, 2015:38-47.)

ZHOUMin, born in 1994, M. S. candidate. Her research interests include mobile security, malicious code analysis, vulnerability mining.

ZHOUAnmin, born in 1963, research fellow. His research interests include security defense and management, mobile Internet security.

LIULiang, born in 1982, M. S., lecturer. His research interests include vulnerability mining, malicious code analysis.

JIAPeng, born in 1988, Ph. D. candidate. His research interests include virus propagation dynamics, binary security, malicious code analysis.

TANCuijiang, born in 1991, M. S. candidate. His research interests include mobile security, malicious code analysis, vulnerability mining.

MiningdenialofservicevulnerabilityinAndroidapplicationsautomatically

ZHOU Min, ZHOU Anmin*, LIU Liang, JIA Peng, TAN Cuijiang

(CollegeofElectronicsandInformation,SichuanUniversity,ChengduSichuan610065,China)

Concerning the fact that when the receiver of an Intent does not validate empty data and abnormal data, the process will crash and cause denial of service, an automated Android component vulnerability mining framework based on static analysis techniques and fuzzing test techniques was proposed. In this framework, reverse analysis techniques and static data flow analysis techniques were used to extract package name, component, Intent with the data of a traffic and data flow paths from exported component to private component to assist fuzzing test. In addition, more mutation strategy on the attributes of Intent (such as Action, Category, Data and Extra) were added while generating Intent tests and the Accessibility technology was adopted to close the crash windows in order to realize automation. Finally, a tool named DroidRVMS was implemented, and a comparative experiment with Intent Fuzzer was designed to verify the validity of the framework. The experimental results show that DroidRVMS can find denial of service vulnerability resulting from dynamic broadcast receiver and most types of exceptions.

component communication; denial of service; static analysis; dynamic analysis; vulnerability mining

2017- 05- 12;

2017- 06- 08。

周敏(1994—)，女，陜西漢中人，碩士研究生，主要研究方向：移動安全、惡意代碼分析、漏洞挖掘； 周安民(1963—)，男，四川成都人，研究員，主要研究方向：安全防御管理、移動互聯(lián)網(wǎng)安全、云計算安全； 劉亮(1982—), 男，四川成都人，講師，碩士，主要研究方向：漏洞挖掘、惡意代碼分析； 賈鵬(1988—)，男，四川成都人，博士研究生，主要研究方向：病毒傳播動力學、二進制安全、惡意代碼分析； 譚翠江(1991—), 男，四川成都人，碩士研究生，主要研究方向：移動安全、惡意代碼分析、漏洞挖掘。

1001- 9081(2017)11- 3288- 06

10.11772/j.issn.1001- 9081.2017.11.3288

(*通信作者電子郵箱zhouminscu@163.com)

TP311

A