WLAN –WAN 2) DUT –LAN

3) DUT –WLAN 4) DUT –WAN 5) LAN –LAN 6) LAN –WLAN 7) LAN –WAN 8) WLAN –WLAN

經過我們的實驗，一般的無線 DUT 在設計上經常在以下路徑上有安全性的漏 洞，這些路徑分別是 LAN –LAN、LAN –WLAN 以及 WLAN –WLAN (以下我們用 critical paths 表示這三條路徑)。圖 5-15 顯示此實驗之架構，其中紅線表示 critical paths。SIDSI 支援 flowbit 之功能，因此它可以比對跨封包之 SNOT 規則，如圖 5-16 所示。

圖 5-15、SIDSI 實驗架構圖

圖 5-16、SIDSI 支援跨封包比對 SNOT 規則

圖 5-17 顯示未切割之一般封包含有違規存取字串 get /admin-serv/config/admpw (以紅框標示)，經實驗測試後，該 DUT 可正確地偵測該封包有越權存取的危險性。接 著我們再透過 SIDSI 送出切割後的封包，將違規字串拆散在數個封包內發送，藉以測 試 DUT 之進階防禦能力。

圖 5-17、含有違規存取字串之未分割封包範例

圖 5-18 顯 示 經 由 SIDSI 分 割 並 送 出 的 封 包 ， 我 們 透 過 SIDSI 的 MakePacket_Diveded()函式指定封包字串長度為 3。因此，分割封包中的第一個封包的

字串內容為 get，下一個封包 payload 為/ad。

圖 5-18、SIDSI 支援分割封包之功能

以上實驗說明了 SIDSI 之實用性，SIDSI 除了提供基本的發送攻擊封包之測試功 能外，它亦支援分割封包等進階功能，可用多種方式來測試 DUT 之強度與防禦能力，

進而提供 DUT 強度改進的建議。

 行動裝置滲透檢測

 Android 行動裝置惡意網頁檢測工具

以下我們利用實驗來說明 Android 行動裝置惡意網頁檢測工具能夠攔截具有惡意 攻擊的語法的網頁。在使用者瀏覽網頁時，第一個動作便是下載該網頁的資料。在下 載網頁資料的同時，Android 行動裝置惡意網頁檢測工具會將該網頁資料中有安全疑 慮的 javascript 進行 overlay 的動作。

圖 5-19 顯示使用者對於 google 進行連線要求。當下載完 google 網頁後，Android 行動裝置惡意網頁檢測工具也完成 javascript 的轉換並且顯示出 ”DEBUG: Finish Loading!”。

圖 5-19、下載網頁

接著 Android 行動裝置惡意網頁檢測工具將利用建立好的 policy 來判定轉換完的 javascript 函數是否具有威脅性。若是通過 policy 判定，瀏覽器將呈現 google 的網頁(見 圖 5-20)。

圖 5-20、網頁未發現威脅

接著我們展示 Android 行動裝置惡意網頁檢測工具如何偵測出具有惡意程式碼的 網頁。首先，我們先建立一個網頁，其網址為 http://140.113.216.158。該網頁被駭客 惡意植入了 cross-site attack 攻擊的程式碼，因此所有連上該網頁的使用者的 Cookie 都會被輕易地被駭客盜用。同樣地，Android 行動裝置惡意網頁檢測工具先連線到該 網頁，修改具有安全性問題的 javascript 語句 (如圖 5-21 所示)。接著 Android 行動裝 置惡意網頁檢測工具發現該網頁含有惡意攻擊的語法，它會攔截該攻擊並且顯示如圖 5-22 所示的訊息。

圖 5-21、惡意網頁下載

圖 5-22、成功偵測到 cross-site attack

 Android 應用軟體安全漏洞檢測工具 (G-exploit)

G-exploit 旨在檢測 Android 上應用程式之漏洞，幫助程式開發人員彌補程式開發 中不經意發生的錯誤或是修補隱藏的安全性漏洞。由於 java 本身就是一個以安全為優 先考量的程式開發語言，因此常見的錯誤都是寫作壞習慣或是寫作規則的錯誤，較少 發現可能造成重大傷害的安全性漏洞，但是仍隨著 Android 之普遍和日趨強大的功 能，Android 之應用軟體安全也益發重要。

