秦佳偉，張華，嚴(yán)寒冰，何能強(qiáng)，涂騰飛

（1.北京郵電大學(xué)網(wǎng)絡(luò)與交換技術(shù)國(guó)家重點(diǎn)實(shí)驗(yàn)室，北京 100876；2.國(guó)家計(jì)算機(jī)網(wǎng)絡(luò)應(yīng)急技術(shù)處理協(xié)調(diào)中心，北京 100029）

1 引言

近幾年，安卓應(yīng)用一直在快速增長(zhǎng)中，但是隨之增長(zhǎng)的還有應(yīng)用所產(chǎn)生的漏洞。2020 年，國(guó)家信息安全漏洞共享平臺(tái)（CNVD,China National Vulnerability Database）收錄安全漏洞中移動(dòng)互聯(lián)網(wǎng)漏洞占全年收錄數(shù)量的8.0%。因?yàn)樗械能浖┒炊即嬖诒还粽邼撛诶玫目赡躘1-3]，所以發(fā)現(xiàn)漏洞并修復(fù)它，才是避免軟件遭受攻擊的有效方法。2018 年，PIAnalyzer[4]分析并提取了PendingIntent權(quán)限繞過(guò)漏洞的規(guī)則，基于靜態(tài)檢測(cè)的方法實(shí)現(xiàn)對(duì)改漏洞的檢測(cè)。目前，與Intent 機(jī)制相關(guān)的研究[5-12]主要關(guān)注APP 隱私泄露問(wèn)題。過(guò)辰楷等[5]提出了一種基于安全要素語(yǔ)句插裝的泄露檢測(cè)方法。AmanDroid[7]通過(guò)跟蹤APP 組件間的交互信息來(lái)識(shí)別隱私泄露問(wèn)題。

另外，為了降低人工依賴和提高對(duì)未知漏洞的發(fā)現(xiàn)能力，基于學(xué)習(xí)的漏洞檢測(cè)成為技術(shù)發(fā)展趨勢(shì)之一[13-25]?；趯W(xué)習(xí)的漏洞檢測(cè)研究主要集中在Java 語(yǔ)言的漏洞方面。早期的基于學(xué)習(xí)的Java 源代碼漏洞檢測(cè)研究[21,24]解決了基于規(guī)則的漏洞檢測(cè)方法依賴人工經(jīng)驗(yàn)的問(wèn)題，但是漏洞代碼的抽象表示缺乏語(yǔ)義特征，從而影響漏洞識(shí)別的準(zhǔn)確率。2017 年，Ma 等[22]提出將Java 代碼轉(zhuǎn)換成抽象語(yǔ)法樹(shù)（AST,abstract syntax tree）的特征，然后采用機(jī)器學(xué)習(xí)模型來(lái)對(duì)Java 程序進(jìn)行漏洞檢測(cè)。AST 特征可以保留程序?qū)ο笾g的語(yǔ)義信息，但是包含與漏洞代碼無(wú)關(guān)的噪聲數(shù)據(jù)會(huì)導(dǎo)致誤報(bào)[26-28]。Java 程序不具有APP 的生命周期特性和組件間通信機(jī)制（ICC,inter-component communication），所以無(wú)法適用于檢測(cè)無(wú)源碼的APP 的漏洞。2018 年，王持恒等[13]依據(jù)APP 的流量數(shù)據(jù)和權(quán)限列表信息采用聚類方法檢測(cè)廣告漏洞，但是該方法僅適用于廣告漏洞檢測(cè)場(chǎng)景。2021 年，Gencer 等[29]研究直接依賴于時(shí)間的APP 漏洞，并采用時(shí)間序列、多層感知器等多種模型生成了漏洞預(yù)警模型。

基于學(xué)習(xí)的APP 漏洞檢測(cè)缺少針對(duì)安卓本身運(yùn)行機(jī)制所導(dǎo)致的漏洞的研究。現(xiàn)有的2 種特征提取方法會(huì)導(dǎo)致漏洞檢測(cè)的準(zhǔn)確率下降。其中，基于代碼中關(guān)鍵字符串計(jì)數(shù)的特征方法無(wú)法表現(xiàn)語(yǔ)義信息，也無(wú)法體現(xiàn)漏洞的上下文關(guān)聯(lián)信息；AST 的漏洞提取方法會(huì)存在誤報(bào)[26-28]。在針對(duì)其他編程語(yǔ)言的程序漏洞檢測(cè)方面[15-16,19-20,30]，2019 年，Zou 等[15]針對(duì)C 語(yǔ)言的程序漏洞提出一種名為code gadgets的程序特征表示方法，由此設(shè)計(jì)并實(shí)現(xiàn)了基于深度學(xué)習(xí)的漏洞檢測(cè)系統(tǒng)。因?yàn)镃 語(yǔ)言的程序分析不涉及對(duì)回調(diào)方法的處理，所以該方法無(wú)法直接適用于APP 漏洞檢測(cè)。安卓APP 不僅有Java 語(yǔ)言的漏洞，還有不正確地使用平臺(tái)的應(yīng)用程序接口（API,application program interface）所導(dǎo)致的漏洞，危害更嚴(yán)重。例如，安卓ICC 不僅允許同一個(gè)APP 的不同組件間進(jìn)行數(shù)據(jù)傳遞，而且允許不同的APP 之間的數(shù)據(jù)傳遞。這就給APP 帶來(lái)了安全風(fēng)險(xiǎn)——使用該機(jī)制實(shí)現(xiàn)的功能的各個(gè)對(duì)象的屬性設(shè)置都可能導(dǎo)致漏洞。因此不能通過(guò)Java 代碼的規(guī)則匹配檢測(cè)相關(guān)漏洞。

