移動(dòng)應(yīng)用安全解析學(xué): 成果與挑戰(zhàn)

楊 威,肖旭生, 李鄧鋒, 李豁然, 劉譞哲, 王浩宇, 郭 耀, 謝 濤

?

移動(dòng)應(yīng)用安全解析學(xué): 成果與挑戰(zhàn)

楊 威1,肖旭生2, 李鄧鋒1, 李豁然3, 劉譞哲3, 王浩宇3, 郭 耀3, 謝 濤1

1伊利諾伊大學(xué)香檳分校 計(jì)算機(jī)系 厄巴納 美國 618012NEC美國研究所 普林斯頓 美國 085403北京大學(xué) 信息科學(xué)技術(shù)學(xué)院 北京 中國 100871

隨著移動(dòng)應(yīng)用(App)的廣泛使用, 移動(dòng)應(yīng)用的安全事件也頻頻發(fā)生。從數(shù)以億計(jì)的移動(dòng)應(yīng)用中準(zhǔn)確地識(shí)別出潛在的安全隱患成為了信息安全領(lǐng)域重要的難題之一。移動(dòng)應(yīng)用數(shù)量級(jí)增長的同時(shí), 也產(chǎn)生了海量的應(yīng)用安全數(shù)據(jù)。這些數(shù)據(jù)使得移動(dòng)應(yīng)用的安全解析成為了可能。本文分別從用戶界面解析、重打包應(yīng)用檢測、應(yīng)用功能與安全行為一致性檢測、基于上下文的惡意行為檢測、終端用戶應(yīng)用管理和使用行為分析這五個(gè)方面介紹了移動(dòng)應(yīng)用安全解析學(xué)目前的成果。同時(shí), 基于以上的研究成果, 對(duì)未來的研究方向進(jìn)行了展望, 并討論了這些研究方向面臨的挑戰(zhàn)。

移動(dòng)安全; 數(shù)據(jù)解析; 機(jī)器學(xué)習(xí); 程序分析

1 引言

1.1 移動(dòng)應(yīng)用安全解析學(xué)概述

隨著移動(dòng)終端(如智能手機(jī), 平板電腦等)的普及, 基于應(yīng)用商店的發(fā)布模式成為軟件應(yīng)用的重要模式, 移動(dòng)應(yīng)用產(chǎn)業(yè)得到了快速的增長。截至2015年, 在Apple Store、Google Play等主流應(yīng)用商店和360、豌豆莢等第三方應(yīng)用商店上已經(jīng)積累了數(shù)百萬移動(dòng)應(yīng)用。由于移動(dòng)應(yīng)用可從移動(dòng)終端獲得大量的敏感信息, 且其本身能通過移動(dòng)市場及廣告商產(chǎn)生高利潤, 移動(dòng)應(yīng)用頻頻遭到了黑客的攻擊。移動(dòng)應(yīng)用安全事件頻發(fā)。究其原因, 主要來源于如下幾個(gè)方面: 簡單的應(yīng)用市場安全審查、粗粒度的權(quán)限系統(tǒng)、有限的系統(tǒng)級(jí)安全監(jiān)測, 以及鼓勵(lì)快速傳播的應(yīng)用分派模式, 等等。海量的移動(dòng)應(yīng)用缺乏集中有效的安全管理等, 都導(dǎo)致大量的惡意移動(dòng)應(yīng)用, 或是存在安全漏洞的低質(zhì)量移動(dòng)應(yīng)用, 被發(fā)布在移動(dòng)應(yīng)用市場。如何從海量的移動(dòng)應(yīng)用中精確地識(shí)別出可能會(huì)給移動(dòng)終端帶來安全隱患的應(yīng)用, 成為移動(dòng)應(yīng)用安全研究的重要問題之一。

從量大面廣、不斷推陳出新的移動(dòng)應(yīng)用中準(zhǔn)確識(shí)別惡意應(yīng)用是很有挑戰(zhàn)性的問題之一, 得到了學(xué)術(shù)界和工業(yè)界的廣泛關(guān)注[19] [13] [20]。但同時(shí), 這些海量應(yīng)用為移動(dòng)應(yīng)用的安全分析提供了充足的歷史數(shù)據(jù)進(jìn)行參考。利用機(jī)器學(xué)習(xí)的方法來進(jìn)行數(shù)據(jù)解析(Data Analytics)已成為應(yīng)用安全分析的重要手段。圖1描述了移動(dòng)應(yīng)用安全解析的幾個(gè)關(guān)鍵步驟。

首先, 安全解析會(huì)通過程序分析或文本分析在移動(dòng)應(yīng)用中提取相關(guān)特征(feature), 同時(shí), 如有必要, 將提取相關(guān)的領(lǐng)域知識(shí)(domain knowledge)。此后提取的特征將會(huì)被進(jìn)一步地處理。處理之后, 整個(gè)特征數(shù)據(jù)集會(huì)被分為訓(xùn)練樣本集(training data set)及測試樣本集(testing data set)。機(jī)器學(xué)習(xí)算法利用訓(xùn)練樣本數(shù)據(jù)集, 并參考提取的領(lǐng)域知識(shí), 生成機(jī)器學(xué)習(xí)模型。而測試樣本數(shù)據(jù)則用于樣本測試以評(píng)估生成的機(jī)器學(xué)習(xí)模型, 并產(chǎn)生最后的評(píng)估結(jié)果。

本文從五個(gè)方面, 概述了目前學(xué)術(shù)界如何利用海量的移動(dòng)應(yīng)用數(shù)據(jù)對(duì)應(yīng)用的安全性進(jìn)行解析, 并選取一些典型工作加以介紹。本文第二節(jié)介紹了基于用戶界面解析的敏感信息安全管理機(jī)制。其中著重介紹了兩個(gè)用于發(fā)現(xiàn)并保護(hù)用戶輸入的敏感信息的安全技術(shù):SUPOR[13]和UIPicker[25]。本文第三節(jié)介紹了重打包應(yīng)用的檢測技術(shù)。其中著重介紹了WuKong[9], 去除第三方庫干擾且可擴(kuò)展的重打包應(yīng)用檢測系統(tǒng)。本文第四節(jié)介紹了軟件功能與安全行為的一致性(consistency)研究。這類研究致力于檢測應(yīng)用中非用戶所期望的敏感行為。此類研究一般基于一個(gè)重要假設(shè), 即應(yīng)用市場中的軟件功能描述反映了用戶對(duì)應(yīng)用行為的期望。在這個(gè)假設(shè)的基礎(chǔ)上, 此類研究利用文本分析等技術(shù)來檢測真實(shí)的應(yīng)用安全行為是否與用戶所能覺察到的功能描述保持一致。本文第五節(jié)介紹基于上下文(Context)的惡意行為檢測技術(shù)。這類研究表明一個(gè)行為發(fā)生的上下文可以有效反映應(yīng)用執(zhí)行這個(gè)行為的目的。而執(zhí)行行為的目的可以作為甄別行為的惡意性的主要依據(jù)。這類研究通過程序分析來提取安全行為的上下文, 并通過這些提取的上下文來輔助機(jī)器學(xué)習(xí)算法檢測惡意行為。本文第六節(jié)介紹了移動(dòng)終端應(yīng)用的管理和使用。這類研究一般基于Android用戶數(shù)據(jù)分析, 然后從數(shù)據(jù)中發(fā)現(xiàn)可能存在惡意行為的應(yīng)用。此小節(jié)探究了三種可供安全分析參考的用戶數(shù)據(jù), 即非主動(dòng)安裝, 用戶卸載行為及異常流量檢測。當(dāng)數(shù)據(jù)維度增多、規(guī)模增大、更高效準(zhǔn)確的算法被提出之后, 此類方法幫助我們發(fā)現(xiàn)更多的安全隱患。

2 用戶界面解析(UI Analytics)

智能手機(jī)用戶通過手機(jī)應(yīng)用的圖形用戶界面(GUI, Graphical User Interface)與手機(jī)應(yīng)用進(jìn)行交互, 例如選擇圖標(biāo)或者輸入用戶名和密碼。通過這些交互過程, 用戶與手機(jī)應(yīng)用之間進(jìn)行了信息的輸入與輸出。在這些用戶輸入的信息中, 包括很多用戶的敏感信息, 例如用戶名、身份證號(hào)碼、銀行卡號(hào)碼等。如果這些輸入的敏感信息被手機(jī)應(yīng)用無意的以明文形式發(fā)送出去, 或者惡意的發(fā)送到遠(yuǎn)端服務(wù)器, 將會(huì)對(duì)用戶的隱私安全造成嚴(yán)重的危害。

