物聯網市場正在以爆炸式的增長勢頭飛速發展。隨著裝置規模的不斷增長和業務邏輯的日漸複雜，物聯網平臺基礎設施的安全性也愈發重要。物聯網平臺對協議的具體實現是否完整、對特定訊息的解析過程是否安全就成了重中之重。

這需要面面俱到地針對協議中的繁雜標準和指定的行為規範進行較為完整的測試。同時，考慮到實際使用中可能存在的各種干擾和攻擊，測試過程也需要覆蓋各種非標準異常報文，以分析目標平臺對異常情況的容錯和處理能力。

模糊測試是一個非常有效的測試手段。本文將以 EMQ X 為例，介紹如何使用模糊測試工具來發現 MQTT 伺服器/MQTT 客戶端對協議實現上可能存在的缺陷和漏洞。

## 什麼是模糊測試

模糊測試 （fuzz testing, fuzzing）是一種軟體測試技術。其核心思想是將自動或半自動生成的隨機資料輸入到一個程式中，並監視程式異常，如崩潰、斷言（assertion）失敗，以發現可能的程式錯誤，比如記憶體洩漏。模糊測試常常用於檢測軟體或電腦系統的安全漏洞。

模糊測試可以被用作白盒、灰盒或黑盒測試。通常用於黑盒測試，回報率較高。