要實(shí)現(xiàn)針對(duì)安卓本身運(yùn)行機(jī)制的漏洞檢測(cè)，且克服人工提取特征的局限性，需要解決以下3 個(gè)問(wèn)題。1) 目前缺少可供深度學(xué)習(xí)使用的APP 漏洞數(shù)據(jù)集，如何獲取一批可用的數(shù)據(jù)集？2) 面對(duì)安卓應(yīng)用特有的ICC 方式和無(wú)主程序入口的運(yùn)行啟動(dòng)方式，如何進(jìn)行程序分析和漏洞特征提??？3) APP 漏洞特征表示方法方面，如何在不缺少關(guān)鍵信息的情況下對(duì)程序進(jìn)行語(yǔ)義化的特征抽象？

為了克服上述挑戰(zhàn)，本文以隱式Intent 通信漏洞（IISV,implicit Intent security vulnerability）和PendingIntent 權(quán)限繞過(guò)漏洞（BPPAV,bypass PendingIntent permission audit vulnerability）為研究對(duì)象，針對(duì)安卓運(yùn)行機(jī)制導(dǎo)致的漏洞檢測(cè)提出了一種上下文感知的安卓應(yīng)用程序漏洞檢測(cè)方法。該方法可以從APP 中提取出只與漏洞相關(guān)的代碼信息，并且將特征代碼中的自定義函數(shù)名與變量名進(jìn)行統(tǒng)一格式化處理，既保留語(yǔ)義邏輯性也具有可讀性。本文主要貢獻(xiàn)如下。

1) 本文從GooglePlay 獲取了5 000 個(gè)樣本，采用工具和人工分析的方法對(duì)其進(jìn)行漏洞標(biāo)記，得到包含IIS 的漏洞樣本1 806 個(gè)和包含PLP 的漏洞樣本95 個(gè)，提取41 812 條特征代碼段。經(jīng)特征化處理后，本文數(shù)據(jù)集與APP 無(wú)直接關(guān)聯(lián)關(guān)系，但是因?yàn)槁┒葱畔⒌拿舾行?，該?shù)據(jù)集僅通過(guò)郵件提供。

2) 在APP 漏洞特征表示上，本文提出一種包含語(yǔ)義信息的特征抽象方法——CIS。該方法可以保留程序的執(zhí)行流程的結(jié)構(gòu)信息，從APP 中提取只與漏洞相關(guān)的代碼信息，并且將特征代碼中的自定義函數(shù)名與變量名進(jìn)行統(tǒng)一格式化處理，既保留語(yǔ)義邏輯性也具有可讀性。針對(duì)APP 沒(méi)有明確的唯一主函數(shù)入口的情況，本文給出了9 個(gè)入口點(diǎn)，可以更全面地構(gòu)建APP 內(nèi)部代碼邏輯與數(shù)據(jù)關(guān)系。

3) 基于CIS 方法，本文選取Bi-LSTM 算法構(gòu)建了一個(gè)針對(duì) APP 漏洞的深度學(xué)習(xí)檢測(cè)模型VulDGArcher，針對(duì)本文分析的2 種漏洞，其識(shí)別準(zhǔn)確率達(dá)到了96%。

2 代碼語(yǔ)義特征化

漏洞代碼特征化應(yīng)最大化保留語(yǔ)意信息和影響漏洞形成的因素。本文提出了一種特征抽象方法CIS，利用APP 漏洞點(diǎn)的上下文信息，提取與漏洞點(diǎn)有關(guān)的語(yǔ)義信息，減少無(wú)關(guān)變量和函數(shù)信息。

2.1 漏洞語(yǔ)義特征

APP 源碼中包含很多邏輯處理流程，一個(gè)功能的實(shí)現(xiàn)需要用到其他的變量或者方法。在對(duì)某一種漏洞分析時(shí)，本文只關(guān)注和這個(gè)漏洞觸發(fā)點(diǎn)相關(guān)的變量和方法，其他代碼在這種場(chǎng)景下都是噪聲。

以IIS 為例，代碼1 是一個(gè)APP（MD5 是51da27661a8eff2f0cb37b7756e576b3）中使用隱式Intent 的方法實(shí)現(xiàn)發(fā)送郵件的功能函數(shù)，第11)行～第15)行實(shí)現(xiàn)了一個(gè)隱式Intent 對(duì)象，該對(duì)象中加入了過(guò)濾條件Intent.ACTION_SENDTO，同時(shí)該對(duì)象中包含了全部郵件內(nèi)容。該APP 并沒(méi)有設(shè)定發(fā)送郵件的APP，也沒(méi)有強(qiáng)制設(shè)置用戶選擇所有可以響應(yīng)該Intent 的應(yīng)用程序，這種現(xiàn)象就會(huì)導(dǎo)致該APP 存在IIS。

代碼1IIS 的示例代碼

綜上，IIS 風(fēng)險(xiǎn)與Intent 的使用有關(guān)。所以從APP 的源代碼角度分析，該風(fēng)險(xiǎn)應(yīng)主要關(guān)注Intent的對(duì)象及其用到的方法。如代碼1 所示，影響該漏洞的代碼只有第12)行～第18)行，其他是噪聲數(shù)據(jù)。

