# [A Large-Scale Empirical Analysis of the Vulnerabilities Introduced by Third-Party Components in IoT Firmware](https://nesa.zju.edu.cn/download/zbb_pdf_issta_22.pdf)

## Abstract

* IoT 韌體的開發為了提高效率降低成本，依賴第三方元件(TPC)
* TPC 中的漏洞將會影響韌體的安全性，且現有工作較少關注這塊
* 實現 FirmSec，利用句法特徵和控制流圖特徵來檢測 TPC 並識別對應的漏洞
* 分析 34136 個韌體，其中有 11086 是公開的韌體
* 成功檢測到 584 個 TPC，識別 429 個 CVE
* 針對設備的地區分析，發現中國和韓國的設備特別危險

## Introduction

* 韌體廣泛使用 TPC 加速開發過程
* BusyBox, OpenSSL
* TPC 的漏洞將會打開更多攻擊面
* OpenSSL 中的 Heartbleed 漏洞
* 因此識別容易受攻擊 TPC 很重要，目前的工作較少關注 TPC，且缺乏對非 Linux 的韌體支援(擴展性低)

### Challenges

* 韌體數據集建構
* 為了研究需要大量的數據集
* 韌體處理
* 基於 Linux 的韌體需要提取 filesystem
* 單片韌體需要知道 Metadata
* TPC 檢測和漏洞識別
* 需要識別版本
* 需要 TPC 數據庫，收集 TPC 和對應的漏洞

### Methodology

* 從公共來源和私人收集韌體
* 利用 binwalk 和 IDA 對韌體做處理
* 從 TPC 和韌體中提取句法特徵和控制流圖特徵，根據版本檢查搜索對應漏洞
* 最後 FirmSec 會產出報告
* 該論文更深入探討 IoT 的四個面向
* 不同供應商的漏洞差異
* 不同地區的安全性差異
* 過時 TPC 的問題
* 韌體中 TPC 的 GPL/AGPL 許可違規

### Contributions