目前 G-exploit 可以檢測到的 java 問題包含:

1) 正確性的問題(correctness)：檢測程式設計人員沒注意到之寫作上的錯誤，避 免此類寫作錯誤成為真實程式的臭蟲 (bug)。

2) 寫作壞習慣(bad practice)：檢測程式設計人員寫作時的壞習慣，例如解構子 的濫用，避免不必要的錯誤。

3) 異常的程式碼(dodgy)：檢測不確定的程式行為，如未被確認的轉型等等。

我們以 Snake 這個 Android 應用程式為例，介紹 G-exploit 之操作流程並驗證 G-exploit 之可行性。首先，我們將 Snake.dex 檔上傳至 G-exploit 網頁平台，並選擇使 用 Findbugs 軟體來進行靜態偵測 (見圖 5-23)。

圖 5-23、G-exploit 線上檢測平台

接著，G-exploit 將呈現檢測報告，如圖 5-24 所示。由檢測報告可以看出，此應 用程式大小為 689 kbs，含有 75 個臭蟲。此檢測報告亦會提供安全漏洞的危險等級，

其中 Bugs p1 之危險等級最高，Bugs p2 其次，依此類推。而報告中的 Ratio 則表示安 全性漏洞的存在比例。此次實驗偵測到的安全性漏洞為 MS (見圖 5-25)，這表示在 Snake 程式中存在一塊可被惡意程式或是經由人為的不小心而被更動的靜態區塊；MS 安全漏洞將可能造成 Snake 程式被惡意程式所控制而執行非預期之惡意行為，其解決 辦法為將 Snake 程式封裝成套裝軟體 (package)。

圖 5-24、G-exploit 之檢測報告

圖 5-25、檢測結果之詳細說明

 Android 動態惡意軟體程式檢測工具

藉由 QEMU Translator 的幫助，我們目前已經可以成功將 Android 建置在 x86 主 機模擬系統的上層，並以此進行觀測。圖 5-24 是 Android 架設在 x86 系統模擬流程。

首先，利用其 VM Dalvik 將 Android 的應用程式編譯成屬於簡單指令集的 ARM 指 令。接著，我們利用 QEMU Translator，將 ARM 指令轉換成複雜指令集的 x86 指令 集。由於 ARM 指令已經被轉至成 x86 指令，所以它可以架設在 x86 主機模擬系統 (QEMU)。因為經由 Dalvik 所編譯出來的 ARM 指令再轉成 x86 兩段手續後將會造成 指令無法確實對應，因此我們還無法進行惡意軟體分析與判斷，我們需要進一步研究 來解決這個問題。

圖 5-26、Android 架設在 x86 系統上的模擬流程

圖 5-25 是我們接下來預計完成的流程圖。在未來兩年，我們將繼續研究 ARM 指 令的操作碼 (OP-code)，了解每個指令是要做什麼事情，並且了解在這操作碼之後所 接續的暫存器與與我們在 x86 系統動態惡意軟體程式所作記錄的暫存器相對應關係。

得知這些對應關係之後，我們就可以將這些 ARM 指令轉換成 x86 指令，然後就可利 如同 x86 系統動態惡意軟體行為偵測系統來進行 Android 平台上惡意軟體的檢測。

圖 5-27、預計工作流程圖

 文件檔案惡意程式檢測系統 (Forenser)

Forenser 為一自動化惡意程式檢測系統，它可偵測文件檔案中的惡意程式碼。以 下我們將介紹 Forenser 針對非 Windows 執行檔所做的檢測流程。圖 5-28 顯示 Forenser 針對非 Windows 執行檔做檢測的流程。Forenser 會依序將掃描的過程及結果一一呈現 給使用者(見圖 5-29)。當檢測完成時會會提供檢測報告並提供操作上的建議 (見圖 5-30)，檢測報告結果亦可用右上方的第三個按鍵儲存。

圖 5-28、針對非 Windows 檔案檢測流程

圖 5-29、檢測中提供詳細的資訊給使用者