代碼2 是某個(gè)Android 系統(tǒng)中“設(shè)置”APP（CVE-2014-8609）使用PendingIntent 方法實(shí)現(xiàn)添加用戶功能。在第3)行中，一個(gè)PendingIntent 對(duì)象mPendingIntent 被創(chuàng)建，并帶有一個(gè)空的Intent 對(duì)象。因?yàn)槭窍到y(tǒng)內(nèi)置APP，所以mPendingIntent 對(duì)象具有系統(tǒng)權(quán)限。當(dāng)惡意 APP 注冊(cè)接收該mPendingIntent 對(duì)象時(shí)，因?yàn)閙PendingIntent 注冊(cè)的Intent 是空的，所以惡意APP 可以修改Intent 對(duì)象中的Action 和Extra data 屬性，再以具有系統(tǒng)權(quán)限的mPendingIntent 對(duì)象發(fā)送出去，以此達(dá)到權(quán)限繞過(guò)目的。

代碼2PLP 的示例代碼

綜上分析，PLP 與PendingIntent 和Intent 的使用都有關(guān)，所以代碼2 中影響該漏洞的代碼只有第3)行和第4)行。

特征化方法既要將漏洞相關(guān)代碼表示出來(lái)，又要保留代碼之間的語(yǔ)義信息的特征化方法。本文針對(duì)這一需求定義了一種特征化代碼的方式CIS，如式(1)所示。它是由全部影響漏洞存在的相關(guān)變量的上下文內(nèi)容Ci組成的，也是由疑似漏洞點(diǎn)的直接或間接相關(guān)的所有代碼組成的調(diào)用序列。

如式(2)所示，Ci是一個(gè)有向圖，由一個(gè)相關(guān)變量i的前向關(guān)系語(yǔ)句和后向關(guān)聯(lián)的語(yǔ)句組成；vi是第i個(gè)變量的關(guān)系圖中的某個(gè)調(diào)用語(yǔ)句。當(dāng)同一個(gè)變量的數(shù)據(jù)從vik傳遞到viw時(shí)，這2 個(gè)點(diǎn)之間存在邊eikw。

代碼3 是代碼1 進(jìn)行CIS 處理后的結(jié)果。第1)行表示聲明了一個(gè)Intent 對(duì)象且該對(duì)象的臨時(shí)編號(hào)是10；第2)行表示對(duì)編號(hào)為10 的這個(gè)Intent 對(duì)象進(jìn)行了初始化操作且初始化傳遞的參數(shù)是String 類型；第3)行～第7)行依次表示編號(hào)為10 的這個(gè)Intent 對(duì)象進(jìn)行設(shè)置屬性等操作；第8)行表示Intent對(duì)象被發(fā)送。

代碼3IIS 的CIS 示例代碼

以上結(jié)果顯示CIS 既包含Intent 相關(guān)的代碼也保證了語(yǔ)句的原本調(diào)用序列。CIS 在包含疑似漏洞點(diǎn)的所有相關(guān)對(duì)象和語(yǔ)句的同時(shí)，去掉了與它無(wú)關(guān)的代碼信息，順序性保留了邏輯上的語(yǔ)義信息。

2.2 構(gòu)建CIS

從一個(gè)APP 文件構(gòu)建關(guān)于一個(gè)疑似漏洞點(diǎn)的CIS 的流程如圖1 所示。

1) 反編譯

本文對(duì)APP 進(jìn)行漏洞分析的目標(biāo)是APK文件，包含編譯好的可執(zhí)行文件。為了對(duì)源代碼進(jìn)行漏洞分析，本文基于WALA 實(shí)現(xiàn)了對(duì)APK 文件的反編譯操作，從而獲取到了APP 的Smali 形式的代碼。

2) 構(gòu)建控制流圖

本文定義了如表1 所示的入口點(diǎn)，并以此為基礎(chǔ)為安卓APP 構(gòu)建必要的控制流圖（CFG,control flow graph），如式(3)所示。

表1 定義的入口點(diǎn)

其中，N是全部節(jié)點(diǎn)集；程序中的每個(gè)語(yǔ)句都對(duì)應(yīng)圖中的一個(gè)節(jié)點(diǎn)nk，當(dāng)nk存在調(diào)用nw的關(guān)系時(shí)，兩者之前存在一條從nk指向nw的邊ekw；nentry 和nexit 分別為程序的入口和出口節(jié)點(diǎn)。經(jīng)過(guò)分析安卓的4 種組件的啟動(dòng)入口點(diǎn)和中間狀態(tài)的轉(zhuǎn)換關(guān)系以及安卓的UI 反射入口等特性。

3) 構(gòu)建程序依賴圖

程序依賴圖（PDG,program dependency graph）是程序的一種圖形表示，是帶有標(biāo)記的有向多重圖，如式(4)所示。構(gòu)建方法是以程序的CFG 為基礎(chǔ)，去掉CFG 的控制流邊，加入數(shù)據(jù)和控制流邊。因此PDG 包括了數(shù)據(jù)依賴圖和程序依賴圖，數(shù)據(jù)依賴圖定義了數(shù)據(jù)之間的約束關(guān)系，控制依賴圖定義了語(yǔ)句執(zhí)行情況的約束關(guān)系。PDG 全部節(jié)點(diǎn)集合為V'，其中任意一個(gè)節(jié)點(diǎn)sk表示語(yǔ)句或控制謂詞表達(dá)式，邊E'表示程序組成部分之間的依賴關(guān)系，包括控制依賴和數(shù)據(jù)依賴。如果PDG 中的語(yǔ)句sk和sw可以通過(guò)控制流或者數(shù)據(jù)流來(lái)彼此關(guān)聯(lián)，則兩點(diǎn)之前存在一條邊。因?yàn)镻DG 既包含程序中語(yǔ)句之間的數(shù)據(jù)依賴關(guān)系，又包含控制依賴關(guān)系，所以可減少漏洞信息搜索空間。

