---
# System prepended metadata

title: '[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)'
tags: [paper]

---

# [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

* ![](https://i.imgur.com/sR6LvP5.png)
* 分為三塊
    * 韌體收集
    * 韌體預處理
    * 韌體分析

### 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 就是為特徵匹配，將下一步檢查
* 如果![](https://i.imgur.com/PrJPH38.png) < beta 就認為該 TPC 匹配成功
    * 韌體中與 TPC 的語法特徵重複的比例夠高
* 匹配成功後的標記為 𝑅𝑆𝑦𝑛𝑡𝑎𝑥

##### CFG feature matching

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

#### Vulnerability Identification

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

## System Evaluation

* 數據集
    * ![](https://i.imgur.com/CQJEEhJ.png)
    * 過濾完之後有 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 代表沒識別成功
* ![](https://i.imgur.com/YjKD2Ka.png)
    * 不採取聯集時準確度差不多，但召回率低很多
    * Gemini 是原始未修改的
    * BAT 用字串來辨識，無法辨識版本
    * OSSPolice 原來用於辨識 Android 中的開源軟體，修改成 TPC 的版本
* false positives 原因
    * TPC 重疊
    * 不同版本太過相似
* false negatives 原因
    * 韌體中的 TPC 太少見
    * 只使用部分的 TPC 導致特徵不足

## Data Characterization

### TPC Usage

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

### Introduced Vulnerabilities Overview

* 34136 個韌體中發現 128757 個潛在漏洞，涉及 429 個 CVE
    * ![](https://i.imgur.com/0hoaIwC.png)
* 小米的路由器特別多，平均有 116.19 個
    * 其他廠商也是路由器特別多問題
    * OpenWrt 和 TSmart 數量雖多，問題卻較少
* ![](https://i.imgur.com/oezk9iE.png)
    * OpenSSL 包含最多 CVE
    * Busybox 使用最廣泛

## Analysis Results

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

### Firmware Vulnerability

* ![](https://i.imgur.com/gJOOs5X.png)
    * 路由器最容易受攻擊
* ![](https://i.imgur.com/EYz8Kla.png)
    * 小米最容易受攻擊

### Geographical Distribution

* 使用 Shodan 搜尋設備的分佈
* ![](https://i.imgur.com/40RKP0p.png)
    * 韓國、美國、台灣、加拿大最嚴重
    * 歐洲國家較少
* 這可能跟工廠模式和韌體的更新機制有關

### Delay Time of TPCs

* TPC 版本太新可能不能用，但太舊可能有漏洞
* 計算了韌體使用的 TPC 發布日和發布時 TPC 最新版本的天數
* ![](https://i.imgur.com/KchxXHs.png)
    * 延遲時間與漏洞有正相關
    * 發現路由器平均都比較久

### License Violations

* 主要研究 General Public License (GPL) 和 Affero General Public License (AGPL)
    * 發布時必須也要開源
* ![](https://i.imgur.com/snOV9mI.png)
    * 很多都找不到韌體的 source code

## Discussion

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

## Conclusion

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

###### tags: `paper`