• 沒有找到結果。

Android 惡意程式偵測方法之相關研究

第二章 文獻探討

2.3 Android 惡意程式偵測方法之相關研究

無論是 Android 權限要求或是 Android API 函式呼叫,在過去已經被許多研究作為 研究變數,因為這些資訊與惡意程式行為息息相關,例如惡意程式作者希望取得使用 者 之 地 理 位 置 , 並 透 過 簡 訊 回 傳 至 遠 端 伺 服 器 , 則 需 要 ACCESS_COARSE_LOCATION 和 SEND_SMS 兩個權限,並且在程式碼中實際呼叫此

11

兩權限所對應之 API 函式,分別為 getCellLocation 函式和 sendTextMessage 函式。因此,

在本節將針對現有之 Android 惡意程式偵測研究進行探討,以及回顧相關的文獻,討 論其所用到的分析技術和使用到的特徵變數,並以此作為本研究分析系統的基礎。

 靜態分析

靜態分析 [8] 是將 Android 應用程式中的 APK 檔案,從 APK 中提取出所需的判斷 變數,進行比對。無論是權限、字串、和字節碼中的 API 函式呼叫等等。靜態分析的 優點在於不會被惡意程式所偵測,分析速度快,以及節省電腦計算資源。靜態分析的 方法,可再進一步依照提取的變數分成特徵分析、權限分析及 API 函式分析。

(1) 特徵分析

特徵分析會將程式碼中特定的模式或是一段程式指令提取出來,建立一個獨特的 特徵,並以此來比對現有的特徵資料庫,判斷是否有惡意特徵。然而這樣的分析方法 只能辨別出已知的惡意程式,無法識別未記錄特徵的惡意程式,因此需要不斷更新惡 意程式碼特徵資料庫。除此之外,大量的特徵比對也會消耗許多電腦運算資源。

Droid Analytics [9] 是基於特徵分析的系統,透過分析 Dalvik 字節碼 [10] ,將每一 個 Android 應用程式內所使用到的函式以及類別作為特徵變數,共有 47126 個特徵,

每個特徵將給予一個特定的十六進位編碼作為此特徵的編號,接著將每一個 Android APK 檔案反組譯後取得對應的特徵編號來與已知的惡意程式家族比對相似度。 Droid Analytics 與防毒軟體所使用 MD5 雜湊方式所建立的特徵相比更具優勢,因為 Droid Analytics 使用 Dalvik 字節碼作為特徵,因此能夠識別出惡意程式的程式碼區段,以及 惡意程式執行的程式邏輯,而 MD5 雜湊所建立的檔案特徵僅只限於單一檔案層級,無 法得知是哪段程式區段被辨認為惡意程式。但此研究也發現,有許多特徵同時出現在 惡意程式和非惡意程式中,代表這些重複的特徵對於辨別惡意程式與否為無效的特徵。

同時此研究只僅於辨認已知惡意程式,因為判別惡意程式與否均是仰賴與已知惡意程 式 家 族比 較, 而 如果 遇到未知惡意程 式則 無法辨識 。 Parvez 等人在 [11] 中提出 AndroSimilar,使用統計特徵的方式來偵測惡意程式,AndroSimilar 利用已知的惡意程

12

式特徵為基礎,來計算未知應用程式和惡意程式家族的相似度,判斷成功率為約為六 成。但使用特徵分析的缺點就是判斷準確率會根據惡意程式碼資料庫的特徵數量而有 不同的準確性,當特徵數量不足就無法準確判斷惡意程式。由上述研究可知,特徵分 析方式仍受限於特徵資料庫的大小,以及無法偵測未知的惡意程式。

(2) 權限分析

在每一個 Android 應用程式被安裝前,都需要授權同意程式所需要的權限,權限 要求會被列在 AndroidManifest.xml 檔案中,且 Google 將 Android 權限根據風險程度,

區分為一般權限和危險權限 [12] 。因此安全研究者可以根據危險權限的請求來進一步 分析是否有可能為惡意程式。

為了解決特徵分析的不足,而有了權限分析。 Ryo 等人在 [13] 中,提出一種輕量 化的檢測方法來分析 AndroidManifest.xml 檔案,來獲得 Android 的權限,並由此計算 惡意風險評分,若惡意風險評分超過閾值則認定為惡意程式。這樣的檢測方法非常節 省計算資源,且可以檢測出未被識別過的惡意程式。但僅有使用權限作為判斷依據的 準確度仍不高,很容易將非惡意的程式誤判為惡意程式,且權限也無法保護所有重要 的資訊,因為有些惡意行為不需要權限就能進行,例如在程式碼中執行 Linux 系統的 指令來取得手機系統之資訊。在 Enck 等人 [14] 和 Tang 等人 [15] 的研究中,提出以權 限為主要分析的變數,且均有使用權限分組作為新變數,並自訂了一些可能的惡意程 式規則,例如同時擁有接收簡訊和寫入簡訊內容權限的程式,就有可能為有風險的應 用程式,要求的權限同時符合所定義的組合規則時 才認定可能為惡意程式,例如 READ_PHONE_STATE 可以取得手機號碼和 IMEI 但是不能將資料移轉出去,若要竊 取出去可能需要 INTERNET 或是 SEND_SMS 的權限請求。因此使用組合的方式,能 夠更加確定惡意行為的發生。

