# [An Efficient Greybox Fuzzing Scheme for Linux-based IoT Programs Through Binary Static Analysis](https://ieeexplore.ieee.org/abstract/document/8958740?casa_token=Kb_i1kK8L9oAAAAA:MzXAHIKB3Yfoo5peZwAmx6XjqX2k7-BWeDw697HFGA9DlHAj8cUosApXlQS565r1peBXY8g)

## Abstract

* 傳統的 Fuzzing 因為執行環境的關係，有時不能直接用於 Based on Linux 的 IoT 上。
* 提出了新方法，可以 Based on Linux 做灰箱模糊測試。
* Binary static analysis
* IoT program greybox fuzzing
* Binary static analysis 用於生成 Fuzzing 的有效輸入。
* IoT program greybox fuzzing 強化 frimware 的 kernel 使其更好監控 IoT program

## Introduction

* Based on Linux 的設備通常會了達到功能實現會做修改，卻對安全設計考量不周。
* Linux 是開源的，攻擊者更好打。
* Fuzzing 是常見的測試技術，透過隨機輸入看看程序是否有異常。
* Greybox fuzzing 則是透過輕量的檢測去指導輸入的生成，使測試效率提高。
* AFL
* Linux IoT program 的特點
* 拿不到原始碼，只能提取
* AFL 可以只用 Binary 做測試
* 需要特定環境配置
* 用 Emulation
* (TriforceAFL 將全系統模擬和 AFL 結合)
* 挑戰
* 大多數的 AFL 生成輸入在 IoT 程序早期階段會被丟棄
* 沒有符合格式
* IoTFuzzer 根據行動裝置去做優化，但對大多數 IoT 系統沒有用
* 灰箱測試本身難以收集 IoT 執行的訊息，難以觀察程式狀態並計算覆蓋率
* 解決方法
* Binary static analysis
* 靜態分析出能執行不同路徑的關鍵字
* IoT program greybox fuzzing
* 基於 TriforceAFL 做修改，更精準觀察程式
* 對 module 做修改，process monitor, system call monitor and context analyzer。
* 評估
* Based on IDA Pro and TriforceAFL 完成系統
* 用 Firmadyne 配置 6 個 Firmware
* 透過發現 program 的漏洞和崩潰來評估系統的有效性和效率
* 貢獻
* 通過對物聯網程序的二進制靜態分析在全系統仿真中提出了一種有效的灰盒模糊測試方案
* 對現實世界的物聯網程序進行評估，可以有效地發現基於 Linux 的物聯網程序中的漏洞

## Overview

* 系統分為兩個階段

### Binary static analysis

* 
* 使用 Binwalk 提取出 firmware 中的 binary 檔
* 找到 Binary 中的字串
* 對這些字串做汙點分析，確認是否為關鍵字
* 字串當作 taint source
* 常用和字串、記憶體相關的 lib function 當作 taint sink
* 
* 汙點分析時，將程式切成 block 來跑，放入 queue 中一個一個拿出來做分析
* 從有使用到該字串的 block 開始做汙點分析，如果影響到一個 function
* function 是一般 function，放入 queue 繼續跑汙點分析
* 是 taint sink function，完成
* BFS

### IoT program greybox fuzzing

#### TriforceAFL

* TriforceAFL 是基於 AFL，又引進 QEMU，使其支援全系統仿真的 kernel 模糊測試
* TriforceAFL 流程
* 啟動 IoT 模擬，同時啟動 fuzz drive
* fuzz drive fork 出子 process 執行後續的動作
* 從 Fuzz 引擎拿出輸入餵到子 process 中
* system call 出現才餵？
* 裡面幾個關鍵元件
* Fuzz 引擎：和 AFL 一樣的輸入生成機制
* Fork：不同於 AFL 只需要對單一 process 做 fork，TriforceAFL 需要支援多 process 才能達到 full-system 模擬
* 程式碼覆蓋率：TriforceAFL 在使用到 system-call 時記錄下當前的 PC 和 位於的 block，如果計算出的覆蓋率較高就將該輸入加入到 seed pool 中

#### Modification

* 
* Fuzz 引擎：直接從前面的 Binary static analysis 拿出關鍵字，但變異策略一樣
* Fork：特別針對網路相關的 system call，這些 system call 出現前才做 fork 並送入輸入
* 程式碼覆蓋率：覆蓋率所需要的資訊存在虛擬地址空間中，但虛擬機切換 process 時會共享地址空間，因此需要針對 PC 使用上下文分析器去追蹤

### Real-time monitor for IoT program

* 為了做到前面提到的新的 fork 模式和覆蓋率監控，實作了這個 Real-time monitor
* 三個功能
* process monitor，觀察程序何時啟動、暫停
* 藉由 Linux kernel 的 task_struct 可抓到任務的名稱和 PID
* system call monitor，用於新的 fork 機制 (for 網路相關 system call
* 發生 system call 時去抓 system call number，比較是否為目標 system call
* context analyzer，用於更精準的代碼覆蓋率
* 藉由 Linux 的 page global directory 找到現在執行的 process
* 透過 QEMU system mode 實現

## Implementation and Evaluation

### System implementation

* Binary static analysis 用 python 完成、IoT program greybox fuzzing 用 c 完成
* Binary static analysis 使用 IDA Pro 逆向，用 IDApython 完成汙點分析
* IoT program greybox fuzzing 基於 TriforceAFL 實現系統

### Experiment setup

* Dataset: Firmadyne，網路攝影機 or 路由器
* 先用 Firmadyne 模擬起來，HTTP 的相關 process 做為測試目標
* 除了找到的關鍵字之外，另外加入了 long string 來更快的觸發 BOF
* 和 AFL 和 TriforceAFL 比較，跑24小時
* 不跑靜態分析

### Effectiveness

* 
* 發現 6 個已知漏洞和 1 個未知漏洞
* TriforceAFL 和 AFL 大部分根本跑不起來

### Efficiency

* 用靜態分析出來的關鍵字和隨機測試做比較
* 同一個 process 跑五次
* 
* 紅：靜態分析、藍：隨機測試
* 上面：發現的 Crush、下面：路徑覆蓋率

## Limitation

* 目前靜態分析是將 uClibc 中的字串、記憶體 function 訂為 taint sink，但如果他自己寫 compare function 就抓不到
* 目前系統模擬是直接用 Firmadyne，因此 Firmadyne 跑不起來的也就不能用

## Conclusion

* 利用 static binary analysis 強化模糊測試的效率
* 加強 full emulation greybox fuzzer，支援 IoT 的模糊測試
* 發現現實世界 IoT programs 的漏洞證明有效性。

###### tags: `paper`