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

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

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

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

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

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

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

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

0 引言

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

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

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

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

1 背景知識(shí)與相關(guān)工作

1.1 公開組件

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

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

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

1.2 啟動(dòng)私有組件

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

//私有組件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 本地拒絕服務(wù)漏洞介紹

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

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

//攻擊者代碼

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

startActivity(intent);

//啟動(dòng)受害者組件

//受害者代碼片段

Intent i=getIntent();

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

{

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

}

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

//攻擊者代碼片段

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

startActivity(i);

//啟動(dòng)受害者組件

//受害者代碼片段

Intent i=getIntent();

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

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

//攻擊者代碼片段

ArrayList cve_id=new ArrayList();

intent.putExtra("cve_id", cve_id);

startActivity(intent);

//啟動(dòng)受害者組件

//受害者代碼

Intent intent=getIntent();

ArrayList intArray=

intent.getIntegerArrayListExtra("cve_id");

if (intArray !=null) {

for (int i=0; i

intArray.get(i);

}

}

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

//攻擊者代碼, SelfSerializableData 這個(gè)類未定義

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

startActivity(i);

//啟動(dòng)受害者組件

//受害者代碼

Intent intent=getIntent();

intent.getSerializableExtra("serializable_key");

5)其他異常導(dǎo)致的拒絕服務(wù)漏洞：如IllegalArgumentException、UnsupportedOperationException異常等導(dǎo)致的拒絕服務(wù)。

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

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

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

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

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

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

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

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

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

2.1 逆向分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7)此時(shí)棧頂是v4節(jié)點(diǎn)。從棧頂彈出v4節(jié)點(diǎn)，并將v4節(jié)點(diǎn)標(biāo)記為非入棧狀態(tài)。

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

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

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

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

3.1 模糊測試

3.1.1 測試用例生成策略

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

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

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

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

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

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

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

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

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

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

3.1.2 測試過程

模糊測試的流程為：

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

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

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

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

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

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

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

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

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

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

步驟2 注冊(cè)崩潰窗口監(jiān)聽事件。根據(jù)應(yīng)用崩潰時(shí)，窗口上通常會(huì)出現(xiàn)“很抱歉，xxx已停止運(yùn)行?！钡奶崾咎卣鲗?duì)應(yīng)用崩潰彈窗進(jìn)行監(jiān)聽。

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

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 實(shí)驗(yàn)與分析

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

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

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

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

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

4.2 實(shí)驗(yàn)結(jié)果分析

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

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

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

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

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

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

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

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

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

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

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

5 結(jié)語

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

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

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

2)本文只對(duì)未加固應(yīng)用進(jìn)行了組件拒絕服務(wù)漏洞的自動(dòng)化挖掘，沒有考慮加固應(yīng)用，下一步需要研究對(duì)加固應(yīng)用的漏洞挖掘。

References)

[1] 肖衛(wèi), 張?jiān)? 楊珉. 安卓應(yīng)用軟件中Intent數(shù)據(jù)驗(yàn)證漏洞的檢測方法[J]. 小型微型計(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] 王允超, 魏強(qiáng), 武澤慧. 基于靜態(tài)污點(diǎn)分析的Android應(yīng)用Intent注入漏洞檢測方法[J]. 計(jì)算機(jī)科學(xué), 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]. 中國科學(xué): 信息科學(xué), 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]. 計(jì)算機(jī)應(yīng)用, 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] 王敏, 陳少敏, 陳亞光. 基本路徑測試用例設(shè)計(jì)算法[J]. 計(jì)算機(jī)應(yīng)用, 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應(yīng)用程序組件通信魯棒性測試[J]. 計(jì)算機(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應(yīng)用程序組件漏洞測試方法研究[D]. 太原: 太原理工大學(xué), 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—)，女，陜西漢中人，碩士研究生，主要研究方向：移動(dòng)安全、惡意代碼分析、漏洞挖掘； 周安民(1963—)，男，四川成都人，研究員，主要研究方向：安全防御管理、移動(dòng)互聯(lián)網(wǎng)安全、云計(jì)算安全； 劉亮(1982—), 男，四川成都人，講師，碩士，主要研究方向：漏洞挖掘、惡意代碼分析； 賈鵬(1988—)，男，四川成都人，博士研究生，主要研究方向：病毒傳播動(dòng)力學(xué)、二進(jìn)制安全、惡意代碼分析； 譚翠江(1991—), 男，四川成都人，碩士研究生，主要研究方向：移動(dòng)安全、惡意代碼分析、漏洞挖掘。

1001- 9081(2017)11- 3288- 06

10.11772/j.issn.1001- 9081.2017.11.3288

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

TP311

A