> 來源：[https://zh.wikipedia.org/wiki/模糊測試](https://zh.wikipedia.org/wiki/模糊測試)

## 準備工作

### 測試工具及物件選擇

本文我們選擇 Defensics 作為模糊測試的工具。Defensics 是 Synopsys 新思公司開發的黑盒模糊測試工具，提供了對大量檔案格式、網路協議、介面的模糊測試套件。它針對 [MQTT](https://www.emqx.com/zh/mqtt) v3.1 協議標準，使用大量自動生成的 MQTT 資料包對 Broker/Client 進行測試，幫助開發者和測試人員提高軟體的安全性。

> 針對 MQTT v5 的測試套件目前尚未釋出

我們將以開源 MQTT 訊息伺服器 - EMQ X為例，對其協議實現情況進行安全性測試。EMQ X 是由 EMQ 映雲科技開源的大規模可彈性伸縮的雲原生分散式物聯網 MQTT 訊息伺服器，可高效可靠連線海量物聯網裝置，高效能實時處理訊息與事件流資料，助力構建關鍵業務的物聯網平臺與應用。

### 測試環境準備

本次測試在 Arch Linux 環境下進行，滾動更新至最新版本，使用 [EMQX 5.0-beta.2-8be2aaf7](http://github.com/emqx/emqx) 進行測試 。

此外，在進入下一步之前，需要從 Synopsys 處下載 Defensics 的安裝包、字尾名為 `.install` 的測試套件安裝檔案、以及 DEFENSIC 可執行檔案以提供給 FlexNet 許可伺服器驗證 license 狀態使用。

[![下載 Defensics 的安裝包](http://img.blog.itpub.net/blog/2022/02/07/92c6a17f142bb742.png?x-oss-process=style/bb "下載 Defensics 的安裝包")](https://www.emqx.com/zh/blog/mqtt-broker-security-fuzz-testing "下載 Defensics 的安裝包")

### 部署許可伺服器（FlexNet）

Synopsys Defensics 使用 FlexNet 管理許可證照，需要在執行 Defensics 模糊測試器的的網路環境中部署 FlexNet Server ，以管理從 Synopsys 處取得的許可證照（即 `license.lic` 檔案）。

可以選擇使用 Systemd User Unit 在本地部署啟動 FlexNet Daemon ，配置如下。其中 license.lic 證照檔案及 DEFENSIC ( Vendor Daemon )可執行檔案將位於同一目錄。 FlexNet 將會從 $PATH 中搜尋 Vendor Daemon 可執行檔案來進行認證。

當然，在需要更多測試人員使用 Defensics 的情況下，也可以將其部署在專用的證照伺服器上以對更多的使用者提供證照認證服務。其他詳細資訊和具體引數可參考 Defensics 及 FlexNet Publisher 相關文件。

![lmgrd.service Systemd User Unit](http://img.blog.itpub.net/blog/2022/02/07/0c24781f28d288bc.png?x-oss-process=style/bb "lmgrd.service Systemd User Unit")

之後使用命令 `systemctl --user enable --now lmgrd.service` 啟動認證伺服器 Synopsys 提供的 Vendor Daemon。Defensics 便可以透過許可認證開始測試了。

### 其他配置

在 Linux 系統中可能存在顯示問題及字型模糊的情況，可以參考 [Java Runtime Environment fonts - ArchWiki](https://wiki.archlinux.org/title/Java_Runtime_Environment_fonts) 進行配置。

### 安裝 Defensics 及測試套件

以 root 身份執行 `.sh` 安裝程式進行安裝。並且安裝過程中建議勾選啟動指令碼的生成選項 `/usr/local/bin/Defensics` 。

![Defensics 安裝選項](http://img.blog.itpub.net/blog/2022/02/07/4b5a778457180252.png?x-oss-process=style/bb "Defensics 安裝選項")

如果一切順利，啟動 Defensics 後在 `File -> License Manager` 中就可以看到經過驗證的 License 狀態。之後就可以安裝並載入測試套件了。

![Defensics 安裝測試套件](http://img.blog.itpub.net/blog/2022/02/07/7415c5bee4c7c05f.png?x-oss-process=style/bb "Defensics 安裝測試套件")

## Defensics 測試

### 基礎配置

在基礎配置中設定 MQTT Server 的 ip 地址和埠號，以及用於測試的 MQTT Client 配置。

> 其中 MQTT 預設為 1883 埠（在啟用了 TLS/SSL 時為 8883 埠）。

如果 MQTT Server 啟用了客戶端認證或訊息主題許可權，需要對測試用的兩個客戶端進行更詳細的配置。
另外 Defensics 也提供了更進階的 Payload 模糊測試和基於 TLS/SSL 連線的測試。但本次測試僅涉及 MQTT v3.1.1 協議標準相關的模糊測試，所以無需進行配置。

![MQTT Basic Configuration](http://img.blog.itpub.net/blog/2022/02/07/d3848edff6b525f0.png?x-oss-process=style/bb "MQTT Basic Configuration")

在配置了相應的欄位值後，Defensics 將會以指定的 Client ID 、使用者名稱密碼連線 MQTT Server ，並會用指定的 MQTT 主題進行訊息釋出和主題訂閱，即 `PUBLISH` 與 `SUBSCRIBE` 。

對於更高階和複雜的測試，可以使用 `Edit sequence` 功能編輯對應的配置檔案，來改變連線或斷開連線時的行為，例如連線後自動訂閱，連線後立刻釋出訊息等操作。

### 可操作性測試

完成配置後在 `Interoperability` 中進行可操作性測試，來驗證不同的報文能否正常進行傳送接收。在與 MQTT Server 正常連通的情況下，可以執行的測試組將會以綠色標註。

![Defensics Interoperability Test](http://img.blog.itpub.net/blog/2022/02/07/bca11647c9cc2e77.png?x-oss-process=style/bb "Defensics Interoperability Test")

### 高階配置

在這一部分，允許使用者對具體的測試用例執行過程進行配置，但一般來說預設配置已經足夠。

其中包括了對測試用例執行過程的控制，例如超時閾值、重複次數、嘗試次數等。

![Defensics Test Case Run Control](http://img.blog.itpub.net/blog/2022/02/07/e6dc7fd1711d513e.png?x-oss-process=style/bb "Defensics Test Case Run Control")

另外使用者也可以根據實際情況進行網路相關的配置，以獲取在不同網路情景下的測試結果。此時也可以選擇根據 MQTT Server 的目標 IP 進行自動配置。

![Defensics ip 自動配置](http://img.blog.itpub.net/blog/2022/02/07/e0d5021f92318d81.png?x-oss-process=style/bb "Defensics ip 自動配置")

![TCP Conf](http://img.blog.itpub.net/blog/2022/02/07/c1c60f08adbfd0d7.png?x-oss-process=style/bb "TCP Conf")

另外也可以根據 CVSS （通用漏洞評分系統）提供的漏洞分級方法對可能檢測到的異常情況進行評估。

### 儀表配置（Instrumentation）

儀表是指在測試過程中觀察和控制被測系統，觀察的目標是檢測由測試引起的任何故障。儀表還可用於在執行測試時重新啟動或以其他方式控制被測系統。

大多數測試套件都啟用了預設檢測，無需進行額外配置。並且此預設配置的性質因不同的測試套件而異。

### 選擇測試用例

Defensics 對於 MQTT v3.1.1 協議標準，提供了總計超過 100 萬的測試用例可以用來對目標系統進行全面的模糊測試。與此同時，也支援使用者進行基於這些細分的測試用例自行選擇、組合用例，來針對性地聚焦分析並解決問題。

此次我們選取部分用例進行測試，其中包括 `CONNECT-DISCONNECT` `PUBLISH-qos-0` `SUBSCRIBE-qos-0` 三組用例，並同時選擇全部異常訊息用例進行測試。

![Defensics 選擇測試用例](http://img.blog.itpub.net/blog/2022/02/07/ca994578ccd5004d.png?x-oss-process=style/bb "Defensics 選擇測試用例")

在針對於異常訊息的測試中，也可以選擇各類不同資料的異常行為數量和程度進行測試。例如文字、二進位制資料、數字、字元等；同時也可以配置溢位異常的位元組限制來使用值溢位的畸形報文進行測試。

![Sequence anomalies Chosen](http://img.blog.itpub.net/blog/2022/02/07/b234907c7618dfeb.png?x-oss-process=style/bb "Sequence anomalies Chosen")

![Defensics Customize anomalies size](http://img.blog.itpub.net/blog/2022/02/07/617a88d10a9d7d95.png?x-oss-process=style/bb "Defensics Customize anomalies size")

### 執行測試

選擇好測試用例的種類和異常資料的數量，便可以開始測試。本次測試用時約 6 分鐘，其中約 98% 透過測試，約 1%（2779條用例）結果未知。

![Defensics 執行測試](http://img.blog.itpub.net/blog/2022/02/07/7be6a60489c91559.png?x-oss-process=style/bb "Defensics 執行測試")

### 分析儲存結果

我們先來選取其中一條未知結果的異常報文進行分析。

可以看到 Defensics 為了評估被測物件的健壯性，在模糊測試時嘗試使用了不符合協議規範的異常資料進行測試。例如圖中被進行了紅色高亮標註部分，這部份兩位元組資料在 MQTT v3.1.1 協議的 `SUBSCRIBE` 報文中，指示了訂閱主題的 UTF-8 字串的長度。即表示接下來長度 `0x009A` (154位元組)的資料為訂閱主題過濾器的 UTF-8 字串。但該主題過濾器實際長度 18 位元組，值應為 `0x0012` ，與實際長度不符。

按照協議的強制性規範宣告，在此種情況下，服務端必須關閉傳輸這個協議違規控制報文的網路連線**[MQTT-4.8.0-1]。**

但並未具體規定是否必須有指示錯誤原因的報文回傳。所以 EMQ X 僅進行了內部錯誤處理，對異常報文直接丟棄。也不對傳送方進行任何資訊回傳操作，所以 Defensics 將此條結果標記為未知。

但按照協議，**此結果仍然符合要求。**

![Defensics 結果分析](http://img.blog.itpub.net/blog/2022/02/07/61b4cd3083be420c.png?x-oss-process=style/bb "Defensics 結果分析")

經過統計，2779 條結果未知的測試用例中，不同型別的錯誤如下表所示：

| **錯誤型別**                              | **數量** |
| :---------------------------------------- | :------- |
| 報文過大(overflow)                        | 190      |
| 固定報頭錯誤(fixed-header)                | 44       |
| 固定報頭標誌位錯誤(flags)                 | 34       |
| 報文剩餘長度值異常(remaining-length)      | 1167     |
| 報文識別符號異常(packet-identifer)          | 626      |
| 主題過濾器結構錯誤(topic-filters)         | 304      |
| 主題過濾器長度值異常(topic-filter-length) | 414      |

EMQ X 在面對這些異常報文時，直接作了丟棄處理，並未發回關於錯誤資訊的指示報文。

對於其中一部分錯誤型別，由於錯誤點位的資訊比較關鍵，試圖對關鍵資訊邊界進行猜測甚至可能造成更大、更無法接受的錯誤。
例如上面剖析過的字串長度指示值錯誤。如果對主題過濾器及其長度進行猜測，可能會得到錯誤的主題過濾器，造成客戶端得到非預期的主題訂閱。甚至也有可能是主題過濾器長度正確，而主題過濾器的值在傳輸過程中丟失損壞。

這類邏輯錯誤在系統執行中更加難以發現和排查，並且後果更難以接受。所以此時對異常報文直接丟棄成為了更優選擇。

至於其他型別的錯誤，由於錯誤點位過於明顯，相較之下更可能的原因是傳輸過程中的資料丟失、或資料流邊界錯誤導致的異常。所以更傾向於認為這些資料不是 MQTT 報文，也作了丟棄處理，不去耗費額外的資源對這些異常進行處理。

## 總結

本文大致梳理了使用 Synopsys 出品的 Defensics 模糊測試器及配套的 MQTT v3.1 協議測試套件，對 EMQ X 的模糊測試過程，並且選取了部分用例進行測試和結果原因分析。

可以看到 EMQ X 在對協議的實現上非常完整，即使使用大量錯誤報文進行測試也不會導致 EMQ X 失去提供服務的能力，可以保證協議的安全性，為實際專案的穩定執行提供安全保障。

EMQ 致力於為物聯網領域提供高可用、高可靠的 MQTT 訊息伺服器及其他資料基礎設施軟體。在去年，我們也與 Synopsys 達成了合作，該公司將全面負責 EMQ 各產線產品整個生命週期的安全和質量風險管理。我們希望使用者可以透過 EMQ 的產品，構建更加穩定可靠的物聯網平臺與應用。

EMQ X 開源專案也隨時歡迎您的參與，歡迎透過 [GitHub：https://github.com/emqx/emqx](https://github.com/emqx/emqx) 向我們提交 PR 或 Issue。

>版權宣告： 本文為 EMQ 原創，轉載請註明出處。
>
>原文連結：[https://www.emqx.com/zh/blog/mqtt-broker-security-fuzz-testing](https://www.emqx.com/zh/blog/mqtt-broker-security-fuzz-testing)

MQTT 伺服器安全性測試

相關文章