針對Android移動應用的惡意加密流量標注方法研究

何高峰,司勇瑞,徐丙鳳

(1.南京郵電大學 物聯網學院,南京 210003; 2.東南大學 計算機網絡和信息集成教育部重點實驗室,南京 211189;3.南京林業大學 信息科學技術學院,南京 210037)

0 概述

隨著移動互聯網的迅速發展,Android智能終端已經成為日常社會活動的重要輔助工具,與此同時,Android智能終端的廣泛使用也吸引了眾多攻擊者的目光,造成各類惡意移動應用攻擊事件層出不窮。如2019年趨勢科技安全團隊在Google Play中檢測出惡意應用Flappy Birr Dog,其會竊取用戶的短信、聯系人信息以及截屏、錄音等敏感性文件,對全球196個國家都造成了嚴重的影響[1]。惡意移動應用現已普遍采用HTTPS等加密流量進行網絡數據傳輸從而躲避檢測[2],這給移動網絡和移動用戶的安全防護帶來了巨大的挑戰。

為了從加密網絡流量中識別出惡意移動應用,研究人員提出多種基于機器學習的檢測方法,如文獻[3-5]等。此類檢測方法的共同流程是同時運行惡意移動應用和正常移動應用,采集其產生的網絡流量作為數據樣本,從收集的網絡流量樣本中提取檢測特征,利用支持向量機等機器學習方法對檢測特征進行訓練,從而得出檢測模型。再利用檢測模型對未知流量進行分類檢測,判定未知流量是否由惡意移動應用產生。在上述流程中,準確的網絡流量采集是檢測方法的基礎,這是因為機器學習分類方法的有效性依賴于數據標注的正確性[6]。

然而,現有工作對惡意移動應用的流量標注研究較少。實際上,已有相關研究均將惡意移動應用產生的所有網絡流量直接標注為惡意流量,并對其進行特征提取和建模分類,但該方法會產生較多的錯誤標注,如對公開的惡意移動應用網絡流量數據集CICAAGM[7]進行分析時,150個惡意移動應用總共產生477條TLS(Transport Layer Security)流量,但其中多數TLS流量都具有Google的合法證書。進一步利用TLS證書的別名選項排除Google和Facebook中的正常流量,剩余的惡意流量數目僅有196條。在此案例中,若將所有加密TLS流量均標注為惡意流量,則會產生大量的錯誤樣本標注數據,從而影響最終檢測結果。究其原因,多數Android惡意移動應用通過重打包方式形成[8],黑客攻擊者通常選取對熱門移動應用進行反編譯并加入惡意代碼,再對修改后的代碼和資源文件進行重新打包發布,誘騙用戶下載運行。因此,移動用戶在運行該惡意移動應用時,原有代碼也將被執行以完成主體功能,從而產生正常交互網絡流量。這類流量與惡意代碼無關,應當標注為正常流量,進而使得惡意流量樣本數據集更加精確。

為區分惡意移動應用產生的加密網絡流量為惡意流量還是正常流量,本文提出一種針對Android移動應用的惡意加密流量標注方法。通過TLS握手協議等特征篩選出可疑加密流量,再對惡意移動應用進行反編譯,利用代碼分析對可疑加密流量進行確認,從而標注出惡意加密流量,以減少錯誤標注。

1 相關工作

現有研究工作提出多種惡意移動應用檢測方法,如文獻[9]提出一種三步驟檢測方法。首先,識別HTTP POST/GET請求報文;然后,在識別出的報文中查找用戶身份敏感內容,如國際移動用戶識別碼IMSI和移動設備國際識別碼IMEI等;最后,若檢測出敏感內容,使用WHOIS工具查詢遠端服務器的注冊信息,并判斷遠端服務器是否為攻擊者服務器。若遠端服務器為攻擊者服務器,則判定當前流量為惡意移動應用產生的惡意流量,反之則為惡意移動應用產生的正常流量,該方法需要檢測報文內容,因而只適用于明文流量,無法應用于加密流量的檢測判斷。

針對加密網絡流量的檢測判斷,文獻[10]以平均報文長度、流平均長度、報文時間間隔等網絡流量統計值為檢測特征,利用機器學習分類方法對Android惡意移動應用進行檢測。在測試的48個移動應用樣本中(包括正常移動應用和惡意移動應用),總共成功檢測出45個樣本,準確率為93.75%。文獻[11]以發送和接收的報數字節數、網絡狀態(WiFi、蜂窩等)、應用狀態(前臺、后臺等)為移動應用的行為特征,利用機器學習方法建立惡意移動應用檢測模型,實驗結果表明檢測率超過80%,誤報率小于10%。