圖 5-30、檢測完成並給予使用建議

 動態惡意軟體分析檢測工具 (Malware Behavior Analyzer, MBA@TWISC) 為了追蹤 X86 主機的資訊流動，我們對 X86 指令集中的每個指令進行分析，

了解每個指令的汙染擴散行為。例如 mov op1, op2 這組 X86 指令中，假若 op2 是我們認定的汙染資料，藉由 mov 的搬動，op1 也隨之受到汙染，又或者 jmp [mem]會將記憶體位址 mem 汙染擴散到 CPU 的程式計數器(Program Counter)… 等。在確認為需要記錄為可疑的指令後，我們將搭配接下來將會提到的” 汙染資 料記錄資料結構設計”做記錄。

為了提升資料擷取的效率以及減少儲存汙染資料所造成龐大的空間負擔，我 們為系統設計一了個資料結構以利後續分析。X86 指令間彼此互動頻繁，在一連 串的指令傳遞過程中，很有可能都是受到同一分汙染資料的干預因而造成汙染資 料檔必須記錄所有指令以及暫存器的內容，造成其中許多不相關的資料也跟著被 記錄。依照這種方式記錄會造成資料紀錄檔過於龐大，不僅浪費記錄資料的空 間，這種沒有效率的紀錄會照成往後提取資料困難而嚴重影響分析汙染資料的效 能。

如果想要模擬一 512MB 的 X86 主機運作，所需要花費的記憶體就達 2.5GB 之多。為了解決這個問題，我們透過如記憶體管理單元將記憶體分層的概念，以 避免未受汙染的區塊也同樣占據記憶體空間。如以記憶體前 24bit 作為索引，便 可節省未受到任何汙染的 256 個記憶體區所需的汙染資料結構。如圖 5-31 所示：

圖 5-31、利用記憶體管理方式改良記錄資料結構

汙染記錄資料結構設計完成後，接下來要為 X86 系統模擬器(QEMU)的每個 模擬儲存單元作修改，所謂的模擬儲存單元包括：CPU 的暫存器、記憶體、硬碟、

鍵盤輸入緩衝區、顯示卡的顯示緩衝區以及網路卡的傳送/接收緩衝區等等。每 個模擬儲存單元都有不同的儲存格式，所以在資料結構上也為了各個單元做了調 整，讓資料記錄更有彈性，資料分析也更有效率。

本系統已經完成資訊流動的追蹤，但是卻沒有設定資訊安全的功能。本系統 提供了技術人員可以自行標定特定儲存單元或是特定資料當作汙染源的標的，以 進行分析。此功能僅提供基本規則的定義方式，不足以定義和作業系統相關的資 訊安全規則。由於模擬與分析工作可以彼此獨立進行，因此本系統利用管線化處 理的概念，提高整體模擬運行的 throughput。我們將整個系統的工作切割成三段 獨立的子單元，如圖 5-32 所示。藉由(A)模擬 CPU 運行指令、(B)依該指令之行 為更新汙染記錄資料結構以及(C)檢查是否違反定義的資訊流程安全規則的獨立 以及管線化處理，達成提升整體分析效能。

圖 5-32、管線化設計

 大規模遠端系統滲透測試網 (RSPTN)

本計畫已經於 98 年度完成大規模遠端系統滲透測試網之初步建置，以下將以一 範例實驗說明 RSPTN 之使用方式與支援之功能。此滲透測試網之系統規格與實驗受 測電腦規格如下：

－ 滲透測試網伺服器

CPU：Intel Core 2 Duo E6300 Ram：DDR II-667 1G*2 OS：LINUX 2.6.29.4

－ 受測電腦

CPU：Intel Pentium-M 1.5 GHz Ram：768 MB

OS：Windows XP Pro SP3

當受測電腦連上 RSPTN 後，若是同意 RSPTN 進行滲透測試，則 RSPTN 便可開 始弱點偵測與分析。以此次測試實驗為例，經過約 90 秒，RSPTN 可產生滲透測試報 告，此報告正確地分析受測電腦之作業系統 (Windows XP)，且 RSPTN 可偵測出 87 個弱點，並能成功滲透其中之一 (見圖 5-33)。