當(dāng)前, 移動(dòng)安全研究主要集中在能夠被智能手機(jī)操作系統(tǒng)和應(yīng)用開發(fā)API所管理的用戶敏感信息, 例如聯(lián)系人信息、GPS位置, 等等。智能手機(jī)操作系統(tǒng)通過權(quán)限對(duì)這些敏感信息進(jìn)行管理。為了訪問這些敏感信息, 移動(dòng)應(yīng)用開發(fā)者必須聲明相應(yīng)的權(quán)限, 并經(jīng)過用戶同意后, 該手機(jī)應(yīng)用才會(huì)被授予請(qǐng)求的權(quán)限。然而, 這些被權(quán)限管理的數(shù)據(jù)通常并沒有包括所有的用戶敏感信息。作為一種主要的用戶敏感信息, 用戶輸入的信息就不能被手機(jī)操作系統(tǒng)的權(quán)限進(jìn)行管理。因此, 我們需要新的安全管理機(jī)制來發(fā)現(xiàn)并且保護(hù)用戶輸入的敏感信息。

SUPOR提出了一種結(jié)合靜態(tài)分析和自然語言處理的方法, 如圖2所示。該方法對(duì)用戶界面進(jìn)行靜態(tài)分析, 自動(dòng)找出接受用戶輸入敏感信息的文本框, 并把這些文本框跟手機(jī)應(yīng)用程序里面存儲(chǔ)這些文本框輸入的程序變量關(guān)聯(lián)起來。利用這種關(guān)聯(lián), 我們就可以使用現(xiàn)有的信息泄露分析技術(shù)來檢測手機(jī)應(yīng)用是否泄露了用戶輸入的敏感信息。

此外, UIPicker提出了一種結(jié)合機(jī)器學(xué)習(xí)、自然語言處理和程序分析的方法, 如圖4所示。該方法利用大量的用戶界面顯示的信息生成分類器, 用于判斷描述用戶界面控件的提示文字是否含有敏感信息的提示。為了提高發(fā)現(xiàn)潛在安全隱患的精準(zhǔn)度, UIPicker進(jìn)一步利用程序分析對(duì)用戶界面的控件進(jìn)行分析, 從而保證對(duì)用戶界面顯示的信息的分析結(jié)果更加精確和全面。

2.1 問題描述

智能手機(jī)的界面包含著各式各樣的UI控件, 例如按鈕、文本框和圖文列表。每一種控件都接受某一類型的用戶輸入。比如按鈕接受點(diǎn)擊、文本框接受用戶輸入的文字、圖文列表接受用戶的選擇等。這些控件一般都有相應(yīng)的文字提示, 來告訴用戶他們希望得到的用戶輸入。圖3是某Android應(yīng)用的用戶登錄界面。該用戶界面包括兩個(gè)文本框, 第一個(gè)文本框接受用戶輸入的帳號(hào), 第二個(gè)文本框接受用戶輸入的密碼。顯而易見, 這些輸入都屬于敏感信息, 以明文傳輸這些信息到遠(yuǎn)程服務(wù)器會(huì)造成對(duì)用戶隱私的危害。

自動(dòng)檢測UI控件是否接受包含有敏感信息的用戶輸入主要存在三點(diǎn)挑戰(zhàn): (1) 由于用戶輸入不由操作系統(tǒng)的權(quán)限進(jìn)行管理, 現(xiàn)有的針對(duì)系統(tǒng)API的方法都沒法使用。判定用戶輸入是否包含有敏感信息, 需要分析相關(guān)UI 控件的文字提示信息。 (2)如何精確的把用戶界面顯示的文字提示與UI控件對(duì)應(yīng)起來？每個(gè)用戶界面都有很多個(gè)UI控件, 而每個(gè)UI控件的附近又可能有多處文字提示。例如, 在圖3, 第一個(gè)文本框上面的文字提示是帳號(hào), 而下面的文字提示是密碼。因此, 準(zhǔn)確的匹配UI控件及其文字提示是判斷用戶輸入是否包含敏感信息的前提。(3)如何判定文字提示的內(nèi)容是要求用戶輸入敏感的信息？文字提示的內(nèi)容都是用自然語言寫的, 而這些內(nèi)容的語義沒法被程序直接分析。

a) 用戶界面的分析

針對(duì)檢測用戶輸入敏感信息的第一點(diǎn)挑戰(zhàn), 即分析相關(guān)UI 控件的文字提示信息, SUPOR和UIPicker都提出了對(duì)用戶界面分析的技術(shù)。智能手機(jī)的用戶界面一般采用聲明式語言進(jìn)行定義。比如, Android應(yīng)用通常有多個(gè)用戶界面。每個(gè)用戶界面統(tǒng)一使用XML定義用戶界面, 包括用戶界面的布局, UI 控件的定義, 還有UI界面顯示的資源(圖標(biāo)和字符串)。通過分析這些定義文件, 我們可以在不運(yùn)行應(yīng)用的情況下就知道一個(gè)手機(jī)應(yīng)用有多少個(gè)界面和每個(gè)界面的控件。同時(shí), 通過利用ADT(Android開發(fā)工具)的類庫, 我們也可以靜態(tài)地渲染每個(gè)UI界面。這些分析使得SUPOR和UIPicker都能把UI控件的文字信息抽取出來, 并通過分析這些文字信息來判定UI控件是否會(huì)接受用戶輸入的敏感信息。

b) 敏感關(guān)鍵詞的數(shù)據(jù)收集

由于智能手機(jī)的屏幕尺寸的限制, UI控件的文字提示一般都是短語或者單詞, 很少有成段的文本提示用于描述一個(gè)UI控件所要接受的用戶輸入。因此, 使用基于關(guān)鍵詞的自然語言分析技術(shù)可以有效地分析這些文字提示。為了收集表示敏感信息的關(guān)鍵詞, SUPOR和UIPicker提出了兩個(gè)方法。

方法一: 自然語言處理與分析

SUPOR首先收集了54,371個(gè)Android應(yīng)用的UI文字信息, 然后利用自然語言處理的技術(shù), 對(duì)頻繁出現(xiàn)的短語和句子進(jìn)行結(jié)構(gòu)分析, 抽取出名詞和名詞短語。在抽取出的這些名詞和名詞短語里面, 再通過人工分析并劃分出10類關(guān)于敏感信息的關(guān)鍵詞。

方法二: 基于Chi-Square的聚類

UIPicker首先根據(jù)初始給定的敏感詞語對(duì)用戶界面的定義文件進(jìn)行分類, 然后利用Chi-Square測試的方法抽取在這些界面定義文件里面具有代表性的詞語。這些抽取出來的詞語再通過人為篩選, 然后擴(kuò)充敏感關(guān)鍵詞。

c) 用戶輸入分類

針對(duì)檢測用戶輸入敏感信息的第二和第三點(diǎn), SUPOR和UIPicker提出了不同的解決方法。

方法一: 用戶界面分析

SUPOR通過靜態(tài)的UI渲染, 計(jì)算出每個(gè)UI 控件和文字提示的絕對(duì)坐標(biāo)。這樣, SUPOR就進(jìn)一步地能計(jì)算出每個(gè)文字提示到達(dá)任何一個(gè)文本框的距離。對(duì)于一個(gè)UI 控件, 用戶一般都是看離該控件最近的文件提示來確定該UI控件接受哪種內(nèi)容的用戶輸入?；谶@個(gè)觀察, SUPOR挑選最近的文字提示, 并且利用收集的敏感關(guān)鍵詞來判定該UI控件是否接受用戶輸入的敏感信息。

方法二: 建模解析

不同于SUPOR, UIPicker收集UI控件的文字信息以及其布局定義文件里面的資源定義, 并利用這些信息來對(duì)UI 控件進(jìn)行歸類。 UIPicker利用收集的敏感關(guān)鍵詞做為特征, 采用支持向量機(jī)(Support Vector Machine, SVM)訓(xùn)練出一個(gè)分類器, 然后利用該分類器可以對(duì)任意一個(gè)UI控件進(jìn)行分類, 判定其是否接受敏感輸入。

2.2 實(shí)驗(yàn)結(jié)果

實(shí)驗(yàn)結(jié)果表明, SUPOR和UIPicker提出的方法都達(dá)到了大于90%的精確度。 SUPOR由于采用了用戶界面分析的方法來匹配文字提示和文本框, 因而在精確度上可以達(dá)到97.3%, 高于UIPicker的93.6%。UIPicker的機(jī)器學(xué)習(xí)方法除了可以應(yīng)用在文本框上, 在其他UI 控件上也達(dá)到了很高的精確度。

2.3 展望和挑戰(zhàn)

用戶通過用戶界面與手機(jī)應(yīng)用進(jìn)行交互。SUPOR和UIPicker專注于分析用戶界面中的文字信息。除了文字信息, 用戶界面還包含圖標(biāo)等其他信息。全面分析這些信息有助于檢測更多的惡意手機(jī)應(yīng)用。例如, 惡意手機(jī)應(yīng)用可以通過假的用戶界面以騙取用戶輸入的信息。如何對(duì)用戶界面進(jìn)行更深度的分析以保護(hù)用戶的安全和隱私將會(huì)成為一個(gè)重要的研究方向。