4) 構(gòu)建CIS

本文按照算法1 所描述的過(guò)程，選取一個(gè)疑似存在漏洞的風(fēng)險(xiǎn)點(diǎn)。如圖1 所示，IIS 漏洞的疑似漏洞點(diǎn)是Intent 。本文首先提取疑似漏洞點(diǎn)的前向切片和后向切片；然后選取其中的配置方法，如put Extra 等；最后對(duì)這類方法中的對(duì)象再次進(jìn)行前向切片和后向切片提取。所有提取的中間切片結(jié)果使用Construct Tree 存儲(chǔ)在樹(shù)結(jié)構(gòu)中。因?yàn)楸疚淖罱K得到的代碼抽象結(jié)果要保持相對(duì)的邏輯順序性，本文將使用Search Tree 方法前序遍歷讀取樹(shù)結(jié)構(gòu)中的結(jié)果，并將所有結(jié)果匯總到一起形成這個(gè)疑似漏洞點(diǎn)的代碼抽象形式CIS'。

算法1基于疑似漏洞點(diǎn)構(gòu)建代碼抽象表示CIS'

輸入存儲(chǔ)切片代碼tree Node，一個(gè)疑似漏洞點(diǎn)inp，APP 的程序依賴圖PDG

輸出疑似漏洞點(diǎn)的代碼抽象表達(dá)式CIS'

CIS'包含自定義的變量名和API 等噪聲數(shù)據(jù)，因此本節(jié)進(jìn)一步優(yōu)化數(shù)據(jù)特征以便模型更好地識(shí)別漏洞，優(yōu)化過(guò)程如算法2 所示。

算法2對(duì)CIS'進(jìn)行數(shù)據(jù)歸一化處理

輸入初步提取的所有疑似漏洞點(diǎn)的抽象代碼特征CIS's

輸出最終的代碼特征CIS

①?gòu)腁PP 提出來(lái)的CIS'中包含了方法的異常處理信息，這些信息不會(huì)影響漏洞是否存在，但是會(huì)降低模型檢測(cè)漏洞的準(zhǔn)確率。經(jīng)分析，這部分信息是在符號(hào)@后的字符。所以先獲取@在CIS'中的位置Index，移除掉Index 后面的表示異常處理的字符串，得到新的CIS'。

②CIS'包含開(kāi)發(fā)者自定義的變量信息。因?yàn)槊總€(gè)開(kāi)發(fā)者自定義的變量命名不同，所以自定義變量就是噪聲數(shù)據(jù)，會(huì)影響模型對(duì)漏洞的識(shí)別。本文將自定義方法進(jìn)行統(tǒng)一的重新定義，計(jì)算出CIS'中每個(gè)自定義的變量vari，然后按照先后順序i對(duì)其進(jìn)行替換變成統(tǒng)一的命名VERi，這樣CIS'中不同的自定義的變量只是編號(hào)不同，其他的都是用統(tǒng)一的VER 字符串表示。利用同樣的方法，依次將自定義的方法名變成FUNi，自定義的類名變成CLASSi。不同的類、方法和變量將按照后邊的序號(hào)i進(jìn)行區(qū)分，相同的類、方法和變量在不同位置命名保持一致。

③代碼特征化的結(jié)果中，系統(tǒng)API 的方法都是展示的完整的全限定位名，如Java/lang/String，也就是包含了類所在的包名。因?yàn)锳PI 的類名就可以表現(xiàn)出該API 的行為和意義，包名對(duì)于漏洞的識(shí)別是無(wú)意義的變量信息。盡管存在少量的API 具有同樣的類名，但是存在于不同的包名下，這些少量的API 主要是監(jiān)聽(tīng)類，并沒(méi)有實(shí)際的行為意義，即不會(huì)影響漏洞的存在。所以計(jì)算出CIS'中的每個(gè)以上類別的系統(tǒng)API（apii），去掉所有的包名只保留類名。例如，Java/lang/String 簡(jiǎn)化后為String。

④對(duì)于上述幾步的處理優(yōu)化后，本文對(duì)同對(duì)象的調(diào)用方法進(jìn)行再一次的組合，最大限度地還原APP 的原本語(yǔ)句表達(dá)形式。最后得到含有最小噪聲數(shù)據(jù)的代碼特征值即CIS。

3 基于語(yǔ)義代碼片段的漏洞識(shí)別模型

本文基于CIS 采用Bi-LSTM 算法構(gòu)建了一個(gè)保留語(yǔ)意信息的APP 漏洞檢測(cè)模型VulDG Archer，圖2 為其訓(xùn)練過(guò)程。采用深度學(xué)習(xí)模型可以解決人工提取漏洞規(guī)則的漏報(bào)問(wèn)題，并能克服依賴專家經(jīng)驗(yàn)對(duì)新漏洞識(shí)別的局限性。

1) 構(gòu)建CIS

構(gòu)建CIS 的過(guò)程如算法3 所示。

算法3構(gòu)建APP 的CIS

輸入待分析的安卓應(yīng)用APP，所有的入口函數(shù)EPs，疑似漏洞點(diǎn)集合inps

輸出漏洞特征CISs

21) end for

22) 按照上述過(guò)程構(gòu)建PDG

23) 按照算法1 構(gòu)建一個(gè)疑似漏洞點(diǎn)inp 的CISs

