IOTFUZZER: Discovering Memory Corruptions in IoT Through App-based Fuzzing
隨着越來越多的物聯網設備進入消費市場，迫切需要在攻擊者之前檢測其安全漏洞。現有的基於二進制分析的方法僅適用於固件，除了那些配備有用於從設備中提取代碼的特殊工具的固件之外，這種方法很難訪問。爲了應對物聯網安全分析中的這一挑戰，本文中提出了一個新穎的自動模糊測試框架，稱爲IOTFUZZER，旨在發現物聯網設備中的內存損壞漏洞而無需訪問其固件映像。關鍵思想是基於以下觀察：大多數IoT設備通過其官方移動應用程序進行控制，並且此類應用程序通常包含有關其與設備進行通信的協議的豐富信息。因此，通過識別和重用程序專用邏輯（例如，加密）來改變測試用例（尤其是消息字段），我們能夠有效地探測IoT目標，而無需依賴於有關其協議規範的任何知識。研究中，作者實施了IOTFUZZER並評估了17種運行在不同協議上的實際IoT設備，並且該方法成功地識別了15個內存損壞漏洞（包括8個以前未知的漏洞）。
INTRODUCTION
首先介紹了物聯網設備的發展情況，並考慮到鬆散的安全保護和大量的漏洞帶來的安全隱患，給網絡犯罪分子帶來可乘之機。
物聯網攻擊的一個重要目標是設備固件中的安全漏洞。系統檢測這些漏洞需要解決一些挑戰：
1、固件獲取困難
許多供應商未公開提供其固件映像；從主板上轉儲映像需要已啓用的調試端口的支持，許多物聯網設備由於其簡單性不存在這些調試端口。
2、壓縮格式的多樣性
所獲得的固件如何解壓縮？
在對從固件中提取的文件進行安全性分析時，主要挑戰來自各種底層架構（內存佈局，指令集等）。
1、現有技術主要依賴於某些體系結構的仿真，但是NVRAM參數不可用會導致在模擬器中運行的程序崩潰；
2、利用符號執行來分析固件也需要考慮到架構問題。
Our Approach. 與傳統的嵌入式設備不同，大多數物聯網設備由用戶通過移動應用程序控制。此類IoT應用程序旨在充當其設備的電話側控制面板，因此攜帶有關該設備的豐富信息，尤其是與其固件進行通訊的方式。此類信息的示例包括應用程序中嵌入的命令（種子）消息，URL和加密/解密方案。IOTFUZZER，是一種自動的黑盒模糊測試框架，專門用於檢測IoT固件中的內存損壞漏洞。 IOTFUZZER的獨特之處在於，它可以運行協議指導的模糊測試，並利用物聯網應用程序攜帶的信息，而無需對協議進行逆向工程或從應用程序中顯式恢復此類知識。取而代之的是，它執行動態分析以識別在應用程序內部形成的將傳遞給目標設備的消息內容，並在運行時自動更改這些內容，以便使用應用程序的程序邏輯來生成有意義的測試用例，以測試目標固件。這種方法不僅輕量級，避免了繁重的協議分析，而且可靠，即使在存在密碼保護（加密，身份驗證等）的情況下，也能夠生成有效的測試有效負載。
IOTFUZZER 通過由測試用例觸發的崩潰來報告問題的存在，用於指導後續安全分析以找出漏洞的根本原因。
Contributions.
1、無需獲取固件的模糊測試框架IOTFUZZER，用於IoT設備的安全性分析。 通過利用官方移動應用程序所攜帶的信息及其程序邏輯，可以自動檢測IoT設備中的內存損壞漏洞，而無需直接訪問固件。
2、開發了一套新技術來實施自動的黑盒IoT模糊器，其中包括無需協議規範的協議引導模糊測試，用於消息生成和傳遞的上下文內加密和聯網功能重播以及用於遠程監控目標IoT設備狀態的輕量級機制。
3、作者實施了IOTFUZZER的功能齊全的原型，並對17個現實世界的IoT設備進行了評估，發現了15個對安全至關重要的內存漏洞，其中有8個從未報告過。
BACKGROUND
A. Typical IoT Communication Architecture
典型的物聯網智能設備通常配備有許多用於外部信息收集的傳感器，以及用於數據傳輸的無線連接模塊。相應的智能手機應用程序作爲控制節點，與物聯網設備配對後可以向物聯網設備發送控制命令，以更改系統設置或獲取運行狀態數據。設備和應用之間的通信模式可以是直接連接（例如Wi-Fi，藍牙和ZigBee），也可以是通過無線路由器的委託連接（即連接到同一Wi-Fi網絡）。另外，一些供應商提供了額外的雲服務來支持遠程設備管理和數據存儲。在這種雲輔助架構中，設備或IoT應用程序將通過Internet連接到雲服務器。本文將重點放在通過Wi-Fi實現通用性的本地連接模式（直接連接和委託連接）上。
B. Obstacles in Firmware Analysis
物聯網設備通常運行固件來提供系統控制、狀態監視、數據收集等功能。固件通常是高度定製的，以適應具有有限計算和內存資源的硬件芯片。由於其封閉的資源和架構多樣性，執行固件變得極具挑戰性甚至需要大量的人工分析。以下爲分析固件的挑戰：
1、固件獲取
一方面許多供應商並未明確爲用戶在線提供映像；另一方面，硬件黑客嘗試使用調試端口（例如JTAG接口）轉儲固件映像或導出控制檯。但是，越來越多的製造商傾向於在交付產品之前禁用調試端口，以防止基於硬件的破解。
2、固件解包
獲得固件映像後，下一步就是解壓縮提取包含的文件。固件格式的多樣性以及固件映像被壓縮、加密也會帶來阻礙。
3、可執行分析
對從固件映像中提取的文件進行安全性分析，主要困難在於未統一的基礎架構。
Our Approach.
物聯網應用可以用作測試封閉源IoT設備的客戶端，它是發送測試消息的節點。這樣的設計避免了在發現新漏洞時逆向工程二進制可執行文件的困難和繁瑣的工作。
C. Challenges in IOTFUZZER Design
IOTFUZZER 是一個自動的協議指導的模糊測試框架，可以將探測消息發送到IoT設備以觸發內存損壞漏洞。基於沒有針對物聯網設備的流行且占主導地位的協議標準這一事實，物聯網供應商傾向於設計定製的數據格式和協議、使用非標準的加密功能來加密消息。因此，爲了從物聯網應用程序生成協議指導和加密一致性消息，需要遵循相應設備的協議格式和加密方案。
Challenges.
1、更改網絡消息中的字段。
需要自動識別和模糊未知協議的協議字段。
2、處理加密的消息。
需要一種輕巧靈活的解決方案來重用應用程序中的消息加密功能。
3、監控崩潰。
需要設計一種有效的機制來遠程自動監視設備狀態。
Solutions.
1、更改數據源處的協議字段。
可以在協議消息源處對協議消息中使用的數據進行突變，遵循原始程序邏輯，這些突變的字符串最終將成爲協議字段。
2、在運行時重用加密功能。
由於從一開始就修改了數據源，因此正常的程序執行將有助於完成消息加密過程並生成準備發送的消息，因此無需重新實現完整的加密邏輯。
3、通過心跳機制檢測活力。
儘管無法在本地監視正在運行的設備的狀態，但可以通過發送心跳消息來推斷程序或系統是否處於活動狀態。心跳消息可以是任何查詢設備狀態的消息。
D. Scope and Assumptions
1、被測物聯網設備可以由相應的移動應用程序進行配置和控制。
2、通信渠道需要基於Wi-Fi。
3、Android平臺。
DETAILED DESIGN
IOTFUZZER 分爲兩個階段：應用程序分析階段和模糊測試階段。
1、應用程序分析階段
將物聯網應用程序作爲輸入，分析 UI 以進行網絡事件觸發，並跟蹤與應用程序協議相關領域的傳播。完成這些步驟後，IOTFUZZER記錄了所有協議字段以及相應功能。
2、模糊測試階段
使用IoT應用程序的動態工具來改變感興趣的協議字段，並動態監視IoT設備的崩潰。最後，IOTFUZZER輸出警報（即崩潰消息），指示潛在的內存損壞。
有四個主要步驟來模糊IoT設備：
1、UI分析
分析IoT應用程序的代碼並發現所有將導致網絡消息發送的UI組件，用以通過驅動相應的UI控件觸發消息發送事件。
2、數據流分析
爲了識別其值與要發送到IoT設備的消息內容相關的程序元素，跟蹤數據從一組選定的元素中發現確實影響某些消息字段的流，使用這些程序元素來突變字段的內容，以模糊設備。利用數據流分析來確定如何命令IoT應用程序生成有意義的測試輸出以用於模糊其遠程目標。
3、運行時突變
根據定義的模糊策略，一旦識別出協議字段，IOTFUZZER便會在其第一個使用位置對原始字段進行突變。然後，物聯網應用將遵循其正常執行邏輯來計算和構建消息，並將其與變異數據一起發送到物聯網設備。
4、響應監視
遠程監視IoT設備的運行狀態並捕獲觸發的崩潰。對於基於TCP的通信，IoT應用程序和IoT設備之間的連接被中斷很容易檢測，對於基於UDP的通信，使用心跳機制來檢測在不確定的時間發生的崩潰。
A. UI Analysis
在準備協議字段識別和突變時，我們只需要關注觸發網絡消息傳遞的事件。 因此，UI分析的目標是確定最終導致消息傳遞的UI元素。
一個典型的IoT應用程序的工作方式如下：當輸入文本框時，單擊UI上的按鈕，或進入另一個Activity，事件處理程序將被調用以處理事件； 之後，在事件處理功能中，將創建一個後臺線程來構建輸出消息並操作加密/解密和網絡功能。
爲了確定觸發網絡消息的UI組件，執行靜態分析以將不同活動中的UI元素與目標網絡API相關聯。
構建調用路徑。首先使用 Androguard 構建應用程序的調用圖。從目標網絡通信API開始構造UI事件處理程序的後向代碼路徑。 但是，由於存在隱式的控制流轉換，例如 thread.start 和 thread.run 的回調關係以及其他事件驅動的調用，因此還需找到這些隱式邊緣，可以通過 EdgeMiner 獲得。代碼路徑的接收器是一組最終發送網絡消息事件處理程序。
Activity轉移圖構造。爲了到達某些Activity並在模糊期間觸發網絡發送事件，需要構造Activity轉移圖。首先使用 Monkeyrunner 通過基於事件執行順序的簡單策略與每個Activity中的UI元素進行交互；之後獲得一系列UI事件以及如何觸發它們的順序；記錄將當前Activity轉換爲另一Activity的事件，對於每個Activity中的事件，根據構造的調用路徑篩選出不會導致網絡發送API的事件；最後使用記錄的UI事件構造Activity轉換圖，其節點是具有觸發消息發送API的事件（或事件序列）的Activity，而邊緣是創建或恢復Activity的事件（或事件序列）。
B. Data-flow Analysis
在執行過程中改變協議字段需要首先識別協議字段並記錄將協議字段作爲參數的函數。 鑑於IoT應用程序中的命令消息通常是由硬編碼字符串、用戶輸入或系統API構成，使用動態污點跟蹤和 TaintDroid 的改進版本來進行識別。
1、專注於突變未編碼的原始數據，不會將污點傳播到加密函數。執行加密函數識別，除了作爲標準網絡發送API的參數的接收器之外，還將污點接收器設置爲那些加密函數的參數。
2、僅在Dalvik VM中以可變級別記錄污點傳播流，未深入到本機系統庫級別（由於TaintDroid的限制）。
1、污染源。
分析的污點包括物聯網應用中的所有字符串（例如關鍵字和定界符）、消息中經常使用的系統API、來自UI的用戶輸入。
2、污染傳播。
修改傳播規則，擴大更多的污點來源。使用字典來存儲 taint 標籤。每當創建新標籤時，都會將其添加到字典中並跟蹤此標籤的依賴性。
3、污水池。
污點是確定的網絡API和加密函數使用的數據。如果網絡消息中沒有加密，則污染點將是那些標準的網絡API。是否使用加密函數可以通過下所述的加密函數識別來識別。
加密函數識別：
密碼算法通常包含算術和按位運算。首先，選擇包含算術和按位運算的函數，然後記錄消息發送事件的執行軌跡找到候選加密函數。
C. Runtime Mutation
通過污點跟蹤可以識別協議字段以及它們通過的相應功能。 動態地鉤掛記錄的函數，並在運行時更改協議字段參數以生成探測消息，這樣的設計帶來兩個好處：
（1）在對協議字段進行編碼或加密之前可以對其進行模糊處理；
（2）無需協議逆向工程就可以模糊未知協議字段。
在應用執行期間，已標記的變量將傳遞給一組函數，在數據流分析中只需要記錄第一個傳遞的函數及其調用上下文，因爲第一個函數的突變足以更改後續程序邏輯中標記變量的值。大多數協議字段都是在代碼中定義的硬編碼字符串，並且開發人員很少清理傳遞的參數，執行重複數據刪除並獲得這些記錄功能的唯一集合，並使用 Xposed 框架動態地掛鉤。傳遞給鉤子函數的原始值可以用突變值代替。
當一個鉤子函數改變了字段時，不知道協議字段是否已經被模糊化。爲了安排模糊處理的過程，我們使用算法將突變分配給功能參數。突變的分配在觸發每個事件處理程序之前進行。
對於每條消息，我們都希望隨機選擇要突變的字段子集，而不是對所有字段進行突變（因爲設備容易拒絕所有字段都發生了突變的消息）。首先從所有掛鉤函數中提取參數集P；然後隨機生成總突變量s，它是小於c（消息M中已標識字段的數量）的正整數（這樣的要求是通過將每次執行的突變數限制爲少於消息字段的數量，來減少對所有字段進行突變的機會）；最後爲等式t1 + t2 +··+ tn = s（t和s爲整數）計算了一組有效解，其中tx是分配給參數字段px的突變量。該方程的解不是唯一的，只是隨機選擇一個有效的組。由於實時數量的調用函數在運行時不可用，因此選擇一個隨機有效組是一種無偏的解決方案。該策略可以靈活適用於不同的情況，例如強調某些功能或協議字段的突變時間。
一般來說，模糊策略主要有兩種類型：基於生成的模糊和基於變異的模糊。前者需要理解協議格式，並從頭開始生成帶有結構信息的輸入，以避免被直接拒絕。後者僅使用類型信息來更改現有的種子輸入。由於協議字段的運行時突變本質上是輸入結構感知的，因此可以通過對字段採用以下啓發式突變規則來實現帶有結構和類型信息的模糊策略：
（1）更改用於基於堆棧或基於堆的溢出和越界訪問的字符串的長度。
（2）更改整數，雙精度或浮點值以進行整數溢出和越界訪問。
（3）更改類型，提供空值以錯誤解釋值和未初始化的變量漏洞。
D. Response Monitoring
當目標物聯網設備已收到模糊測試消息時，需要知道它是否觸發了任何異常行爲（例如系統崩潰）。
可能的響應可分爲以下幾類：
（1）預期響應。在這種情況下，探測消息將由IoT設備正確處理，並且不會發生任何異常。
（2）意外響應。探測消息超出了程序的預期邏輯（例如，達到了輸入參數的邊界），並觸發了未處理的錯誤。
（3）沒有迴應。當對某個探測消息沒有響應時，它可能觸發DoS漏洞，或者只是在本地處理的錯誤而沒有答覆，或者以死循環運行。
（4）斷開連接。對於像TCP這樣的面向連接的通信協議，當探測消息觸發系統崩潰時，網絡連接將被中斷。
基於以上列出的四種類型的響應，針對物聯網設備與物聯網應用之間的不同傳輸層通信使用了針對性的故障檢測機制。對於基於TCP的連接，只是通過查看連接狀態來推斷系統是否崩潰。對於基於UDP的連接，如果程序或系統崩潰，則不會有任何響應發送回IoT應用程序。
爲了區分這兩種情況，使用心跳插入機制。
首先從IoT應用程序中提取心跳消息，該消息用於檢測設備是否處於活動狀態。心跳消息的提取基於對網絡功能的分析以及在有或沒有用戶與配對的應用程序交互的情況下通過網絡流量進行的差異分析。然後在模糊測試期間，每隔十個插入一個心跳消息以探測是否有活動。
IMPLEMENTATION AND EVALUATION
介紹IOTFUZZER的原型實現並分析評估結果。
A.實現細節
1、共計大約9,100條Java代碼行和1,400條Python代碼行；
2、在IOTFUZZER中集成開源項目（例如Xposed和TaintDroid）；
應用程序分析階段：
3、使用 Androguard，EdgeMiner 和 Monkeyrunner 實現調用路徑的構建和自動 Activity 轉換；
4、依靠Xposed模塊和Monkeyrunner觸發網絡事件以進行污點分析和後續的消息傳遞操作。Xposed提供了掛鉤和替換功能；
5、擴展TaintDroid的污染源和污染跟蹤策略來實現污染跟蹤；
6、污點跟蹤的輸出寫入配置文件中
模糊測試階段：
7、通過在應用執行過程中在Xposed中創建分析線程來實現核心功能（計劃，突變和崩潰監控）；
8、預裝了配置文件以提供目標功能的信息。
注意，分析線程旨在通過爲每個掛鉤函數分配突變配額來安排模糊測試，並且該突變仍在應用的原始線程中執行。某些確認的崩潰是由相同種子消息的變異消息（具有微小差異）觸發的（不同實例，但可能觸發相同的錯誤），因此，記錄每個種子消息和變異消息對的關係可以對崩潰消息進行分類。當獲得一組由IOTFUZZER生成的崩潰消息時，可以將它們與相應的種子消息進行比較，以找到突變的字段並進一步確認固件映像中的漏洞。
B.實驗設置
所有選擇設備都可以通過官方IoT移動應用程序通過本地Wi-Fi網絡進行操作。
對通信協議和數據傳輸格式沒有限制。
Intel Core i7四核×2.81 GHz CPU和8 G RAM的Ubuntu 14.04 PC
Google的Nexus 4上運行污點跟蹤
將正在測試的IoT設備配置爲完全控制的本地Wi-Fi網絡設置，避免了無關的流量和不必要的防火牆封裝干擾。
設備初始化後，將這些設備與智能手機上安裝的相應物聯網應用程序配對，智能手機連接到相同的無線局域網。
C.有效性
使用IOTFUZZER（每個設備設置爲運行24小時）對17個IoT設備執行模糊測試，發現9個設備中有15個嚴重漏洞（內存損壞），包括5個基於堆棧的緩衝區溢出，2個基於堆的緩衝區溢出，4個空指針取消引用和4個崩潰。
D.效率
IOTFUZZER在測試時間和測試用例數量上通常都超過了流行的開源模糊測試，僅用52.79小時就識別了15個內存損壞，總共有184159條模糊信息。
DISCUSSION AND LIMITATIONS
測試範圍。
儘管IOTFUZZER獲得了較高的規範覆蓋率（用於協議），但固件的代碼覆蓋率和攻擊面的覆蓋率卻受到限制。
主要焦點是從移動應用程序的數據輸入通道自動識別內存損壞。爲了檢測（利用）此類內存漏洞，IOTFUZZER（攻擊者）必須以調試（惡意）意圖輸入實際數據。
對於現代物聯網設備，移動應用程序提供了主要的數據輸入通道，以方便設備管理。儘管攻擊者可能會利用其他數據通道，例如傳感器或調試端口，但由於物理訪問的要求，利用的門檻很高，這使得攻擊很難在實踐中成功。
連接模式。
在IOTFUZZER的當前實施中，僅關注與Wi-Fi連接到移動應用程序的設備。
結果判斷。
IOTFUZZER無法直接生成內存損壞類型和根本原因。IOTFUZZER的設計目標是自動生成漏洞警報（即崩潰消息），以幫助安全分析人員輕鬆地定位和確認固件的根本原因。
結果準確性。
對於誤報，IOTFUZZER報告的某些崩潰消息源自不可避免的和不可預測的網絡錯誤，尤其是對於基於TCP的連接。如果IOTFUZZER在子進程中發生並由相應的父進程正確處理，則可能會丟失某些崩潰。線程崩潰將始終影響整個進程並導致進程崩潰，因爲線程沒有自己的地址空間。同樣，在某些情況下，內存損壞也不會導致崩潰。例如，緩衝區溢出導致損壞的局部變量，並且不會損壞堆棧幀或返回地址。
CONCLUSION
介紹了第一個物聯網模糊測試框架IOTFUZZER，它利用官方的移動應用程序來檢測相應物聯網設備的內存損壞。 爲了進行有效的安全測試，開發了一套新穎的技術，包括用於消息生成和傳遞的上下文內加密和網絡功能重播，沒有協議規範的協議字段的運行時變異，以及用於檢測系統崩潰的輕量級監視機制。 通過在真實環境中進行實驗，使用IOTFUZZER成功識別了17個IoT設備中的15個內存安全漏洞。