文獻[12]提出一種基于網絡行為對比的重打包應用檢測方法。通過選擇類似應用將待檢測應用的網絡行為與類似應用的網絡行為進行比對,若行為差別超過一定閾值,則判斷為重打包應用。該檢測方法以網絡行為作為考慮對象,不涉及流量內容,因而適用于加密流量的檢測,但如何選擇合適的類似應用是一項挑戰。為此,文獻[13]提出一種基于移動邊緣計算的惡意重打包應用檢測方法,在移動邊緣計算節點處對不同移動設備產生的同一應用流量進行聚類分析,從而能夠準確發現重打包應用。文獻[14]提出基于攻擊圖的移動應用進行安全評估。文獻[15]構建了移動應用安全防護生態鏈。文獻[16]使用域名對惡意移動應用進行檢測。但上述研究工作均未涉及惡意加密流量的標注問題。

傳統的網絡安全研究中已注意到惡意網絡流量的標注問題。文獻[17]提出一種利用網絡攻防比賽來標注網絡攻擊數據集的思路,并說明了相關系統的組成部分和功能。文獻[18]針對惡意DNS查詢流量,提出一種半人工方式的標注方法。文獻[19]利用黑名單、安全報告和沙盒分析對惡意網絡流量進行標注,進而提高機器學習分類方法的檢測效果。現有工作主要解決傳統網絡攻擊流量的標注問題,對本文研究具有重要的啟發和借鑒意義。

2 Android移動應用惡意加密流量標注

2.1 方法概述

本文提出Android移動應用惡意加密流量標注方法的整體思路,具體如圖1所示。首先,根據端口號和報文熵值判斷流量是否為加密流量,若為加密流量,則依據TLS握手協議解析Client Hello報文和服務器端返回的證書等內容,若解析失敗或握手協議內容異常,則標記該加密流量為異常流量。然后,對移動應用APK文件進行反編譯,在代碼中檢索對應域名或IP地址。最后,以對應域名或IP地址所在函數為中間節點,構建程序控制流程圖,并在圖中尋找是否含有敏感函數調用,若含有敏感函數調用則標注該流量為惡意加密流量。

圖1 本文標注方法的整體思路

在上述基本思路中,有2點需要加以解釋。一是網絡流量與移動應用的對應關系,在采集移動應用網絡流量數據時會單獨運行某移動應用程序,并利用VPN程序排除其他干擾流量[13],因而可以明確網絡流量所對應的移動應用。二是惡意移動應用多數調用Android系統函數來完成攻擊目的[20],如調用讀取短信、日歷或聯系人的系統函數來竊取用戶數據,或調用發送短信、撥打電話相關系統函數進行惡意扣費等,因此本文利用是否含有敏感函數調用來判斷是否存在惡意行為。

2.2 異常加密流量的檢測

從圖1可以看出,標注加密網絡流量時需判斷該流量是否為加密流量,以及是否為異常流量。Android移動應用多數利用HTTPS協議進行數據的加密傳輸[21],判斷服務器端口是否為443,若是,則判定該流量為加密流量。值得注意的是,若443端口流量不屬于加密流量,后續的代碼分析將會對其進行排除。若遠程端口不為443,則計算報文內容載荷的熵值[22-23],具體過程如下:

針對網絡流f,合并所有報文內容(不考慮報文頭部信息),形成長度為N的字節串,即網絡流f內容大小為N字節。計算每一字節對應的數值(0～255),并計算數值ni出現的頻率。如第一個字節對應的數值為3,且在N個字節中,數值3一共出現10次,則數值3的頻率計算為10/N,記頻率pi為ni/N,則網絡流f的內容載荷熵值H(f)的計算方法如式(1)所示:

(1)

其中,m為不同數值的個數。

理想情形下的所有數值都均勻分布,此時熵值最大為8。計算H(f)與8的差值d,若d小于設定的閾值τ,則判定該流量為加密流量,d的計算方法如式(2)所示:

d=8-H(f)

(2)

根據文獻[23]可知,當N≥1 024時,加密的網絡流f的內容大小大于1 KB時,H(f)值無限趨近于8,在實際中易于滿足該條件。因而本文方法對τ值的設定沒有嚴格要求,實驗中τ值設定為0.8。

識別出加密流量后,統一執行TLS協議解析,解析Client Hello報文和服務器端返回的證書內容。若Client Hello、證書內容或服務器自身異常,則判定該加密流量為異常流量。具體的加密流量異常判斷條件如下:

1)TLS協議解析失敗。

2)或者Client Hello報文中的密碼套件支持3DES、RC4等不安全加密算法。

3)或者解析服務器的證書內容失敗。

4)或者服務器證書為自簽名。

5)或者服務器位于云平臺中,如Google App Engine、百度云盤等。

6)或者服務器不在Alexa top 200中。