①本文基于WALA 對(duì)APP 逆向處理得到smali 格式的代碼?；谒械娜肟邳c(diǎn)EBs 處理得到APP 的代碼塊集合EntryBs。

② 從集合EntryBs 中取出任意2 個(gè)不同的代碼塊ebi和ebj，如果從ebi的最后一個(gè)語(yǔ)句到ebj的前項(xiàng)存在條件分支或無(wú)條件分支，或者如果ebj以程序順序緊隨ebi且ebi不以無(wú)條件分支結(jié)束，則在ebi的基本塊中添加一個(gè)有向邊eij指向ebj。依次對(duì)所有的代碼塊進(jìn)行同樣的操作，就構(gòu)建了APP 的CFG。

③CFG 只能呈現(xiàn)APP 的不同塊之間的調(diào)用關(guān)系，為了分析具體APP 內(nèi)部的數(shù)據(jù)傳遞過(guò)程，還要進(jìn)一步得到APP 的數(shù)據(jù)傳遞情況?；贑FG 計(jì)算所有偏序PO 和所有的控制依賴關(guān)系CD。針對(duì)CD中的每一個(gè)偏序關(guān)系bbi→bbj，對(duì)于bbj中的每一個(gè)語(yǔ)句表達(dá)式vjk，都存在一條從bbi指向vjk的邊eijk。這樣就會(huì)得到語(yǔ)句之間的控制關(guān)系。對(duì)于任意2 個(gè)存在數(shù)據(jù)依賴關(guān)系的語(yǔ)句u與v，如果其所在的偏序關(guān)系為bb(u)

④ 基于PDG，本文使用算法1 對(duì)所有的疑似漏洞點(diǎn)構(gòu)建對(duì)應(yīng)的代碼特征CIS。這樣得到的是關(guān)于每一個(gè)疑似漏洞點(diǎn)的包含語(yǔ)義的代碼特征，其中還記錄了這個(gè)疑似漏洞點(diǎn)所在的類名和方法名。

2) 數(shù)據(jù)集標(biāo)注

CIS 的抽象特征沒(méi)有包含它是否存在漏洞的標(biāo)簽，這一步將提取的代碼特征進(jìn)行漏洞打標(biāo)簽。

①本文將APP 文件中的疑似漏洞點(diǎn)所在的函數(shù)使用MobSF（mobile security framework）進(jìn)行漏洞識(shí)別，對(duì)于識(shí)別出來(lái)的漏洞信息，本文再一次進(jìn)行人工校驗(yàn)，最終整理出每個(gè)APP 的漏洞信息。漏洞信息包含包名（pj）、類名（cj）、方法名（mj）和漏洞類型（vjq），如式(5)所示。

② CIS 中的一個(gè)疑似漏洞點(diǎn)ipj如式(6)所示，其中表示包名，表示類名，表示方法名。

3) 訓(xùn)練模型

經(jīng)過(guò)上述階段后的代碼特征仍然是字符串的形式，這種格式的特征模型是無(wú)法直接識(shí)別的，所以也就無(wú)法將它當(dāng)作輸入變量。本文通過(guò)算法4 將其轉(zhuǎn)換成模型可接收的向量，具體過(guò)程如下。

算法4訓(xùn)練模型算法

輸入所有漏洞特征CISs，模型定義的向量長(zhǎng)度閾值w

輸出訓(xùn)練好的模型model

①本文使用word2vector 對(duì)字符串形式的代碼特征CIS 進(jìn)行向量化處理，得到模型可使用的詞向量binData。因?yàn)橛?xùn)練數(shù)據(jù)需要保證統(tǒng)一的長(zhǎng)度，所以應(yīng)對(duì)binData 進(jìn)行歸一化處理。如果bin Data 長(zhǎng)度小于規(guī)定的閾值w（本文w=200），在bin Data 后進(jìn)行補(bǔ)0 操作；如果bin Data 長(zhǎng)度大于閾值w，從后邊進(jìn)行截?cái)嗖僮鳌Ｗ詈蠼y(tǒng)一存在訓(xùn)練數(shù)據(jù)集train Data 中。

② APP 的漏洞代碼特征是基于數(shù)據(jù)流和控制流構(gòu)建的，其中包含了疑似漏洞點(diǎn)的上下文相關(guān)調(diào)用邏輯代碼。深度學(xué)習(xí)算法應(yīng)能夠?qū)W習(xí)到漏洞代碼塊的調(diào)用邏輯。其次，APP 是否存在漏洞受疑似漏洞點(diǎn)的前向代碼和后向代碼的影響。因此選擇的深度學(xué)習(xí)網(wǎng)絡(luò)應(yīng)當(dāng)滿足如下特點(diǎn)：具有記憶性可以獲取上下文關(guān)系；支持長(zhǎng)句子，即長(zhǎng)代碼塊；前向語(yǔ)句和后向語(yǔ)句的影響都能覆蓋。技術(shù)成熟的深度學(xué)習(xí)網(wǎng)絡(luò)中，Bi-LSTM 網(wǎng)絡(luò)同時(shí)支持以上3 個(gè)特性，可以作為APP 漏洞檢測(cè)的深度學(xué)習(xí)網(wǎng)絡(luò)。

由于漏洞代碼特征CIS 都是較長(zhǎng)的語(yǔ)句，為了學(xué)習(xí)長(zhǎng)句子的語(yǔ)義信息，本文選取的Bi-LSTM 模型中加入注意力機(jī)制，訓(xùn)練后得到漏洞識(shí)別模型。

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

本文用實(shí)驗(yàn)回答以下3 個(gè)研究問(wèn)題。