3 重打包檢測分析

3.1 研究背景

相對(duì)于iOS應(yīng)用, Android應(yīng)用更加容易被破解, 且由于Android系統(tǒng)的開源特性, Android應(yīng)用造成的安全隱患也更大。目前有很多的反編譯工具可以使用。惡意的開發(fā)者可以將原應(yīng)用反編譯之后, 進(jìn)行修改, 例如替換掉原應(yīng)用中的廣告庫或者加入一些惡意代碼, 然后重新打包并且發(fā)布出去。應(yīng)用重打包的行為不僅侵犯了開發(fā)者的利益, 也嚴(yán)重威脅到了用戶的安全和隱私。應(yīng)用重打包已經(jīng)成為移動(dòng)平臺(tái)上惡意軟件傳播的主要方式。

目前關(guān)于Android應(yīng)用的重打包檢測有很多相關(guān)工作, 可以分為如下幾類:

(1) 基于哈希的檢測技術(shù)

DroidMOSS[22]使用模糊哈希技術(shù)來對(duì)應(yīng)用中指令序列生成指紋來檢測重打包應(yīng)用。類似的, Juxtapp [18] 使用特征哈希來對(duì)應(yīng)用產(chǎn)生指紋。

(2) 基于應(yīng)用靜態(tài)特征的技術(shù)

FSquaDRA[26]和PlayDrone[15]使用應(yīng)用中的資源文件作為特征來進(jìn)行重打包檢測。PiggyDroid[22]使用API調(diào)用等靜態(tài)特征來做檢測。ViewDroid[6]使用用戶界面的視圖作為特征。

(3) 基于代碼克隆檢測的技術(shù)

DNADroid[12]使用了程序依賴圖(PDG)作為特征來進(jìn)行檢測。Centroid[14]通過找到程序依賴圖的集合中心來進(jìn)行比較。

但是現(xiàn)有的應(yīng)用重打包檢測工作主要存在兩點(diǎn)挑戰(zhàn): (1) 如何在達(dá)到準(zhǔn)確性的同時(shí)保持可伸縮性？應(yīng)用市場存在上百萬的應(yīng)用, 因此應(yīng)用重打包檢測系統(tǒng)需要在上百萬個(gè)應(yīng)用中快速準(zhǔn)確的找出重打包應(yīng)用, 并保證在有新應(yīng)用添加時(shí)能夠增量式的快速檢測新應(yīng)用是否是重打包應(yīng)用。(2) 如何準(zhǔn)確的去除第三方庫的影響？Android應(yīng)用的特點(diǎn)之一是大量的使用了第三方庫, 而第三方庫會(huì)對(duì)檢測重打包應(yīng)用帶來很大的干擾。

針對(duì)這兩點(diǎn)挑戰(zhàn), WuKong[9]提出了兩個(gè)關(guān)鍵技術(shù): (1)提出一個(gè)兩階段的應(yīng)用重打包檢測方法。第一階段先使用簡單的靜態(tài)特征快速找出可能的重打包應(yīng)用對(duì), 然后在第二階段使用更準(zhǔn)確的代碼克隆檢測技術(shù)對(duì)找出的應(yīng)用對(duì)進(jìn)行細(xì)粒度比較。(2)提出一種基于聚類的方法來準(zhǔn)確的識(shí)別并過濾第三方庫, 這種方法可以找出不同版本的第三方庫并且不受混淆的影響。

3.2 系統(tǒng)概述

如圖5所示, WuKong的工作流程包括預(yù)處理階段、粗粒度檢測階段和細(xì)粒度檢測階段。預(yù)處理階段先對(duì)應(yīng)用程序進(jìn)行反編譯, 提取包粒度的特征, 進(jìn)行聚類, 然后根據(jù)聚類結(jié)果過濾第三方庫。在粗粒度階段, 根據(jù)應(yīng)用的靜態(tài)特征快速的找出可能的重打包應(yīng)用對(duì)。然后在細(xì)粒度檢測階段, 對(duì)于可能的重打包應(yīng)用對(duì), 提取代碼塊級(jí)別特征, 然后進(jìn)行相似度比較, 從而找出重打包應(yīng)用。

3.3 第三方庫過濾

3.3.1 挑戰(zhàn)

很多研究工作都是通過白名單的方式來過濾第三方庫, 即通過比較包名是否與白名單中的第三方庫包名相同。然而, 這種方法存在一些問題。首先, 現(xiàn)有的工作都不可能建立一個(gè)完整的第三方庫白名單。大部分工作都使用了大約100個(gè)左右的第三方庫白名單, 遠(yuǎn)遠(yuǎn)少于現(xiàn)有第三方庫的數(shù)量。其次, 在Android應(yīng)用中, 有超過50%的第三方庫都存在不同程度的混淆[5]。被混淆過的代碼中, 包名有可能發(fā)生改變, 例如包名被更改為“com/a/b”。因此, 被混淆后的第三方庫不能通過白名單的方式來過濾。

3.3.2 基于聚類的第三方庫過濾

Android應(yīng)用中的第三方庫使用有兩大特點(diǎn): (1) 第三方庫一般會(huì)被大量的應(yīng)用所使用; (2) 開發(fā)者在使用第三方庫的時(shí)候一般不會(huì)對(duì)其進(jìn)行修改, 因此可以通過聚類的方法將第三方庫檢測出來。根據(jù)這兩個(gè)特點(diǎn), 如果我們對(duì)大量應(yīng)用在包粒度提取特征并且進(jìn)行聚類, 那么屬于第三方庫的包就會(huì)聚到一個(gè)很大的類里面, 通過這種方法我們可以將第三方庫檢測并過濾。

對(duì)于每個(gè)應(yīng)用, 我們?cè)诎６忍崛∷械腁ndroid API調(diào)用特征, 其中包括不同API的調(diào)用的次數(shù)。然后, 根據(jù)API調(diào)用特征來進(jìn)行聚類。在聚類的時(shí)候進(jìn)行嚴(yán)格匹配, 即只有API調(diào)用特征完全一樣的包我們才會(huì)聚在一起。因此, 我們的聚類算法是首先對(duì)每個(gè)包根據(jù)API調(diào)用次數(shù)進(jìn)行排序, 只有調(diào)用次數(shù)完全一樣的時(shí)候, 才比較它們的特征并且進(jìn)行聚類。

基于聚類的第三方庫過濾有以下優(yōu)點(diǎn):

(1) 能夠在沒有先驗(yàn)知識(shí)的情況下檢測出第三方庫。我們檢測到的第三方庫數(shù)量遠(yuǎn)遠(yuǎn)超過白名單方式標(biāo)記的庫的數(shù)量。

(2) 能夠檢測第三方庫的不同版本, 只要有足夠多的應(yīng)用使用這個(gè)第三方庫。

(3) 代碼混淆對(duì)于我們的檢測沒有影響, 因?yàn)槲覀兪褂昧薃ndroid API特征, 在Android 應(yīng)用中常用的命名混淆對(duì)我們的特征沒有影響。

3.4 兩階段的重打包檢測

3.4.1 粗粒度檢測

為了進(jìn)行快速比較, 在粗粒度檢測階段, WuKong使用比較簡單的Android API特征, 主要是不同API的調(diào)用次數(shù)。每個(gè)應(yīng)用被表示成一個(gè)API向量。原理是如果兩個(gè)應(yīng)用核心代碼相似的話, 那么它們的API調(diào)用也比較相似。盡管這樣會(huì)造成一些誤報(bào)(兩個(gè)不同的應(yīng)用的API調(diào)用向量相似), 但是漏報(bào)率會(huì)非常低。WuKong使用曼哈頓距離來表示兩個(gè)API向量的相似度, 如果兩個(gè)應(yīng)用的距離小于給定閾值, 就會(huì)被選出來進(jìn)行細(xì)粒度檢測。

3.4.2 細(xì)粒度檢測

對(duì)于粗粒度檢測階段過濾出來的可能的重打包應(yīng)用對(duì),WuKong提取更詳細(xì)的特征來比較它們的相似度。細(xì)粒度檢測是基于已有的基于計(jì)數(shù)的代碼克隆檢測技術(shù)Boreas[23] [24]。

WuKong將每個(gè)變量在不同計(jì)數(shù)環(huán)境下出現(xiàn)的次數(shù)作為特征, 對(duì)每個(gè)變量得到一個(gè)特征計(jì)數(shù)向量。計(jì)數(shù)環(huán)境用來描述代碼片段中變量的行為特征。WuKong使用了如下的計(jì)數(shù)環(huán)境來描述變量的特征: (1)出現(xiàn)且使用次數(shù);(2)被定義的次數(shù);(3)在條件判斷語句中出現(xiàn)次數(shù);(4)在第一層循環(huán)中出現(xiàn)次數(shù);(5)在第二層循環(huán)中出現(xiàn)次數(shù);(6)在第三層及更深循環(huán)中出現(xiàn)次數(shù);(7)在加/減運(yùn)算中出現(xiàn)的次數(shù);(8)在乘/除運(yùn)算中出現(xiàn)的次數(shù);(9)作為數(shù)組下標(biāo)次數(shù);(10)被常量表達(dá)式定義次數(shù)。