上述6個判斷條件為“或者”關系,只需滿足其一,則可判定為異常加密流量。異常加密流量判定的背后邏輯是:正常Android移動應用多數基于HTTPS(HTTP+TLS)協議進行數據的加密傳輸,且客戶端優先選擇橢圓曲線加密算法等高安全算法,以保證通信內容的安全。而惡意移動應用利用加密流量僅僅是為了躲避檢測,且多數自簽名其證書以降低攻擊成本和隱藏自身信息(購買和維護X.509證書需要一定費用,且泄露攻擊者自身信息)[24-25]。由于黑客趨向于借助公共云平臺隱藏身份[26],且黑客自身部署的服務器排名較低,因而上述6個條件能夠有效檢測出異常加密流量。

2.3 惡意加密流量的確認

檢測出異常加密流量后,執行代碼分析確認該流量是否為惡意流量,具體步驟如下:

輸入流量域名或IP地址A以及對應的移動應用APK文件F

輸出流量標注

//初始化

步驟1判定APK文件F是否存在全局程序控制流程圖G,若不存在,則反編譯APK文件F,構建全局程序控制流程圖G并保存。

步驟2在反編譯后的源代碼中尋找IP地址A,確定IP地址A所在的函數Fun(A)以及產生該流量的參數變量Par1,Par2,…,Parp。

步驟3通過函數調用判斷與IP地址A的網絡連接是否為加密連接,若不為加密連接,則返回。

//前向搜索(確定參數是否敏感)

步驟4在函數Fun(A)中檢查參數Par1,Par2,…,Parp的賦值情形,若在賦值過程中調用了敏感函數,返回“惡意”標注。

步驟5在全局程序控制流程圖G中,以函數Fun(A)為起點,深度優先向前遍歷所有父節點。

步驟6在父節點中,檢查對參數Par1,Par2,…,Parp的隱形賦值情況,若在賦值過程中調用了敏感函數,返回“惡意”標注。

步驟7若遍歷結束,返回“正常”標注。

//后向搜索(判定后續是否有敏感函數調用)

步驟8在全局程序控制流程圖G中,以函數Fun(A)為起點,向后遍歷所有子節點。

步驟9若子節點中存在敏感函數調用,返回“惡意”標注。

步驟10若遍歷結束,返回“正常”標注。

在上述步驟中,初始化階段的核心功能是反編譯APK文件F,然后針對得到的源代碼,構建全局程序控制流程圖G。APK文件名稱、反編譯后的文件與全局程序控制流程圖將一一對應保存,便于后續分析使用。程序控制流程圖反映程序調用關系,示例如圖2所示。Android應用的程序控制流程圖可由Soot框架自動生成,本文不再進行贅述。

圖2 程序調用關系示例

在初始化階段的步驟2中,利用域名或IP地址A定位至特定函數。但在實際中,域名可以動態生成(通過參數賦值或多個參數串聯而成,如new URL(str)),無法直接進行匹配查詢。因此,在生成全局程序控制流程圖時,對于網絡訪問類函數,需要對訪問地址參數進行數據流分析,進而得到域名的完整表示,具體流程同前向搜索類似。

執行完初始化后,進行前向搜索,確定函數參數是否含有敏感數據。參數變量Par1,Par2,…,Parp表示Android系統提供的網絡相關函數,如setURI函數的參數。在當前節點所在的函數Fun(A)中尋找對Par1,Par2,…,Parp的賦值語句,若在賦值語句的右邊存在變量Var,則繼續向上遍歷其父節點,尋找對變量Var的賦值語句(即對參數Par1,Par2,…,Parp的隱形賦值)。以此類推,形成遞歸分析,從而最終確定參數Par1,Par2,…,Parp的具體值,如圖3所示。若在賦值路徑中存在敏感函數調用,則返回“惡意”標注。

圖3 參數值回溯流程

在后向搜索中,無需考慮參數問題,只需判斷子節點是否為敏感函數。即在網絡通信結束后,根據通信內容,惡意移動應用會執行相關攻擊代碼。此行為在遠程控制、廣告展示類惡意應用中較為常見。惡意流量的確認算法中的敏感函數具體有startService()、loadClass()、sendTextMessage()、getContentResolver()、query()、mkdir()、delete()、ListFiles()等。完整的函數列表及其在惡意應用的常見應用解釋見文獻[27]的第4節內容,但不包括其中的HttpURLConnection 和Sockets等網絡相關函數。

3 實驗結果與分析

為了測試本文方法的準確性,實驗重點對重打包類型惡意應用進行分析。這是由于可以通過比對原始應用和重打包應用的代碼,確定惡意代碼位置,從而明確網絡流量的真實類別。即由原始代碼產生的網絡流量為正常流量,而由額外添加的代碼所產生的網絡流量為惡意流量,進而為本文方法的測試提供基準值。