針對權限要求所進行的研究已被認為是可行的,但誤判率較高,因為開發者有可 能會過度要求權限,一般的應用程式也會因為要求了高風險的權限而導致被判定為惡 意程式。之後 Wang 等人 [16] 提出具關聯的權限特徵,利用關聯法則將 APK 內的權限 進行資料探勘,找出潛在的權限關聯,再透過機器學習的方式進行分類預測。以及 Liang [17] 等人和 Liu [18] 等人也均有利用多種權限為組合特徵,將 Android 應用程式

13

的權限取出後,兩兩權限一組進行組合配對成新的屬性並再透過機器學習進行分類,

實驗結果顯示大幅提高了辨識率。由此可見,組合特徵可有效的提高判斷率。

(3) Android API 函式分析

在 Android 手機中所運行的程式,是程式開發者使用 Java 來撰寫的 Android 應用 程式,經過編譯之後會變成 Dalvik 字節碼,接著再透過 Dalvik 虛擬機來執行。API 函 式分析即是透過工具將 APK 反組譯成字節碼進行分析,從 Dalvik 字節碼中可以發現許 多有用的資訊,例如有使用到的 Android API 函式呼叫、程式碼中的字串等等。除了權 限外,另一派學者則將 API 函式呼叫作為主要變數,此處 API 所代表的是由 Google 所 提供的 Android SDK,為了使用手機特定功能,例如讀取簡訊、傳送簡訊、讀取聯絡 人、讀取定位等等功能,此類的 API 函式無法被程式碼混淆技術所混淆,因此可以從 靜態分析來找到是否有使用這樣的 API 函式呼叫。

DroidMat [19] 從 AndroidManifest.xml 提取權限、Intents 中傳遞的資料以及 API 函 式呼叫來分析惡意行為,並使用 K-means 來分群、KNN (K Nearest Neighbor)來分類。

對於惡意程式辨識率已有明顯提升,且花費計算資源少,缺點為無法檢測到有動態載 入以及加殼保護的惡意程式,這在靜態分析是一個常見的問題。之後有學者提出基於 權限和 Android API 函式呼叫作為判斷變數,DroidAPIMiner [20] 以及 Peiravian [21] 等 人,透過機器學習的方式來分類惡意程式,提高只有權限分析的準確性,已有穩定且 準確率高的結果。

(4) 函式呼叫圖(Call Graph)分析

函式呼叫圖是一個控制流程圖,代表程式中函式與函式之間呼叫的關係,通常 會用節點代表各個函式,以箭頭表示函式呼叫順序,並會搭配條件式控制函式呼叫 的路徑,以此構成函式呼叫圖。透過函式呼叫圖,我們可以很清楚瞭解一個程式中,

所有程式路徑的走向。函式呼叫圖可以是靜態也可以是動態,動態函式呼叫圖代表 式真實執行的路線,而靜態函式呼叫圖則代表程式所有可能的呼叫順序。 Jiawei 等 人在 [22] 中設計一個包含兩個步驟的檢測方法。首先將每一個 Android 應用程式中

14

的所有 Android API 函式繪製成靜態函式呼叫圖,稱為 API 函式控制流程圖。接著從 每個惡意程式家族中提取出不同的長度的 API 函式序列,因為惡意程式家族中的惡 意程式通常共享相似的行為模式。最後,將 Android API 函式序列作為輸入特徵,透 過支援向量機、單純貝氏分類以及決策樹分類方法建立 Android 惡意程式檢測模型。

並且評估不同長度的 Android API 函式序列的準確性,結果顯示,在支援向量機的分 類方法會有最佳的準確性,以及長度為二時,會有最好的效果。Apposcopy [23] 同樣 是透過靜態函式呼叫圖來檢測惡意程式,並從 Android API 函式中自定義目標以及動 作兩類型的 API 函式,以此建立資料流的分析。例如惡意程式中有 getDeviceId 函式 此 一 目標 API 函式 ,能夠取得目標手機的 IMEI(International Mobile Equipment Identity)號碼,並有透過 sendTextMessage 函式此一動作 API 函式傳送出去。將惡意 程式家族中以此方法建立所有可能的資料流特徵來檢測 Android 應用程式是否出現此 類特徵,若有則判斷為惡意程式。此種方法相較於單獨使用 Android API 函式更加精 準,但如同靜態分析會遇到的缺點,遇到程式碼混淆或加密即會提高分析的難度。

 動態分析

不同於靜態分析,動態分析 [8] 是將所要分析的程式運行於虛擬機中後,才進一步 去分析程式的行為。動態分析的優點為可以看到一個程式完整的面貌,包括做了什麼 事、使用何種資料,若有什麼惡意行為可以很容易被檢測出來,而靜態分析則相對不 容易檢測;動態分析的缺點為有些程式路徑可能會沒有被執行到,且動態分析在分析 速度和計算資源使用度均比不上靜態分析,但是靜態分析遇到程式碼混淆、加密或者 是其他規避分析技巧時,便會使得分析更加複雜,因此遇到這樣的問題就需要透過動 態分析來解決以上問題。

(1) 函式執行順序分析

由於 Android 程式是在 Linux 作業系統中執行,因此在 Crowdroid [24] 提出一種動 態檢測程式行為的方法,藉由 strace [25]工具, strace 為在 Linux 作業系統環境下的一 套程式分析工具,能夠觀察程式在執行時,所使用到的所有系統呼叫,以此工具來收 集應用程式的 Linux 系統函式呼叫的詳細資訊,透過手機設備端傳送系統紀錄給遠端

15

的伺服器,而在伺服器端則是使用分群演算法來進行分析。這種架構是為了解決分析

的伺服器,而在伺服器端則是使用分群演算法來進行分析。這種架構是為了解決分析

相關文件