對(duì)每個(gè)變量得到一個(gè)特征計(jì)數(shù)向量之后, 可以對(duì)于每個(gè)代碼片段得到一個(gè)特征計(jì)數(shù)矩陣。因此, 每個(gè)應(yīng)用的特征由一系列的特征計(jì)數(shù)矩陣表示, 從而兩個(gè)應(yīng)用之間的相似度就是比較它們的特征計(jì)數(shù)矩陣有多少是相似的。

特征向量的相似度可以通過比較兩個(gè)向量之間的余弦相似度得到。為了計(jì)算特征矩陣A和B的相似度, 對(duì)于矩陣A中的每個(gè)向量, 首先找到與其最大相似匹配的矩陣B中的另一向量, 然后兩個(gè)矩陣的相似度是由所有向量相似度的乘積得到。應(yīng)用之間的相似度, 是比較兩個(gè)應(yīng)用中有多少相似的代碼塊。

3.5 實(shí)驗(yàn)結(jié)果

WuKong選取了國內(nèi)五個(gè)第三方應(yīng)用市場中超過10萬個(gè)應(yīng)用進(jìn)行實(shí)驗(yàn), 如表1所示。

表1 實(shí)驗(yàn)數(shù)據(jù)來源

對(duì)應(yīng)用進(jìn)行預(yù)處理之后, 我們發(fā)現(xiàn)有超過60%的代碼來自第三方庫, 因此這些代碼可以被過濾掉。在粗粒度檢測之后, 共檢測到93,122個(gè)可能的重打包應(yīng)用對(duì), 其中包含14,702個(gè)應(yīng)用。雖然這些應(yīng)用占了總應(yīng)用的14%左右, 但是可能的重打包應(yīng)用對(duì)比總應(yīng)用對(duì)減少了五個(gè)數(shù)量級(jí), 極大的縮短了細(xì)粒度階段所需要的檢測時(shí)間。

在細(xì)粒度檢測之后, 總共檢測到80,439個(gè)重打包應(yīng)用對(duì), 其中包含12,922個(gè)不同的應(yīng)用, 占了總共數(shù)據(jù)集的12%左右。市場內(nèi)部與市場間的重打包關(guān)系如圖6所示。除了市場間的重打包應(yīng)用, WuKong還發(fā)現(xiàn)了在同一個(gè)應(yīng)用市場內(nèi)部有相當(dāng)數(shù)量的重打包應(yīng)用。例如, WuKong發(fā)現(xiàn)eoe市場中有4,368個(gè)應(yīng)用是屬于重打包應(yīng)用, 占了WuKong分析的該市場應(yīng)用的10%以上。這個(gè)結(jié)果也說明了在應(yīng)用市場內(nèi)進(jìn)行重打包檢測的重要性。

3.6 展望和挑戰(zhàn)

應(yīng)用重打包是移動(dòng)平臺(tái)上惡意軟件傳播的主要方式。在應(yīng)用市場中進(jìn)行重打包應(yīng)用分析有助于找出可疑的應(yīng)用, 根據(jù)添加和修改的代碼可以來分析應(yīng)用的惡意行為。同時(shí), 應(yīng)用重打包也促進(jìn)了應(yīng)用加固技術(shù)的研究, 如何對(duì)應(yīng)用進(jìn)行保護(hù)以及防止惡意的開發(fā)者進(jìn)行破解也是主要的一個(gè)研究方向。

4 軟件功能與安全行為間一致性研究

4.1 功能和行為

應(yīng)用商店, 例如Apple Store和Google Play Store, 為用戶提供了豐富的應(yīng)用軟件, 在智能手機(jī)的普及上起到了關(guān)鍵的作用, 但是這些應(yīng)用商店也給惡意軟件的傳播提供了捷徑。目前, 主流的iOS和Android操作系統(tǒng)都有其獨(dú)有的權(quán)限控制機(jī)制來遏制惡意軟件。

蘋果iOS系統(tǒng)采用實(shí)時(shí)權(quán)限請(qǐng)求機(jī)制, 即當(dāng)軟件在每次觸發(fā)到需要權(quán)限的行為時(shí)都會(huì)告知用戶。而Android系統(tǒng)在軟件安裝時(shí)就會(huì)向用戶確認(rèn)該程序正常使用的權(quán)限列表, 等用戶同意安裝后才該軟件將會(huì)被授權(quán)所有被請(qǐng)求的權(quán)限。這些操作系統(tǒng)都要求手機(jī)用戶通過閱讀軟件描述、用戶評(píng)價(jià)和軟件評(píng)分, 以及通過判斷該軟件所請(qǐng)求的權(quán)限的合理性來區(qū)分正常軟件和惡意軟件。但是, 現(xiàn)階段大部分的研究工作主要側(cè)重于單方面分析應(yīng)用軟件的權(quán)限、代碼或?qū)崟r(shí)監(jiān)測來檢測軟件行為是否惡意, 卻忽略了一個(gè)重要的問題: 用戶所期望的軟件行為是什么？

WHYPER[17]基于用戶所期望的軟件行為這樣一種思路, 首次提出了一種基于自然語言處理的軟件風(fēng)險(xiǎn)分析方法, 如圖7所示。該方法在軟件描述和軟件請(qǐng)求的權(quán)限之間建立了一種映射關(guān)系, 并用這種映射關(guān)系量化軟件功能和軟件真實(shí)行為之間的差異性。實(shí)驗(yàn)結(jié)果表明, 自然語言處理技術(shù)能夠有效的識(shí)別出這種差異性, 并能準(zhǔn)確對(duì)軟件提供風(fēng)險(xiǎn)評(píng)估。

此外, AutoCog[28]提出了一種結(jié)合機(jī)器學(xué)習(xí)和自然語言處理的方法, 如圖8所示。該方法利用大量的數(shù)據(jù)生成軟件描述和軟件請(qǐng)求權(quán)限之間的關(guān)系模型, 從而使分析結(jié)果更精準(zhǔn)和全面。

4.2 問題描述

通常情況下, 應(yīng)用軟件不會(huì)在軟件描述中闡述請(qǐng)求特定權(quán)限的原因。然而大部分惡意軟件經(jīng)常會(huì)請(qǐng)求一些和軟件功能無關(guān)的權(quán)限[27] [1]。例如, 一個(gè)惡意時(shí)鐘軟件會(huì)使用GPS權(quán)限發(fā)送用戶的地理位置信息。但是對(duì)于一個(gè)GPS追蹤軟件, 把用戶的地理位置信息通過網(wǎng)絡(luò)端發(fā)送出去是正常行為, 而并非隱私泄漏。同理, 一個(gè)用來Root手機(jī)的軟件, 通過利用權(quán)限提升漏洞獲取Root權(quán)限的行為也應(yīng)被看做是正常行為。因此, 用戶所期望的軟件功能和軟件真實(shí)行為之間的差異性應(yīng)當(dāng)是檢測惡意軟件重要指標(biāo)之一。我們所面臨的問題是如何自動(dòng)化識(shí)別出用戶所期望的軟件功能和軟件真實(shí)行為之間的差異性, 并用此差異性來對(duì)軟件進(jìn)行風(fēng)險(xiǎn)評(píng)估。

具體來說, 我們需要尋求一種方法, 通過軟件描述估測用戶所期望的軟件功能, 同時(shí)從軟件請(qǐng)求的權(quán)限估測軟件的真實(shí)行為。前者需要我們對(duì)軟件描述進(jìn)行語義上的分析, 后者需要我們對(duì)軟件權(quán)限進(jìn)行語義上的分析。

盡管關(guān)鍵詞搜索法是最直接、最易實(shí)現(xiàn)的, 但是它在語義推理和處理語義混合效應(yīng)上有諸多局限性。因此研究人員采用自然語言處理技術(shù)來取代關(guān)鍵詞搜索法。

4.3 語義處理

4.3.1 句子劃分

首先需要將軟件描述中的句子區(qū)分出來, 同時(shí)盡可能地降低詞法記號(hào)(lexical token)的數(shù)量。這樣能夠有效的幫助我們提高分析的準(zhǔn)確度。具體來說需要處理如下幾種情況:

1. 句號(hào): 英文中句號(hào)(‘.’)除了可以當(dāng)做句子結(jié)尾符號(hào), 也可以在小數(shù)點(diǎn), 省略號(hào)和簡化符號(hào)(例如“Mr.”)中出現(xiàn)。

2. 句子劃分: 除了句號(hào)外, 標(biāo)號(hào), 點(diǎn)句, 分隔符等其他特殊符號(hào)都能劃分句子。