* [韌體資料集開源](https://github.com/BBge/FirmSecDataset)
* 提出 FirmSec，是可擴展的自動化框架，用於分析韌體中使用的 TPC 並識別漏洞
* 91.03% 的準確率
* 92.26% 的召回率
* 針對 TPC 做了大規模分析
* 確認 IoT 設備的地區差異
* 發現 2478 個韌體可能違反 GPL/AGPL

## Design and Implementation

* 
* 分為三塊
* 韌體收集
* 韌體預處理
* 韌體分析

### Firmware Collection

* 韌體收集主要使用爬蟲，來源有三種
* 官網
* FTP site
* 社群
* 私有韌體的部分，得到一家智能居家公司的韌體庫權限
* 以 TSmart 代表該公司

### Firmware Preprocessing

* 可分為三個步驟
* 過濾
* 根據副檔名過濾非韌體的檔案
* 識別
* 根據爬蟲爬到的 Metadata 文件提取韌體的訊息(型號和類別等等)
* 用 binwalk 掃描得到 os, 架構和 filesystem
* 提取和反組譯
* 提取部分使用 binwalk 提取
* 使用 sasquatch, jefferson 和 yaffshiv 來解決無法提取的類型
* 反組譯部分利用 IDA 反組譯並得到 CFG
* 單片韌體可能會沒有資訊而無法反組譯，參考韌體的處理器手冊並實作相關 IDA 插件來完成

### Firmware Analysis

* 韌體分析模組分為三個部分
* 數據庫建立
* TPC 檢測
* 漏洞識別

#### TPC Database Construction

* TPC 數據庫需要包含韌體中可能使用的 TPC 和每個版本的漏洞資訊
* IoT 韌體並沒有一個公開可訪問的數據庫，因此只好盡可能地收集 TPC 並映射漏洞
* TPC 來源
* 從韌體中提取
* 開源的 IoT 專案
* IoT 平台的 SDK
* TSmart 的 TPC 名單
* 利用 cve-search 從 CVE 數據庫查詢 TPC，並撰寫腳本查詢 NVD 和 CVE 的資訊
* 最後建立 1191 個 TPC，包含 TPC, licenses, 版本, CVE, CVSS scroes, CVE 描述

#### TPC Detection

* 檢測版本是困難的，因為兩個版本之間的程式碼差異可能很小
* 利用句法特徵和 CFG 特徵來檢測
* 從 TPC 和韌體上提取這兩個特徵後，利用編輯距離和 ratio-based 的匹配來計算相似度，並用 Gimini 模型比較 CFG 特徵

##### TPC feature extraction

* 實作一個 TPC 的 C/C++ 解析器，可提取句法特徵
* 句法特徵包含字串、Function 名稱和型別
* TPC 所有版本中一樣的特徵稱為共享句法特徵，不同版本有差異的稱為獨特句法特徵
* 再來，從每個版本的 TPC 提取出屬性控制流圖(ACFG)

##### Firmware feature extration

* 從韌體中提取句法特徵
* 單片韌體可能無法解析函數名稱
* 藉由在 IDA 配置大量 TPC 的簽名文件來解決(一樣的 funrction 就會自動匹配)
* 一樣利用提取 ACFG，因為單片韌體無法反組譯所以要訂製提取工具

##### Syntactical feature matching

* 利用編輯距離和 radio-based 匹配來衡量 TPC 與韌體的相似度
* 如果 TPC 與韌體句法特徵的距離 < alpha 就是為特徵匹配，將下一步檢查
* 如果 < beta 就認為該 TPC 匹配成功
* 韌體中與 TPC 的語法特徵重複的比例夠高
* 匹配成功後的標記為 𝑅𝑆𝑦𝑛𝑡𝑎𝑥

##### CFG feature matching

* 利用修改過後的 Gemini 做 CFG 特徵匹配
* 多了 function level 的資訊，原本只有 Block level
* 匹配成功後的標記為 𝑅𝐶𝐹𝐺
* 最後辨識的結果取 𝑅𝑆𝑦𝑛𝑡𝑎𝑥 和 𝑅𝐶𝐹𝐺 的聯集
* 沒寫不一樣怎麼處理

#### Vulnerability Identification

* 最後利用建立的 TPC 數據庫與檢測到的 TPC 版本來檢查漏洞
* 有些漏洞其實無法被利用，因為受攻擊的部分可能因為配置等原因，其實無法被存取
* 最後會韌體產生一份報告，指出所有潛在的風險與提供修復的建議

## System Evaluation

* 數據集
* 
* 過濾完之後有 11086 個公開韌體、 23050 個私有韌體
* 7.9% IP cam, 21.3% 路由器, 3.5% switch
* 23.9% ARM, 4.9% MIPS
* 36.2% Linux-based, 63.8% non-Linux based
* 為了評估，建立三個有 Groundtruth 的子數據集
* 用於訓練修改後的 Gemini 並評估準確度
* 用於給 FirmSec 選擇適當 Thresholds
* 用於評估 FirmSec 識別 TPC 和其版本的準確度
* 因為很難明確知道韌體中使用的 TPC，最後使用 Tomatoshibby 和 OpenWrt 的韌體，因為有 Source code
* 結果有準確度和召回率
* false positives 代表識別錯誤的 TPC 或版本
* false negatives 代表沒識別成功
* 
* 不採取聯集時準確度差不多，但召回率低很多
* Gemini 是原始未修改的
* BAT 用字串來辨識，無法辨識版本
* OSSPolice 原來用於辨識 Android 中的開源軟體，修改成 TPC 的版本
* false positives 原因
* TPC 重疊
* 不同版本太過相似
* false negatives 原因
* 韌體中的 TPC 太少見
* 只使用部分的 TPC 導致特徵不足

## Data Characterization

### TPC Usage

* FirmSec 解包並反組譯了 96% 的韌體檔
* 123 個被加密
* 972 個來自 TSmart 的是未知的處理器
* 269 使用未知的 filesystem
* 
* 識別 584 個不同的 TPC
* OpenWrt 的路由器有最多的 TPC，因為它是開源的
* 單片韌體(TSmart)中的 TPC 較少，因為它通常會自己實作功能
* 每種設備前 10 常見的 TPC
* 
* 不同廠商使用相同 TPC 很常見
* 不同種類使用的 TPC 具有共通點

### Introduced Vulnerabilities Overview

* 34136 個韌體中發現 128757 個潛在漏洞，涉及 429 個 CVE
* 
* 小米的路由器特別多，平均有 116.19 個
* 其他廠商也是路由器特別多問題
* OpenWrt 和 TSmart 數量雖多，問題卻較少
* 
* OpenSSL 包含最多 CVE
* Busybox 使用最廣泛

## Analysis Results

* 四個實驗問題
* 來自不同供應商不同種類的韌體有多容易受攻擊
* 容易受攻擊的設備地理分布在哪
* 是否該採用最新的 TPC
* 是否存在違反 TPC 許可的情況

### Firmware Vulnerability

* 
* 路由器最容易受攻擊
* 
* 小米最容易受攻擊

### Geographical Distribution

* 使用 Shodan 搜尋設備的分佈
* 
* 韓國、美國、台灣、加拿大最嚴重
* 歐洲國家較少
* 這可能跟工廠模式和韌體的更新機制有關

### Delay Time of TPCs

* TPC 版本太新可能不能用，但太舊可能有漏洞
* 計算了韌體使用的 TPC 發布日和發布時 TPC 最新版本的天數
* 
* 延遲時間與漏洞有正相關
* 發現路由器平均都比較久

### License Violations

* 主要研究 General Public License (GPL) 和 Affero General Public License (AGPL)
* 發布時必須也要開源
* 
* 很多都找不到韌體的 source code

## Discussion

* FirmSec 對於 N-day 漏洞發現能力很不錯，但對未知漏洞的發現能力薄弱
* 結合 Fuzzing

## Conclusion

* 對目前 IoT 韌體中的 TPC 做了大規模的分析
* 提出 FirmSec 用於尋找 TPC 引起的韌體漏洞
* 進一步分析 TPC 帶來的問題與設備的地區差異等

###### tags: `paper`