RQ1：CIS 能否識(shí)別出APP 的多種漏洞？

RQ2：與現(xiàn)有的APP 漏洞檢測(cè)方法相比，VulDGArcher 的效果如何？

RQ3：VulDGArcher 的效率如何，是否具有實(shí)用性？

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

因?yàn)橄嚓P(guān)的研究成果還沒(méi)有開(kāi)放出可用的安卓漏洞樣本數(shù)據(jù)集，所以本文從Google Play 獲取了5 000 個(gè)APP 樣本，先用安卓漏洞檢測(cè)工具M(jìn)obSF 識(shí)別出APP 的疑似漏洞點(diǎn)和初步的漏洞標(biāo)記，再對(duì)檢測(cè)后的APP 進(jìn)行人工的源碼分析，分析應(yīng)用程序中的疑似漏洞點(diǎn)上下文的數(shù)據(jù)流，標(biāo)定出的所有APP 中存在IIS 或PLP 的樣本數(shù)量如表2 所示。表2 中的安全是指APP 使用對(duì)應(yīng)的API 操作且安全的樣本。因?yàn)榇嬖谕粋€(gè)APP 同時(shí)存在IIS 和PLP 這2 種漏洞，所以在數(shù)據(jù)統(tǒng)計(jì)時(shí)沒(méi)有去重。

表2 數(shù)據(jù)集中存在不同的漏洞APP 數(shù)量

對(duì)APP 進(jìn)行CIS 代碼特征化處理后，現(xiàn)有APP樣本中，屬于某種漏洞的CIS 特征條數(shù)如表3 所示。為了對(duì)比實(shí)驗(yàn)，本文統(tǒng)計(jì)了現(xiàn)有APP 中存在漏洞的原始代碼文件（.class）的數(shù)量，如表4 所示。因?yàn)橥瑯右粋€(gè)源代碼文件（.class）可能存在多個(gè)同類別的漏洞且表4 中記錄的是原始代碼的文件數(shù)（.class文件數(shù)），所以各種漏洞的數(shù)量和表3 所展示的特征化后的結(jié)果不一樣。

表3 數(shù)據(jù)集中存在不同的漏洞CIS 數(shù)量

表4 數(shù)據(jù)集中疑似漏洞點(diǎn)原始代碼段數(shù)量

4.2 評(píng)價(jià)指標(biāo)

實(shí)驗(yàn)環(huán)境為一臺(tái)64 GB RAM，3 TB SSD，Intel Intel Xeon CPU E5-2640 v2 2.00 GHz 服務(wù)器。

本文的實(shí)驗(yàn)是檢測(cè)多個(gè)漏洞，所以是一個(gè)多分類問(wèn)題。本文分別計(jì)算每個(gè)漏洞的對(duì)應(yīng)的指標(biāo)值，然后將全部類別的對(duì)應(yīng)指標(biāo)值進(jìn)行取平均值。以第i類漏洞的檢測(cè)為例，本文的評(píng)價(jià)指標(biāo)如下。

真正類TPi：樣本的真實(shí)類別是i漏洞，模型預(yù)測(cè)的結(jié)果也是i漏洞。

假負(fù)類FNi：樣本的真實(shí)類別是i漏洞，模型預(yù)測(cè)的結(jié)果不是i漏洞。

假正類FPi：樣本的真實(shí)類別不是i漏洞，模型預(yù)測(cè)的結(jié)果是i漏洞。

真負(fù)類TNi：樣本的真實(shí)類別不是i漏洞，模型預(yù)測(cè)的結(jié)果不是i漏洞。

誤報(bào)率（FPR,false positive rate）：不是i漏洞的樣本被預(yù)測(cè)成i漏洞的占比。

召回率（TPR,true positive rate）：真實(shí)存在漏洞的樣本判定為存在漏洞。

精確度（P,precision）：i漏洞的樣本被預(yù)測(cè)為漏洞的比例。

F-Measure (F1)：精確度和召回率加權(quán)調(diào)和的平均。

精度（Acc,accuracy）：判為漏洞的樣本數(shù)量占據(jù)樣本總數(shù)量的比例。

4.3 實(shí)驗(yàn)分析

1) 回答RQ1：CIS 特征在漏洞檢測(cè)上的有效性

本文想驗(yàn)證基于CIS 特征的深度學(xué)習(xí)檢測(cè)模型是否能夠正確地檢測(cè)出漏洞，并且是否可以實(shí)現(xiàn)多種漏洞的檢測(cè)。本文選取了2 種安卓漏洞IIS 與PLP。在算法的選擇上，由于CIS 的特征包含了interest point 的上下文，因此選取了具有后向反饋的Bi-LSTM 作為模型的算法。

如表5 所示，本文按照一定的比例將每種漏洞的數(shù)據(jù)拆分成了訓(xùn)練集、驗(yàn)證集和測(cè)試集。雖然其中IIS 的數(shù)量大于PLP 的數(shù)據(jù)量，但是在針對(duì)漏洞的CIS 特征中包含了interest point 的上下文語(yǔ)義信息，這樣不同的漏洞之間的實(shí)現(xiàn)語(yǔ)句的明顯不同，所以CIS 會(huì)有明顯的差別。這樣不同漏洞之間的數(shù)據(jù)量的差距也不會(huì)影響模型識(shí)別的結(jié)果出現(xiàn)樣本不均衡的假陽(yáng)性問(wèn)題。從圖3 中可以看出，CIS 特征在訓(xùn)練過(guò)程中隨著訓(xùn)練迭代次數(shù)的增加，訓(xùn)練集和驗(yàn)證集的auc 參數(shù)都在逐步增加并逐漸達(dá)到一定的平穩(wěn)狀態(tài)，采用時(shí)訓(xùn)練集和驗(yàn)證集的loss 參數(shù)都在逐步的下降并達(dá)到平穩(wěn)態(tài)。這說(shuō)明基于CIS 的特征是可以實(shí)現(xiàn)針對(duì)安卓多種漏洞檢測(cè)。