3. 命名: 代表名字的一連串單詞沒有必要進(jìn)行再拆分。例如“Google Map”。

4. 簡寫: 有時(shí)候縮寫和原詞常常放在一起, 例如: “Instant Message (IM)”。對(duì)簡寫進(jìn)行分析是沒有必要的。

4.3.2 句子結(jié)構(gòu)分析

WHYPER和AutoCog都采用Stanford Parser對(duì)句子里的命名, 從屬關(guān)系(Stanford-Typed Dependency)和詞性進(jìn)行標(biāo)注, 之后還對(duì)單詞進(jìn)行了主次關(guān)系標(biāo)注, 如圖9(對(duì)句子“Also you can share the yoga exercise to your friends via Email and SMS”的標(biāo)注)所示。

有研究表明, 一階邏輯(First Order Logic)能夠有效的表達(dá)文本中的相互關(guān)系[2] [3] [16], 因此WHYPER進(jìn)一步采用一階邏輯樹形圖, 當(dāng)作語義解析的中間語言, 如圖10所示。在這種表達(dá)形式中, 葉節(jié)點(diǎn)都是實(shí)體節(jié)點(diǎn), 葉節(jié)點(diǎn)外所有節(jié)點(diǎn)都是謂語(predicate)節(jié)點(diǎn); 在每個(gè)謂語節(jié)點(diǎn)下的第一個(gè)子節(jié)點(diǎn)是主實(shí)體(節(jié)點(diǎn)7), 第二個(gè)子節(jié)點(diǎn)是次實(shí)體(節(jié)點(diǎn)10), 即這兩個(gè)子節(jié)點(diǎn)為主次關(guān)系。

WHYPER還研究實(shí)現(xiàn)了一個(gè)結(jié)合shallow parsing[4]技術(shù)的級(jí)聯(lián)有限狀態(tài)機(jī)(cascading finite state machine),將標(biāo)注了從屬關(guān)系后的文本轉(zhuǎn)換為一階邏輯樹形圖的表達(dá)形式。在該表達(dá)形式之后將會(huì)與分析出的軟件真實(shí)行為進(jìn)行差異性比較。

4.4 差異匹配

方法一: 單一分析

為了獲取應(yīng)用的真實(shí)行為, 我們分析軟件需要調(diào)用的系統(tǒng)API函數(shù)。這是因?yàn)? 區(qū)別于傳統(tǒng)PC軟件, 手機(jī)端的軟件所能用到的系統(tǒng)資源有限。分析手機(jī)軟件對(duì)系統(tǒng)資源的訪問能夠幫助我們估測出軟件的真實(shí)行為。WHYPER首先列出所有API所需的權(quán)限; 其次, 對(duì)每個(gè)權(quán)限, 找出其調(diào)用的資源與行為并整合成語義圖。權(quán)限CONTACT能夠允許軟件從聯(lián)系簿獲取手機(jī)號(hào)、郵件、地址等信息, 并且可以對(duì)聯(lián)系簿進(jìn)行讀取、顯示、發(fā)送等操作, 如圖11所示。

最后, WHYPER對(duì)通過一階邏輯樹形圖里面的實(shí)體節(jié)點(diǎn)分和謂語節(jié)點(diǎn)與語義圖里資源的訪問類型和方法進(jìn)行匹配, 并找出差異。

方法二: 建模與大數(shù)據(jù)解析

AutoCog分別提出了“文本語義模型”和“描述對(duì)權(quán)限關(guān)聯(lián)性模型(description-to-permission relatedness model, 簡稱DPR, 如圖12所示)”。

文本語義模型用來描述詞匯之間語義上的關(guān)聯(lián)性。AutoCog從維基百科采集大量文本數(shù)據(jù), 并用顯示語義分析(Explicit Semantic Analysis)技術(shù)構(gòu)建文本語義模型。

描述對(duì)權(quán)限關(guān)聯(lián)性模型通過詞匯來表征每個(gè)權(quán)限之間安全特性。AutoCog用基于學(xué)習(xí)技術(shù)的算法實(shí)現(xiàn)了權(quán)限關(guān)聯(lián)性模型。該算法對(duì)海量軟件描述進(jìn)行分析, 測量出每一對(duì)主次關(guān)系名詞與各個(gè)權(quán)限的關(guān)聯(lián)性。最后, 通過添加np-counterparts和保留那些與權(quán)限有統(tǒng)計(jì)關(guān)聯(lián)的詞匯來優(yōu)化模型。

最后, 給定一個(gè)應(yīng)用軟件, 用語義模型測量該軟件的描述與其權(quán)限的關(guān)聯(lián)性。

4.5 展望和挑戰(zhàn)

近幾年, 當(dāng)基于自然語言處理技術(shù)的軟件風(fēng)險(xiǎn)評(píng)估框架與其它技術(shù)結(jié)合(例如機(jī)器學(xué)習(xí))后, 會(huì)越來越全面和高效地發(fā)現(xiàn)移動(dòng)應(yīng)用中潛在的風(fēng)險(xiǎn)。今后的工作可以繼續(xù)嘗試與其它技術(shù)融合, 如在程序分析方面, 可進(jìn)一步分析程序的權(quán)限列表, 靜態(tài)代碼或者動(dòng)態(tài)程序分析, 都能更好的描述程序的真實(shí)行為。

5 基于上下文的惡意行為解析

5.1 研究背景

隨著移動(dòng)應(yīng)用的普及, 惡意移動(dòng)應(yīng)用從數(shù)量上和類型上都有顯著地增長。如此快速的增長使得傳統(tǒng)的基于簽名的監(jiān)測方法無法跟上惡意應(yīng)用的進(jìn)化速度。針對(duì)這種情況, 部分研究開始利用機(jī)器學(xué)習(xí)的方法來對(duì)惡意應(yīng)用以及惡意行為進(jìn)行解析。這些研究利用機(jī)器學(xué)習(xí)的方法來總結(jié)惡意行為的模式來對(duì)惡意行為進(jìn)行自動(dòng)檢測。惡意行為的模式

表2 AppContext分類所用特征集

可以是: 方法調(diào)用的模式, 申請(qǐng)權(quán)限的模式, 信息流的模式等。

與此同時(shí), 惡意應(yīng)用也在不斷進(jìn)化以避開防病毒程序的檢測。惡意應(yīng)用軟件的作者會(huì)模仿良性軟件的行為模式, 使得安全分析無法有效檢驗(yàn)惡意應(yīng)用的行為。針對(duì)這種情況, 一些研究提出了利用行為發(fā)生上下文的方法以進(jìn)一步分辨惡意行為和良性行為。這些研究表明, 一個(gè)行為發(fā)生的上下文可以有效反映應(yīng)用執(zhí)行這個(gè)行為的目的。而執(zhí)行行為的目的可以作為甄別行為的惡意性的主要依據(jù)。

在這些研究中, AppContext[20]是一個(gè)利用行為發(fā)生上下文以檢測惡意行為的典型工作。 AppContext通過程序分析來提取安全行為的上下文, 并通過這些提取的上下文來輔助機(jī)器學(xué)習(xí)算法檢測惡意行為。 AppContext主要基于對(duì)惡意應(yīng)用的一個(gè)重要觀察, 即惡意應(yīng)用的設(shè)計(jì)要滿足兩點(diǎn)需求: (1)盡量避開防病毒程序的檢測以延長惡意應(yīng)用在市場中的存活時(shí)間, (2)盡量可能多的觸發(fā)惡意行為以實(shí)現(xiàn)惡意應(yīng)用的效率最大化。

5.2 系統(tǒng)概述

AppContext共分五個(gè)部分:首先通過分析程序的字節(jié)碼來創(chuàng)建程序的調(diào)用圖(Call Graph),并根據(jù)程序中所調(diào)用的安全方法來定位程序中的安全行為。然后, 通過調(diào)用圖來提取觸發(fā)事件(Activation Event), 并將調(diào)用圖轉(zhuǎn)化成適合安全分析的擴(kuò)展調(diào)用圖(Extended Call Graph)。接著, AppContext通過擴(kuò)展調(diào)用圖來創(chuàng)建約減跨過程控制流圖(Reduced Inter-procedure Control Flow Graph), 并通過跨過程控制流圖來找到控制安全行為的條件語句。通過條件語句定位到上下文因素(Context Factor)。最后, 利用機(jī)器學(xué)習(xí)算法來通過觸發(fā)事件和上下文因素將安全行為分類為良性行為以及惡意行為。

5.3 安全行為解析

如表格1所示, AppContext結(jié)合了三種特征集來定義及識(shí)別程序中的安全行為。其中, 行為信息特征集包括程序中請(qǐng)求的權(quán)限和程序中所調(diào)用的安全方法。這兩類信息通過分析程序的配置文件(AndroidManifest.xml)以及字節(jié)碼獲得。