從公開數據集AndroZoo[28]中下載了300個合法移動應用和300個對應的重打包移動應用。針對下載的600個移動應用,首先反編譯其代碼,經文件比對定位出惡意代碼位置。代碼反編譯由Jadx工具完成,代碼文件的比較通過WinMerge來實現。然后,將重打包應用運行于真實的智能手機中,捕獲其產生的網絡流量。若運行出錯(如移動應用版本較早,無法運行于最新手機),則根據移動應用的API版本,配置對應虛擬機進行安裝運行。移動應用的安裝運行均自動化進行,且安裝過程使用adb install命令實現。安裝完成后,使用開源的DroidBot自動點擊產生點擊事件,運行移動應用不同組件。

如圖4所示,移動應用流量的采集由網關完成。網關運行Ubuntu 16.04操作系統,并配置WiFi熱點功能,智能手機及虛擬機均通過無線網絡連接至該網關。在網關中,部署tshark軟件進行網絡流量報文的抓取。流量域名的提取同樣由tshark完成,具體命令為tshark-e dns.qry.name。本文重點解決加密流量的標注問題,在流量采集中僅保存加密流量。首先判斷服務器端口是否為443,若不為443,則計算流載荷的字節熵值。若熵值大于7.2,即式(2)中的τ值為0.8,則標記為加密流量。對于采集的加密流量統一按照TLS協議進行解析,若解析成功,則標記為TLS流量,否則標記為其他類型的加密流量。結果發現,實驗中采集的TLS流量數量為1 523條,其他類型的加密流量數量為116條。

圖4 采集網絡流量環境設置

針對采集到的其他類型的加密流量,進一步分析其對應的移動應用源代碼,確定其是否為真正加密類型的網絡流量。在116條其他類型的加密流量中,總共有79條流量為加密流量,其產生的方式為使用AES或自定義的加密算法對數據內容進行加密,通過Java Socket編程將數據發送至遠程服務器。而剩余的37條網絡流量為壓縮流量,數據內容經gzip等壓縮后發送至服務器。后續的分析僅針對1 602(1 523+79)條加密網絡流量進行。

針對篩選后的加密網絡流量,利用2.2節中的異常判斷條件按照先后順序匹配檢測,若滿足其中一項,則判斷異常并停止后續匹配,檢測結果如表1所示。

表1 異常檢測結果

對表1中的422(79+15+217+111)條異常加密流量執行惡意流量確認算法步驟進行確認。使用Soot生成全局程序控制流程圖,然后對圖執行前向搜索和后向搜索。全局程序控制流程圖規模龐大,難以直接展示,因而將數據保存為XML格式。利用Java解析XML文件進行節點的遍歷操作,在前向遍歷時,需要結合源代碼確定變量賦值語句,此部分由人工方式完成。

代碼分析結果表明,總共有341條加密流量為惡意流量,剩余的81條加密流量為正常流量。進一步同基準值進行對比,結果如表2所示。

表2 基準值比對結果

從表2可知,在異常檢測階段檢測出的正常流量均為正常加密流量,從而減少了惡意流量確認部分的分析負載。在惡意流量確認階段,針對422條異常加密流量,共產生了28條誤報流量,誤報率為6.6%。與未采用本文方法標注的1 602條惡意加密流量相比,采用本文方法標注的惡意加密流量僅有341條,總共減少了1 261條錯誤標注,占總數量的78.7%。由此可知,本文方法能有效減少錯誤標注,從而構建出更加精確的惡意移動應用網絡流量數據集。

4 結束語

本文提出一種針對Android移動應用的惡意加密流量標注方法,判斷網絡流量是否為加密流量,對于非加密流量,使用傳統的DPI技術對其標注,而對于加密類型的流量,依據TLS協議對其解析并利用TLS握手消息等內容判斷該流量是否異常。若該流量異常,則對相應的惡意Android移動應用進行反編譯,構建程序控制流程圖,并分析該加密流量是否涉及敏感操作。若該加密流量的參數為敏感數據或執行完網絡通信后調用執行敏感函數,則標注該加密流量為惡意加密流量。針對300個重打包類型惡意應用進行測試,分析結果表明,未采用本文方法總共采集1 602條加密流量,采用本文方法只有341條流量被標注為惡意加密流量,且僅有28條為誤報流量。因此本文方法可準確地標注惡意Android移動應用網絡流量。

本文僅針對重打包類型惡意Android應用進行分析,后續工作將對更多類型的惡意移動應用進行測試,并研究更加合適的異常加密流量判斷標準,從而減少異常加密流量的數量,提升代碼分析性能,同時識別出APT攻擊類型加密網絡流量。基于形成的準確數據集,將開展針對單條惡意加密流量的在線檢測研究,以更好地保護移動應用和移動網絡安全。