表5 用于模型訓(xùn)練和驗(yàn)證的數(shù)據(jù)集的分布

為了進(jìn)一步驗(yàn)證基于CIS 特征的模型的其他指標(biāo)項(xiàng)隨著訓(xùn)練樣本數(shù)量的不同的變化情況，本文采用不同的訓(xùn)練集進(jìn)行模型訓(xùn)練，訓(xùn)練后的模型都采用同樣的測(cè)試數(shù)據(jù)集進(jìn)行測(cè)評(píng)模型的各種指標(biāo)項(xiàng)。在保證測(cè)試集不變的情況下，本文將表5 中的訓(xùn)練集分別拆分成8 組，詳細(xì)如表6 所示。本文針對(duì)每組訓(xùn)練集都采用同樣的模型和參數(shù)配置，圖4顯示的是不同的訓(xùn)練集下的CIS 的特征的模型的漏洞檢測(cè)指標(biāo)變化。從圖4 可以看出，隨著訓(xùn)練樣本集的擴(kuò)增，模型的精確度、召回率、F-Measure和精度都在逐步增長(zhǎng)并達(dá)到最好的98%，誤報(bào)率逐步下降到2%。

表6 用于模型訓(xùn)練和驗(yàn)證的數(shù)據(jù)集的分布

基于CIS 特征的深度學(xué)習(xí)檢測(cè)模型VulDGArcher可以正確地檢測(cè)出APP 中的多種漏洞。Bi-LSTM 算法可以捕獲長(zhǎng)句子的雙向語(yǔ)義信息，基于該算法的漏洞檢測(cè)模型精確度可以達(dá)到98%，所以Bi-LSTM 算法更適用于VulDGArcher 的檢測(cè)任務(wù)。

2) 回答RQ2：VulDGArcher 與不同的漏洞檢測(cè)方法進(jìn)行對(duì)比漏洞檢測(cè)效果

為了驗(yàn)證VulDGArcher 中CIS 的漏洞特征方法的有效性，本文采用不同的模型算法和不同的特征提取方法進(jìn)行交叉實(shí)驗(yàn)。本文在模型算法方面選取Bi-LSTM 和CNN；在APP 的漏洞特征表示方法方面選取APP 的Java 源代碼文本特征[24]、APP 的AST 特征[22]和CIS。APP 的Java 源代碼文本特征（CB,code block），就是對(duì)待檢測(cè)的目標(biāo)APP 進(jìn)行逆向處理，獲取其源代碼信息，去掉這些源代碼信息中無(wú)意義的標(biāo)記符號(hào)，最后轉(zhuǎn)換成深度學(xué)習(xí)模型可識(shí)別的向量。代碼4 是一個(gè)APP 的IIS 漏洞原始代碼樣例。APP 的AST 特征就是將APP逆向獲取出來(lái)的源代碼信息進(jìn)行AST 表示，去掉其中的特殊標(biāo)記符，然后將其轉(zhuǎn)換成深度學(xué)習(xí)可識(shí)別的向量信息。圖5 是代碼4 所示的漏洞方法的AST 表示，由于篇幅限制，圖5 中只展示了與Intent 相關(guān)的AST。

代碼4IIS 的示例代碼

表7 是不同模型在相同測(cè)試集上的結(jié)果。從表7 可以看出，基于原始的代碼做漏洞檢測(cè)模型的誤報(bào)比較高，達(dá)到51%的原因包括：1) 原始的代碼中包含了大量和漏洞形成無(wú)關(guān)的噪聲數(shù)據(jù)；2) 原始代碼中的自定義方法在每個(gè)APP 中都是不一樣的。相比較，VulDGArcher 在代碼特征化的過(guò)程中提取的是疑似漏洞點(diǎn)的語(yǔ)義上下文信息，去除了所有無(wú)關(guān)的代碼，并且對(duì)于APP 自定義的方法名和類名也進(jìn)行了歸一化處理，這樣才能使VulDGArcher 的誤報(bào)率和漏報(bào)率很低。圖6 可以更加直觀地反映VulDGArcher 與基于其他2 種特征化方法的模型的效果。由圖6 可知，VulDGArcher的APP 漏洞檢測(cè)效果更好。CNN 的漏洞檢測(cè)模型雖然也可以識(shí)別出漏洞，但是模型測(cè)試的各個(gè)指標(biāo)都低于Bi-LSTM 算法。圖7 是同樣的數(shù)據(jù)下2 種算法的ROC 曲線。從圖7 可以直觀地看出，Bi-LSTM 算法更適合CIS 特征。

表7 不同類型的代碼特征的數(shù)據(jù)進(jìn)行模型訓(xùn)練的效果

為了驗(yàn)證上述觀點(diǎn)，本文提取一個(gè)存在IIS 風(fēng)險(xiǎn)的APP，在實(shí)驗(yàn)驗(yàn)證過(guò)程中，VulDGArcher 可以識(shí)別出它存在該風(fēng)險(xiǎn)，但是基于原始代碼文件的模型無(wú)法正確判斷該APP 的這個(gè)風(fēng)險(xiǎn)。代碼5 是代碼4經(jīng)過(guò)VulDGArcher將原始代碼進(jìn)行語(yǔ)義特征處理化后的結(jié)果。從代碼5 中可以看出，特征化后的代碼只包含和IIS 風(fēng)險(xiǎn)相關(guān)的語(yǔ)法信息。