AppContext所用的第二種特征集是觸發(fā)事件特征集。AppContext之所以采用此類特征集是因?yàn)閻阂鈶?yīng)用頻繁地利用手機(jī)系統(tǒng)中的各種事件來觸發(fā)惡意行為。其中, 用于觸發(fā)惡意行為的事件往往與用于觸發(fā)良性行為的事件不同。因?yàn)閻阂廛浖榱吮荛_防病毒程序檢測以及實(shí)現(xiàn)惡意行為效率的最大化, 往往使用觸發(fā)頻率頻繁且用戶不經(jīng)常注意到的事件。比如說, 手機(jī)接收信號(hào)強(qiáng)度的變化?；谶@個(gè)發(fā)現(xiàn), 我們將觸發(fā)事件特征集分為了三種不同的事件:硬件事件、系統(tǒng)事件以及界面事件。其中, 硬件事件是由通過與手機(jī)硬件界面的交互觸發(fā), 如HOME或者BACK按鍵。系統(tǒng)事件通過系統(tǒng)狀態(tài)的變化觸發(fā), 如之前所講信號(hào)強(qiáng)度的變化, 或者系統(tǒng)收到了新的短消息。而界面事件通過用戶與程序本身的界面而觸發(fā), 例如點(diǎn)擊程序中的按鈕。根據(jù)我們的實(shí)驗(yàn)顯示, 系統(tǒng)事件往往會(huì)被作為觸發(fā)惡意行為的事件在惡意應(yīng)用中使用。

AppContext所用的第三種特征集是上下文因素特征集。上下文因素是指那些會(huì)影響安全行為是否會(huì)觸發(fā)的環(huán)境因素, 比如說當(dāng)前的時(shí)間日期。 AppContext之所以將這些因素作為特征集加以考慮, 是因?yàn)閻阂廛浖榱吮荛_用戶或防病毒程序的檢測, 它們會(huì)控制惡意行為在不太會(huì)被檢測的環(huán)境(如特定的時(shí)間地點(diǎn))下觸發(fā)。比如說惡意應(yīng)用DroidDream只會(huì)允許其惡意行為在晚上11點(diǎn)至第二天早上5點(diǎn)間被觸發(fā)。由于用戶在這個(gè)時(shí)間段一般在睡覺, 這樣惡意程序能有效避開用戶的注意力以延長自己的生存時(shí)間。

當(dāng)AppContext通過靜態(tài)分析提取出如上所述的特征集后, 通過人工將所有提取的安全行為標(biāo)記成良性行為與惡意行為, 并利用十倍交叉驗(yàn)證的方法(ten-fold cross-validation)來檢測這些特征集是否能有效檢測惡意應(yīng)用。具體的實(shí)驗(yàn)效果可參照AppContext論文[20]。

5.4 總結(jié)與展望

為了應(yīng)對(duì)惡意應(yīng)用智能性的增加, 手機(jī)應(yīng)用需要對(duì)這種智能性進(jìn)行檢測。利用安全行為的上下文是檢測這種智能性的方法之一。而本章中介紹的AppContext僅為其中有代表性的工作之一。在未來, 隨著惡意應(yīng)用的隱蔽性增加、觸發(fā)頻率更高, 利用上下文解析的方法會(huì)變得更加關(guān)鍵, 以輔助研究者提出相應(yīng)的更智能的檢測方法。

6 移動(dòng)應(yīng)用管理和使用行為分析

6.1 研究背景

隨著移動(dòng)應(yīng)用的普及, 惡意移動(dòng)應(yīng)用從數(shù)量上和類型上都有顯著增長。如此快速的增長使得傳統(tǒng)的基于簽名的監(jiān)測方法無法跟上惡意應(yīng)用的進(jìn)化速度。針對(duì)這種情況, 部分研究開始利用統(tǒng)計(jì)和機(jī)器學(xué)習(xí)的方法, 基于對(duì)終端用戶使用和管理應(yīng)用的行為數(shù)據(jù)進(jìn)行分析, 來推斷惡意應(yīng)用以及惡意行為并進(jìn)行解析。

通過觀察、分析真實(shí)用戶的使用數(shù)據(jù), 可以從中發(fā)現(xiàn)一些潛在的問題, 繼而可以此為根據(jù)有針對(duì)性地分析問題產(chǎn)生的原因, 進(jìn)一步尋求解決問題的方法?；谶@一思路, 本節(jié)從一個(gè)基于Android用戶數(shù)據(jù)的數(shù)據(jù)分析工作出發(fā), 從三個(gè)角度探討如何從數(shù)據(jù)中發(fā)現(xiàn)可能存在惡意行為的應(yīng)用。

6.2 非主動(dòng)安裝

非主動(dòng)安裝一直以來都是困擾智能手機(jī)用戶的一大問題。非主動(dòng)安裝即指一個(gè)應(yīng)用在未經(jīng)用戶允許、不是通過用戶的主動(dòng)選擇而被安裝在了用戶的手機(jī)上, 或者是通過一些帶有迷惑性的界面、語言, 導(dǎo)致用戶進(jìn)行了安裝應(yīng)用的“主動(dòng)”操作, 但這一“主動(dòng)”行為并不是出于用戶本身的意圖。在傳統(tǒng)的PC+ Windows平臺(tái), 這一問題較為普遍。近年來隨著智能手機(jī)的發(fā)展, 非主動(dòng)安裝也隨之進(jìn)入了這一領(lǐng)域。

非主動(dòng)安裝對(duì)于用戶的信息安全來說是具有潛在威脅的。究其根本原因, 在于一個(gè)原本應(yīng)當(dāng)經(jīng)過用戶同意的行為繞開了用戶的確認(rèn), 導(dǎo)致用戶對(duì)于自己的手機(jī)上存在這樣的應(yīng)用并不知情。一個(gè)直接而明顯的影響是這些應(yīng)用占用了手機(jī)的存儲(chǔ)空間。如果這些應(yīng)用同時(shí)具有自啟動(dòng)特性(一個(gè)不經(jīng)用戶同意自行安裝的應(yīng)用, 亦十分可能不經(jīng)用戶同意而主動(dòng)運(yùn)行), 則也會(huì)對(duì)手機(jī)的整體性能造成拖慢。更為嚴(yán)重的問題是, 這些應(yīng)用可能包含惡意行為, 其自行安裝、運(yùn)行的目的即為竊取用戶數(shù)據(jù)。對(duì)于這種行為, 用戶須提高警惕加以防范。

非主動(dòng)安裝的最典型形式是綁定安裝, 即用戶在試圖安裝一個(gè)應(yīng)用時(shí), 被隱式的、不明顯的、或者強(qiáng)制性的安裝了其他若干個(gè)“綁定”在一起的其他應(yīng)用。這一情況可以一定程度上從用戶使用數(shù)據(jù)中得以體現(xiàn)。通過分析用戶使用數(shù)據(jù), 我們發(fā)現(xiàn)存在著一些應(yīng)用對(duì), 它們被共同安裝在同一個(gè)用戶的設(shè)備上的比例相當(dāng)之高。并且, 這些應(yīng)用對(duì)中有相當(dāng)大的比重來源于同一個(gè)開發(fā)者。以某公司開發(fā)的安全軟件A1和手機(jī)管理軟件A2為例, 在所有安裝過這兩個(gè)應(yīng)用的用戶當(dāng)中, 同時(shí)安裝了它們的用戶所占的比例相當(dāng)之高, 超過了70%。通過本地試安裝A1, 我們發(fā)現(xiàn)其確實(shí)綁定安裝的問題, 在安裝A1的過程中, A2被同時(shí)安裝在了手機(jī)上, 即發(fā)生了綁定安裝行為。

根據(jù)這一發(fā)現(xiàn), 我們可以得到如下啟發(fā)。當(dāng)一些應(yīng)用, 尤其是來自于同一開發(fā)者的應(yīng)用被共同安裝的比例較高時(shí), 我們需要提高對(duì)其的警惕性, 警惕該行為是否是由于非主動(dòng)安裝導(dǎo)致。

在傳統(tǒng)PC情境下, 已有相關(guān)研究工作利用應(yīng)用的安裝行為數(shù)據(jù)進(jìn)行分析, 并試圖從中發(fā)現(xiàn)惡意行為。Kwon等人[29]提出過一種利用分析下載圖的方式對(duì)下載應(yīng)用是否具有惡意進(jìn)行分析。比如,應(yīng)用A下載應(yīng)用B和D, 且未知B、D是否具有惡意。但是B后序進(jìn)行了下載C、進(jìn)而C下載F的行為, 而C與F被判斷為惡意應(yīng)用。由此構(gòu)造下載圖并通過對(duì)該圖的分析, 可以很大程度上懷疑B具有惡意性。在移動(dòng)平臺(tái)環(huán)境中, 在擁有行為數(shù)據(jù)的前提下, 我們也可以考慮利用類似技術(shù)進(jìn)行應(yīng)用的惡意性分析。這對(duì)智能手機(jī)上的惡意應(yīng)用發(fā)現(xiàn)相關(guān)工作提供了一個(gè)新思路。本節(jié)前段提到的非主動(dòng)安裝行為可以考慮結(jié)合下載圖進(jìn)行分析。

