# [Game of Hide-and-Seek: Exposing Hidden Interfaces in Embedded Web Applications of IoT Devices](https://dl.acm.org/doi/abs/10.1145/3485447.3512213?casa_token=mORQUWmOzTwAAAAA:gjjO5z7DzYONeLqHW2ZmWZTUj5LKpQC9a_bizpZi1JGF8oH0igQSIdUILTyvFgrnLqWKXvo0xp3Q_Q)

## Abstract

* 針對物聯網設備的 Web 應用程式的攻擊越來越多
* 一個攻擊的目標是隱藏頁面，不使用任何保護措施，但會將敏感訊息暴露給非法使用者
* 提出 IoTScope，自動公開 IoT 設備隱藏 Web 頁面的新方法
* 透過韌體分析建構出請求去測試實體設備
* 請求中會附加各種設備設置的參數來定位隱藏的接口
* IoTScope 在 17 個設備上進行評估，辨識出 44 個漏洞，其中 43 是以前未知的漏洞
* 同時具有高效率，平均在目標設備上發送 151,438 個請求，只花費 47 分鐘
* 應該是 [Open-Source](https://github.com/botao21/IOTScope)

## Introduction

* 嵌入式 Web 應用程式(簡稱 EWA)常用於在管理和配置設備上，提供與使用者交互的方式
* EWA 使用上越來越多，但保護卻不多，容易被未經身分驗證的攻擊者利用

### Hidden interface of IoT device

* 攻擊 EWA 可行的方式是透過隱藏接口，隱藏頁面可能是開發人員有意或無意留下的，不需驗證即可洩漏資訊或是更改設置
* 例如：CVE-2019-14984 利用 exec.cgi 執行系統命令
* 根據 OWASP 統計，broken access control 在 Web 應用程式安全風險中，已經從第五名上升到第一名
* 在 IoT 領域中，缺乏工具去找出這些隱藏頁面

### Approach

* 提出 IoTScope，自動暴露 IoT 設備中隱藏接口
* 透過靜態分析韌體，提取文件名和路徑來建構出請求
* 每個請求發出兩次(略有不同)，比較相似度並判斷是否為無效請求
* IoTScope 指出兩種類型的隱藏接口
* 允許操作設備設置的接口，從前端提取出設備設置參數
* 暴露敏感資訊的接口，從接口上的內容與 NVRAM 或配置文件匹配
* 評估 11 家供應商中 17 台設備
* 發現 44 個漏洞，其中 43 是以前未知的漏洞
* 包含 RCE、安全操作暴露、敏感資訊洩漏等
* 回報並分配了 8 個 CVEs
* 每台設備上花費 101 秒到 3.59 小時，平均 47 分鐘完成

## Background and Motivation

### Embedded Web Applications

* EWA 常用於配置設備的管理介面
* 比起 Apache ISS Nginx 等 web server，EWA 更輕量
* 比起 .php，更常用 binary-based .cgi file
* 沒有 source code
* 經常跨架構，因為設備基於 ARM 或 MIPS

### Hidden Interfaces of Embedded Web Applications

* EWA 通常受到身分驗證和授權的保護，但有些隱藏介面卻不用
* 隱藏介面包含開發者造成的漏洞或留下的後門，主要有兩種類型
* 操作設備設置：例如未經身分驗證修改 DNS server 的 IP
* 資訊洩漏：例如將使用者的登錄密碼洩漏給攻擊者
* 隱藏介面成為攻擊面的主要原因
* 不需驗證即可觸發漏洞
* 攻擊者的效益很高，可直接得到敏感資訊或允許安全操作
* 因為 server 本來就需要監聽 HTTP/HTTPS，防火牆不會阻止訪問隱藏介面

### Challenges in Exposing Hidden Interfaces

* 希望自動化發現這些隱藏介面會遇到的挑戰
1. 列舉所有可能接口
* Web 頁面會用不同方式呈現並位於不同位置，且有可能是各種副檔名，難以列舉
2. 識別未受保護的接口
* 發出請求後，可以得到一堆 request-respone pair，需要識別其中未受保護的部分
* EWA 並不一定會正常的使用 HTTP 的狀態碼，因此需要在不利用 respone 的前提下，自動找出未受保護的接口
3. 識別隱藏接口
* 和會導致程式 Crash 的漏洞不同，沒有提示會告知接口是否為隱藏接口

## Design

* 
* 輸入是設備和 firmware image
* 透過靜態分析韌體提取文件和路徑，構造出 HTTP request
* 利用請求與物理的 IoT 設備或是模擬的設備交互
* IoTScope 收集請求與回應，過濾不感興趣或是受保護的接口
* 最後對剩下未受保護的接口分類(操作 or 洩漏)
* 系統的輸出是韌體中易受攻擊的接口

### Enumerating Interfaces

* 
* 將 filesystem 中的 cgi, php, asp, xml, htm, html 的文件名提取出來
* 接著將 Web server 的腳本和可執行文件重新打包，已排除與 Web 無關的路徑(如 /etc /proc 等)
* 根據這些路徑和文件名，IoTScope 會生成請求 list

### Delivering Probing Requests

* 該元件負責向設備/模擬器發送和接收 HTTP 封包
* IoTScope 每個請求會發送兩次，分別是有 certificate 與沒有

### Identifying Unprotected Interfaces

* 
* 所有的 request-respone pairs 會在這個元件中被分類
* 如果有 certificate 和沒有所帶來的 respone 不同時，表示該介面具有驗證保護
* 但回應相同時，不表示找到未受保護的介面，更多時候是 URL 不存在/無效
* 將所有 respone 相同的 request-respone 分類，最大數量的類別即為無效回應
* 分類方式單純比較字串相似度

### Identifying Hidden Interfaces

* 經過前面的步驟，已經將被保護的接口和無效接口過濾，接著要辨識對使用者有威脅的隱藏接口
* 修改設備配置
* 掃描 Web 頁面前端，提取出請求的相關參數
* 針對 Web 頁面發送兩個請求，一個附加會改變設備設置的參數，另一個沒有
* 如果回應不同表示參數生效
* 但很難自動判定請求是更改設備設置還是狀態查詢，得手動分析
* 資訊洩漏
* 從 NVRAM 和 server 配置文件建立了一個字典檔，當回應內容匹配至少兩個關鍵字時，判定有資訊洩漏

## Evaluation

* Intel i7 processor and 16GB RAM, running Ubuntu 20.04
* 
* 11 家廠商的 17 台設備
* 最新版本的韌體
* 共找到 44 個漏洞(43 個以前未知)

### Overall Results Identified Vulnerabilities

* 
* 8 個 CVE
* 
* 發現 20 個設備設置和 48 個資訊洩漏的頁面
* 人工調查後發現只有 44 個易受攻擊的接口，其餘是誤報
* 誤報原因
* 有些以為是調整設備設置，但其實只是查詢設備狀況
* 有些以為是洩漏出帳號的頁面，其實是讓使用者登入或重置密碼的地方

### Performance

* 最快 101 秒完成，最久 3.59 小時
* 大部分時間花費在發請求和等待回應
* 因為使用實體設備，較花時間
* 可以使用模擬器測試，但本論文沒有使用
* 與 Firmadyne 比較，Firmadyne 不但可能會模擬失敗，覆蓋的 Web 路徑也較少，因此找到的漏洞也較少

### Case Studies

#### CVE-2017-5521

* 13 Netgear device
* passwordrecovered.cgi 可獲取路由器密碼

#### CVE-2019-17512

* DIR-412 router of D-Link
* log_clear.php 可清除路由器 Log

### Discussion Scope of detection

* IoTScope 只能檢測基於 URL 的隱藏接口，若需要特定 HTTP 參數才能觸發的就沒辦法檢測

## Related Work

### IoT Device Testing

* FIRMADYNE
* Firmfuzz
* FirmAFL
* IOTFUZZER

### Detection of Broken Access Control

* AutoForge
* AuthScope
* SmartGen

## Conclusion

* 提出 IoTScope，自動公開物聯網設備中 Web 應用程式的隱藏接口
* 成功識別真實世界中 17 個設備中的 44 個漏洞

###### tags: `paper`