代碼5VulDGArcher 對(duì)IIS 提取特征的結(jié)果

相較于原始代碼，代碼5 去除了很多無(wú)用的噪聲數(shù)據(jù)。這也反映了VulDGArcher 在漏洞識(shí)別上具有很好的效果，主要取決于基于語(yǔ)義的代碼特征化處理。

通過(guò)上述結(jié)果可以看出，基于CIS 漏洞特征化的深度學(xué)習(xí)檢測(cè)模型在APP 漏洞檢測(cè)上效果更優(yōu)。因?yàn)镃IS 相較其他2 種方法提取的漏洞特征去掉了無(wú)用的代碼信息，且包含的信息是疑似漏洞點(diǎn)的上下文相關(guān)的代碼信息。

3) 回答RQ3：VulDGArcher 與不同的漏洞檢測(cè)方法驗(yàn)證實(shí)用性

本文通過(guò)實(shí)驗(yàn)從檢測(cè)漏洞的效率角度評(píng)估VulDGArcher 是否具有實(shí)用性。本實(shí)驗(yàn)增加2 種開(kāi)源的基于規(guī)則的安卓漏洞檢測(cè)器：AndroBugs 和Marvin-static-Analyzer。它們?cè)贕ithub 上具有很多的forks and stars，都支持IIS 脆弱性檢測(cè)，但是不支持PLP 漏洞檢測(cè)。本文將基于PIAnalyzer[4]分析出的 PLP 檢測(cè)規(guī)則配置在 AndroBugs 和Marvin-static-Analyzer 工具中，使工具支持對(duì)2 個(gè)漏洞的檢測(cè)。本文從測(cè)試的數(shù)據(jù)集中隨機(jī)地選取了100 個(gè)APP，然后分別采用Andro Bugs、Marvinstatic-Analyzer、基于AST 的深度學(xué)習(xí)漏洞檢測(cè)模型和VulDGArcher 進(jìn)行漏洞檢測(cè)。如表8 所示，針對(duì)同樣的漏洞，基于學(xué)習(xí)的漏洞檢測(cè)方法的準(zhǔn)確率高于基于規(guī)則的檢測(cè)方法。因?yàn)檫@2 個(gè)漏洞的檢測(cè)方法需要考慮到漏洞點(diǎn)的上下文環(huán)境中涉及的多種對(duì)象屬性配置，而基于規(guī)則的檢測(cè)方法無(wú)法覆蓋上述條件，所以檢測(cè)準(zhǔn)確率相對(duì)較低。

表8 不同檢測(cè)方法的準(zhǔn)確率

圖8 是不同工具的耗時(shí)情況。VulDGArcher 的耗時(shí)主要是代碼特征化處理，模型的漏洞識(shí)別部分接近毫秒級(jí)。因?yàn)閂ulDGArcher 需要構(gòu)建APP 的PDG，然后對(duì)提取出來(lái)的特征進(jìn)行向量化處理，所以這部分處理是耗時(shí)的過(guò)程。雖然如此，VulDGArcher 平均在5 s 以內(nèi)就可以完成對(duì)一個(gè)APP 的漏洞檢測(cè)。圖9 和圖10 分別是各漏洞檢測(cè)工具的CPU 消耗比例和內(nèi)存消耗比例。從圖9 和圖10可以看出，VulDGArcher 的內(nèi)存消耗最多為22%，遠(yuǎn)低于Marvin-static-Analyzer 的48%；CPU 資源使用最多為30%，并且隨著運(yùn)行逐漸保持低于10%。

同種運(yùn)行環(huán)境下，本文將VulDGArcher 與其他3 種漏洞檢測(cè)引擎進(jìn)行比較，從準(zhǔn)確率、耗時(shí)和資源消耗等方面衡量發(fā)現(xiàn)，VulDGArcher 的代碼特征化是相對(duì)耗時(shí)的，但是并不是極其耗費(fèi)資源的。所以本文建議通過(guò)并發(fā)運(yùn)行平衡掉耗時(shí)的缺點(diǎn)。

5 結(jié)束語(yǔ)

本文針對(duì)現(xiàn)有基于學(xué)習(xí)的APP 漏洞檢測(cè)方法的特征表示結(jié)果缺乏語(yǔ)義信息而影響漏洞檢測(cè)準(zhǔn)確率的問(wèn)題，提出了一種包含上下文語(yǔ)義信息的特征抽象方法CIS，并對(duì)由APP 的API 誤用導(dǎo)致的漏洞提出了一種上下文感知的檢測(cè)方法。CIS 可以從APP 中提取只和漏洞相關(guān)的變量信息，并且可以消除開(kāi)發(fā)者自定義代碼的類名、方法名和變量名對(duì)模型檢測(cè)效果的影響。本文基于CIS 采用Bi-LSTM 和注意力機(jī)制構(gòu)建了一個(gè) APP 漏洞檢測(cè)模型VulDGArcher。與基于AST 和原始代碼為特征化的檢測(cè)方法相比，VulDGArcher 可以有效識(shí)別APP 不正確使用安卓平臺(tái)的API 所導(dǎo)致的漏洞。此外，本文構(gòu)建了一個(gè)包含41 812 條特征代碼段的數(shù)據(jù)集。