6.3 用戶卸載行為

當(dāng)用戶在不知情的情況下被安裝了應(yīng)用, 或者是發(fā)現(xiàn)了某一應(yīng)用為惡意應(yīng)用之后, 很有可能會(huì)主動(dòng)卸載該應(yīng)用。因此, 通過分析用戶的應(yīng)用卸載行為, 也可以從一定程度上幫助我們發(fā)現(xiàn)惡意應(yīng)用。這里, 單純分析一個(gè)應(yīng)用被用戶卸載的次數(shù)是不夠準(zhǔn)確的, 因?yàn)椴煌膽?yīng)用有著不同的用戶基數(shù), 一個(gè)用戶量很大的即時(shí)通訊軟件(比如微信)可能下載量很高, 而卸載量也很高。如果直接比較該即時(shí)通訊軟件和另一個(gè)小眾社交軟件的卸載次數(shù), 所得到的結(jié)果并沒有什么意義。Li等人通過對(duì)國內(nèi)某著名Android應(yīng)用市場上1700萬用戶連續(xù)5個(gè)月下載、卸載App的行為進(jìn)行分析后, 提出了一個(gè)直觀的指標(biāo)來度量一個(gè)應(yīng)用被用戶接受的程度[8]: 安裝/卸載比(I/U Ratio), 用來衡量一個(gè)應(yīng)用被卸載的比例, 定義如下: 令一個(gè)應(yīng)用app下載的集合為I(app), 卸載的集合為U(app), 則其安裝卸載比為。直觀而言, 一個(gè)應(yīng)用的安裝卸載比越高, 表示用戶更少的傾向于卸載這個(gè)應(yīng)用, 反之則說明用戶更多的傾向于卸載這個(gè)應(yīng)用。

圖13通過線性回歸, 反映了105萬個(gè)Android App下載次數(shù)與其安裝卸載比之間的關(guān)聯(lián)關(guān)系?？梢钥闯? 應(yīng)用的下載卸載比與其總下載次數(shù)之間的關(guān)聯(lián)并不緊密。從這一角度而言, 應(yīng)用的下載次數(shù)并不能完全反映出用戶對(duì)其的喜好。很多下載量很高的應(yīng)用卸載量也很高, 因此卸載所占比例也非常高。我們進(jìn)一步分析了一個(gè)應(yīng)用的安裝卸載比與其在用戶手機(jī)上的平均存在時(shí)間之間的關(guān)系。所謂存在時(shí)間, 即一個(gè)應(yīng)用從被安裝到用戶的手機(jī)上直至用戶卸載它所經(jīng)過的時(shí)間。這一關(guān)系展現(xiàn)在圖14中?？梢钥吹? 隨著安裝卸載比的提高, 應(yīng)用的平均存在時(shí)間有增長的趨勢(shì)。

因此, 可以認(rèn)為應(yīng)用的安裝卸載比是一個(gè)有意義的指標(biāo)。對(duì)于那些安裝量較高、但是安裝卸載比卻不高的應(yīng)用, 應(yīng)當(dāng)提出額外的關(guān)注。如上節(jié)中提到的A1, 其下載量較高, 但是安裝卸載比缺較低, 可以從一定程度上說明其存在問題。

6.4 異常流量

隱私信息的泄露最終需要通過網(wǎng)絡(luò)來進(jìn)行傳輸, 因此關(guān)注應(yīng)用的網(wǎng)絡(luò)連接情況, 對(duì)于幫助我們發(fā)現(xiàn)惡意軟件也有一定借鑒意義。Li等人[7]分析了百萬級(jí)用戶在26萬個(gè)Android 應(yīng)用上網(wǎng)絡(luò)使用數(shù)據(jù)(連接時(shí)長、流量消耗), 通過對(duì)相似功能的應(yīng)用進(jìn)行聚類和異常檢測之后, 可以觀察到有一些應(yīng)用產(chǎn)生的網(wǎng)絡(luò)行為數(shù)據(jù)和其自身功能存在較為明顯的差異。比如, 有一款手電筒類型的應(yīng)用, 其功能僅為簡單的通過手機(jī)閃光燈進(jìn)行照明(無論是該應(yīng)用自己的描述亦或是用戶對(duì)其的與其都僅此而已)。但是, 這個(gè)手電筒應(yīng)用卻保有很長的后臺(tái)聯(lián)網(wǎng)時(shí)間, 同時(shí)在后臺(tái)產(chǎn)生一定的網(wǎng)絡(luò)數(shù)據(jù)傳輸, 平均每天產(chǎn)生7MB的蜂窩數(shù)據(jù)流量和約5MB的Wi-Fi流量。對(duì)于聯(lián)網(wǎng)時(shí)間, 也許可歸結(jié)為操作系統(tǒng)在后臺(tái)進(jìn)程管理方面存在不足, 但是對(duì)于后臺(tái)流量消耗, 則可能是應(yīng)用本身的設(shè)計(jì)問題, 比如申請(qǐng)了不必要的聯(lián)網(wǎng)權(quán)限、使用了可能存在問題的第三方庫、或者是應(yīng)用本身的邏輯中存在Bug。這一現(xiàn)象很可能是由于惡意行為導(dǎo)致, 至少會(huì)導(dǎo)致用戶的隱私信息直接面臨威脅。類似應(yīng)用應(yīng)當(dāng)提醒我們的注意。

6.5 總結(jié)與展望

在傳統(tǒng)的PC情境下, 已有大量工作通過數(shù)據(jù)比較、數(shù)據(jù)分析、行為分析等方式對(duì)惡意應(yīng)用進(jìn)行鑒別。隨著智能手機(jī)用戶的使用數(shù)據(jù)的增多以及大數(shù)據(jù)技術(shù)的興起, 相關(guān)技術(shù)可以得到新的擴(kuò)展, 新的技術(shù)也有待繼續(xù)開發(fā), 以期從用戶的使用數(shù)據(jù)中發(fā)現(xiàn)可能的安全問題。

隨著智能手機(jī)用戶的使用數(shù)據(jù)的增多以及大數(shù)據(jù)技術(shù)的興起, 從用戶的使用數(shù)據(jù)中可以發(fā)現(xiàn)一些可能的安全問題。本章中介紹的方法僅為冰山一隅。在未來, 當(dāng)數(shù)據(jù)維度增多、規(guī)模增大、更高效準(zhǔn)確的算法被提出之后, 數(shù)據(jù)可以幫助我們發(fā)現(xiàn)更多的安全隱患。

7 小結(jié)

本文分別從用戶界面解析、重打包應(yīng)用檢測、應(yīng)用功能與安全行為一致性檢測、基于上下文的惡意行為檢測, 以及終端應(yīng)用管理和使用這五個(gè)部分介紹了移動(dòng)應(yīng)用安全解析學(xué)目前的成果。同時(shí), 基于以上的研究成果, 對(duì)未來的研究方向進(jìn)行了展望, 并分析了這些研究方向面臨的挑戰(zhàn)。

[1] A. Felt, M. Finifter, E. Chin, S. Hanna, and D. Wagner. "A survey of mobile malware in the wild,"in, 2011, pp. 3-14.

[2] A. Sinha, A. M. Paradkar, P. Kumanan, and B. Boguraev, "A linguistic analysis engine for natural language use case description and its application to dependability analysis in industrial use cases,” in, 2009, pp. 327–336.

[3] A. Sinha, S. M. SuttonJr., and A. Paradkar, “Text2Test: Automated inspection of natural language use cases,” in, 2010, pp. 155-164.

[4] B. K. Boguraev, “Towards finite-state analysis of lexical cohesion.” in, 2000.

[5] B. Liu, B. Liu, H. Jin, and R. View, “Efficient privilege de-escalation for ad libraries in mobile apps,” in, 2015, pp. 89-103.

[6] F. Zhang, H. Huang, S. Zhu, D. Wu, and P. Liu, “ViewDroid: towards obfuscation-resilient mobile application repackaging detection,” in, 2014, pp. 25-36.

[7] H.Li, X. Lu, X. Liu. “Characterizing Smartphone Usage Patterns from Millions of Android Users,” in2015, pp. 459-472.

[8] H.Li, W. Ai, X. Liu. “Voting with Their Feet: Inferring User Preferences from App Management Activities” in2016, pp. 1351-1361.

[9] H. Wang, Y. Guo, Z. Ma and X. Chen, “WuKong: A Scalable and Accurate Two-Phase Approach to Android App Clone Detection," in2015, pp. 71-82.

[10] J. Crussell, R. Stevens, H. Chen, “MAdFraud: Investigating ad fraud in Android applications,” in, 2014, pp. 123-134.

[11] J. Crussell, C. Gibler, and H. Chen, “Attack of the clones: detecting cloned applications on Android markets,” in, 2012, pp. 37-54.

[12] J. Crussell, C. Gibler, and H. Chen, “Scalable semantics-based detection of similar Android applications,” in, 2013, pp. 182-199.

[13] J. Huang, Z. Li, X. Xiao, Z. Wu, K. Lu, X. Zhang, and G. Jiang, “SUPOR: Precise and scalable sensitive user input detection for Android apps,” in2015, pp. 977-992.

[14] K. Chen, P. Liu, and Y. Zhang, “Achieving accuracy and scalability simultaneously in detecting application clones on Android markets,”in, 2014, pp. 175-186.

[15] N. Viennot, E. Garcia, and J. Nieh, “A measurement study of Google Play,” in, 2014, pp. 221-233.

[16] R. Pandita, X. Xiao, H. Zhong, T. Xie, S. Oney, and A. Paradkar, “Inferring method specifications from natural language API descriptions,” in, 2012, pp. 815-825.

[17] R. Pandita, X. Xiao, W. Yang, W. Enck, and T. Xie, “WHYPER: Towards automating risk assessment of mobile applications,”in2013, pp. 527-542.

[18] S. Hanna, L. Huang, E. Wu, S. Li, C. Chen, and D. Song, “Juxtapp: A scalable system for detecting code reuse among Android applications,” in, 2012, pp. 62-81.

[19] W. Yang, M. R. Prasad, and T. Xie, “A grey-box approach for automated GUI-model generation of mobile applications,” In, 2013, pp. 250-265.

[20] W. Yang, X. Xiao, B. Andow, S. Li, T. Xie, & W. Enck, “AppCsontext: Differentiating malicious and benign mobile app behaviors using context,” In2015, pp. 303-313

[21] W. Zhou, Y. Zhou, X. Jiang, and P. Ning, “Detecting repackaged smartphone applications in third-party Android marketplaces,” in, 2012, pp. 317-326.

[22] W. Zhou, Y. Zhou, M. Grace, X. Jiang, and S. Zou, “Fast, scalable detection of piggybacked mobile applications,” in, 2013, pp. 185-196.

[23] Y. Yuan and Y. Guo, “CMCD: count matrix based code clone detection,” in, 2011, pp. 250-257.

[24] Y. Yuan and Y. Guo, “Boreas: an accurate and scalable token-based approach to code clone detection,” in2012, pp. 286-289.

[25] Y. Nan, M. Yang, Z. Yang, S. Zhou, G. Gu, and X. Wang, “UIPicker: User-input privacy identification in mobile applications,” in2015, pp. 993-1008.

[26] Y. Zhauniarovich, O. Gadyatskaya, B. Crispo, F. La Spina, and E. Moser, “FSquaDRA: fast detection of repackaged applications,”2014, pp. 130-145.

[27] Y. Zhou, Z. Wang, W. Zhou, and X. Jiang. "Hey, you, get off of my market: Detecting malicious apps in official and alternative android markets," in, 2012.

[28] Z. Qu, V. Rastogi, X. Zhang, Y. Chen, T. Zhu, and Z. Chen. "AutoCog: Measuring the description-to-permission fidelity in Android applications,"2014, pp. 1354-1365.

[29] B.J. Kwon, J. Mondal, J. Jang, L. Bilge, and T. Dumitras. "The dropper effect: Insights into malware distribution with downloader graph analytics." In. 2015, pp. 1118-1129.

楊威 于2013年在美國北卡羅萊納州立大學(xué)計(jì)算機(jī)科學(xué)專業(yè)獲得碩士學(xué)位?，F(xiàn)在伊利諾伊大學(xué)香檳分校計(jì)算機(jī)專業(yè)攻讀計(jì)算機(jī)科學(xué)學(xué)位博士。研究領(lǐng)域?yàn)檐浖こ膛c安全。研究興趣包括: 軟件安全, 程序分析,自動(dòng)化測。Email: weiyang3@illinois.edu肖旭生 于2014年在美國北卡羅萊納州立大學(xué)計(jì)算機(jī)科學(xué)專業(yè)獲得博士學(xué)位?，F(xiàn)任NEC美國研究所研究員。研究領(lǐng)域?yàn)槠髽I(yè)安全智能系統(tǒng)和移動(dòng)安全管理。研究興趣包括: 軟件測試, 程序分析, 移動(dòng)安全, 系統(tǒng)和企業(yè)安全。Email: xsxiao@nec-labs.com 李鄧鋒 于2015年在美國賓夕法尼亞州立大學(xué)獲得電子工程和計(jì)算機(jī)科學(xué)雙學(xué)位?，F(xiàn)在伊利諾伊大學(xué)香檳分校計(jì)算機(jī)專業(yè)攻讀計(jì)算機(jī)科學(xué)碩士學(xué)位。研究領(lǐng)域?yàn)檐浖こ膛c安全。Email: dli46@illinois.edu李豁然 現(xiàn)在是北京大學(xué)信息科學(xué)技術(shù)學(xué)院的博士研究生。他的研究興趣包括移動(dòng)計(jì)算、軟件工程、數(shù)據(jù)分析及人機(jī)交互。Email:lihuoran@pku.edu.cn 劉譞哲 北京大學(xué)信息科學(xué)技術(shù)學(xué)院副教。研究興趣包括移動(dòng)計(jì)算, 網(wǎng)頁系統(tǒng), 和程序分析。Email: liuxuanzhe@pku.edu.cn王浩宇 于2011年進(jìn)入北京大學(xué)信息科學(xué)技術(shù)學(xué)院攻讀博士學(xué)位, 現(xiàn)在是博士五年級(jí)。研究領(lǐng)域?yàn)橐苿?dòng)計(jì)算, 系統(tǒng)軟件。研究興趣包括: 移動(dòng)系統(tǒng)中的安全與隱私, 移動(dòng)應(yīng)用分析技術(shù)。Email: howiepku@pku.edu.cn 郭耀 北京大學(xué)信息科學(xué)技術(shù)學(xué)院副教授, 美國馬薩諸塞大學(xué)計(jì)算機(jī)工程博士, 中國計(jì)算機(jī)學(xué)會(huì)高級(jí)會(huì)員, ACM和IEEE會(huì)員。主要研究方向?yàn)椴僮飨到y(tǒng)、低功耗設(shè)計(jì)、軟件工程等。Email: yaoguo@pku.edu.cn謝濤 美國伊利諾伊大學(xué)香檳分校(UIUC)計(jì)算機(jī)科學(xué)系副教授和Willett Faculty Scholar, 美國西雅圖華盛頓大學(xué)博士, ACM杰出科學(xué)家和IEEE高級(jí)會(huì)員。主要研究方向?yàn)檐浖こ?、軟件測試和分析、軟件解析學(xué)等。Email:taoxie@illinois.edu

Security Analytics for Mobile Apps: Achievements and Challenges

YANG Wei1, XIAO Xusheng2, LI Dengfeng1, LI Huoran3, LIU Xuanzhe3, WANG Haoyu3, GUO Yao3, XIE Tao1

1Department of Computer Science, University of Illinois at Urbana–Champaign, Urbana, 61801, USA2NEC Laboratories America, Princeton, 08540, USA3School of Electronics Engineering and Computer Science, Peking University, Beijing 100871, China

With the increasing popularity of mobile apps, security incidents of mobile apps frequently occur. Accurately identifying security threats among billions of mobile apps has become an important and difficult topic in information security. In the meantime, the increasing number of mobile apps leads to a massive amount of mobile security data, which enables security analytics for mobile apps. In this article, we illustrate recent research achievements on mobile security analytics from five different perspectives: User Interface (UI) analytics, identification of repackage apps, consistency checking between apps functionality and security behaviors, context-sensitive detection of malicious behaviors, and client app management/usage. We also discuss future directions on security analytics for mobile apps, along with challenges in these directions.

mobile security; data analytics; machine learning; program analysis

TP309.1

1:劉譞哲, 博士, 北京大學(xué)信息科學(xué)技術(shù)學(xué)院副教授, Email: liuxuanzhe@pku.edu.cn。通訊作者2:郭耀, 博士，北京大學(xué)信息科學(xué)技術(shù)學(xué)院副教授，Email: yaoguo@pku.edu.cn。

本文工作得到國家科技部863計(jì)劃項(xiàng)目(2015AA01A202)、國家自然科學(xué)基金委創(chuàng)新群體項(xiàng)目(61421091)、海外合作基金項(xiàng)目(61529201)和國家自然科學(xué)基金青年-面上連續(xù)資助項(xiàng)目(61370020)、美國自然科學(xué)基金(CNS-1513939)、谷歌教授研究獎(jiǎng)的資助。

2016-3-8; 修改日期: 2016-4-26; 定稿日期: 2016-5-1

DOI號(hào) 10.19363/j.cnki.cn10-1380/tn.2016.02.001