博客
MQTT 服務器安全性測試
物聯網市場正在以爆炸式的增長勢頭飛速發展。隨著設備規模的不斷增長和業務邏輯的日漸復雜，物聯網平臺基礎設施的安全性也愈發重要。物聯網平臺對協議的具體實現是否完整、對特定消息的解析過程是否安全就成了重中之重。
這需要面面俱到地針對協議中的繁雜標準和指定的行為規范進行較為完整的測試。同時，考慮到實際使用中可能存在的各種干擾和攻擊，測試過程也需要覆蓋各種非標準異常報文，以分析目標平臺對異常情況的容錯和處理能力。
模糊測試是一個非常有效的測試手段。本文將以 EMQX 為例，介紹如何使用模糊測試工具來發現 MQTT 服務器/MQTT 客戶端對協議實現上可能存在的缺陷和漏洞。
什么是模糊測試模糊測試 （fuzz testing, fuzzing）是一種軟件測試技術。其核心思想是將自動或半自動生成的隨機數據輸入到一個程序中，并監視程序異常，如崩潰、斷言（assertion）失敗，以發現可能的程序錯誤，比如內存泄漏。模糊測試常常用于檢測軟件或電腦系統的安全漏洞。
模糊測試可以被用作白盒、灰盒或黑盒測試。通常用于黑盒測試，回報率較高。
準備工作測試工具及對象選擇
本文我們選擇 Defensics 作為模糊測試的工具。Defensics 是 Synopsys 新思公司開發的黑盒模糊測試工具，提供了對大量文件格式、網絡協議、接口的模糊測試套件。它針對 MQTT v3.1 協議標準，使用大量自動生成的 MQTT 數據包對 Broker/Client 進行測試，幫助開發者和測試人員提高軟件的安全性。
針對 MQTT v5 的測試套件目前尚未發布
我們將以開源 MQTT 消息服務器 - EMQX 為例，對其協議實現情況進行安全性測試。EMQX 是由 EMQ 映云科技 開源的大規模可彈性伸縮的云原生分布式物聯網 MQTT 消息服務器，可高效可靠連接海量物聯網設備，高性能實時處理消息與事件流數據，助力構建關鍵業務的物聯網平臺與應用。
測試環境準備本次測試在 Arch Linux 環境下進行，滾動更新至最新版本，使用 EMQX 5.0-beta.2-8be2aaf7 進行測試 。
此外，在進入下一步之前，需要從 Synopsys 處下載 Defensics 的安裝包、后綴名為 .install 的測試套件安裝文件、以及 DEFENSIC 可執行文件以提供給 FlexNet 許可服務器驗證 license 狀態使用。
下載文件列表
部署許可服務器（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
之后使用命令 systemctl --user enable --now lmgrd.service 啟動認證服務器 Synopsys 提供的 Vendor Daemon。Defensics 便可以通過許可認證開始測試了。
其他配置在 Linux 系統中可能存在顯示問題及字體模糊的情況，可以參考 Java Runtime Environment fonts - ArchWiki 進行配置。
安裝 Defensics 及測試套件以 root 身份執行 .sh 安裝程序進行安裝。并且安裝過程中建議勾選啟動腳本的生成選項 /usr/local/bin/Defensics 。
安裝選項
如果一切順利，啟動 Defensics 后在 File -> License Manager 中就可以看到經過驗證的 License 狀態。之后就可以安裝并加載測試套件了。
安裝測試套件
Defensics 測試基礎配置在基礎配置中設置 MQTT Server 的 ip 地址和端口號，以及用于測試的 MQTT Client 配置。
其中 MQTT 默認為 1883 端口（在啟用了 TLS/SSL 時為 8883 端口）。
如果 MQTT Server 啟用了客戶端認證或消息主題權限，需要對測試用的兩個客戶端進行更詳細的配置。 另外 Defensics 也提供了更進階的 Payload 模糊測試和基于 TLS/SSL 連接的測試。但本次測試僅涉及 MQTT v3.1.1 協議標準相關的模糊測試，所以無需進行配置。
Basic Configuration
在配置了相應的字段值后，Defensics 將會以指定的 Client ID 、用戶名密碼連接 MQTT Server ，并會用指定的 MQTT 主題進行消息發布和主題訂閱，即 PUBLISH 與 SUBSCRIBE 。
對于更高階和復雜的測試，可以使用 Edit sequence 功能編輯對應的配置文件，來改變連接或斷開連接時的行為，例如連接后自動訂閱，連接后立刻發布消息等操作。
可操作性測試完成配置后在 Interoperability 中進行可操作性測試，來驗證不同的報文能否正常進行發送接收。在與 MQTT Server 正常連通的情況下，可以執行的測試組將會以綠色標注。
Interoperability Test
高級配置在這一部分，允許用戶對具體的測試用例執行過程進行配置，但一般來說默認配置已經足夠。
其中包括了對測試用例執行過程的控制，例如超時閾值、重復次數、嘗試次數等。
Test Case Run Control
另外用戶也可以根據實際情況進行網絡相關的配置，以獲取在不同網絡情景下的測試結果。此時也可以選擇根據 MQTT Server 的目標 IP 進行自動配置。
Capture Conf
TCP Conf
另外也可以根據 CVSS （通用漏洞評分系統）提供的漏洞分級方法對可能檢測到的異常情況進行評估。
儀表配置（Instrumentation）儀表是指在測試過程中觀察和控制被測系統，觀察的目標是檢測由測試引起的任何故障。儀表還可用于在運行測試時重新啟動或以其他方式控制被測系統。
大多數測試套件都啟用了默認檢測，無需進行額外配置。并且此默認配置的性質因不同的測試套件而異。
選擇測試用例Defensics 對于 MQTT v3.1.1 協議標準，提供了總計超過 100 萬的測試用例可以用來對目標系統進行全面的模糊測試。與此同時，也支持用戶進行基于這些細分的測試用例自行選擇、組合用例，來針對性地聚焦分析并解決問題。
此次我們選取部分用例進行測試，其中包括 CONNECT-DISCONNECT PUBLISH-qos-0 SUBSCRIBE-qos-0 三組用例，并同時選擇全部異常消息用例進行測試。
Test Case Chosen
在針對于異常消息的測試中，也可以選擇各類不同數據的異常行為數量和程度進行測試。例如文本、二進制數據、數字、字符等；同時也可以配置溢出異常的字節限制來使用值溢出的畸形報文進行測試。
Sequence anomalies Chosen
Customize anomalies size
執行測試選擇好測試用例的種類和異常數據的數量，便可以開始測試。本次測試用時約 6 分鐘，其中約 98% 通過測試，約 1%（2779條用例）結果未知。
Run time 06:03
分析保存結果我們先來選取其中一條未知結果的異常報文進行分析。
可以看到 Defensics 為了評估被測對象的健壯性，在模糊測試時嘗試使用了不符合協議規范的異常數據進行測試。例如圖中被進行了紅色高亮標注部分，這部份兩字節數據在 MQTT v3.1.1 協議的 SUBSCRIBE 報文中，指示了訂閱主題的 UTF-8 字符串的長度。即表示接下來長度 0x009A (154字節)的數據為訂閱主題過濾器的 UTF-8 字符串。但該主題過濾器實際長度 18 字節，值應為 0x0012 ，與實際長度不符。
按照協議的強制性規范聲明，在此種情況下，服務端必須關閉傳輸這個協議違規控制報文的網絡連接[MQTT-4.8.0-1]。
但并未具體規定是否必須有指示錯誤原因的報文回傳。所以 EMQX 僅進行了內部錯誤處理，對異常報文直接丟棄。也不對發送方進行任何信息回傳操作，所以 Defensics 將此條結果標記為未知。
但按照協議，此結果仍然符合要求。
Malformed Subscribe Packet
經過統計，2779 條結果未知的測試用例中，不同類型的錯誤如下表所示：
| 錯誤類型 | 數量 |
|---|---|
| 報文過大(overflow) | 190 |
| 固定報頭錯誤(fixed-header) | 44 |
| 固定報頭標志位錯誤(flags) | 34 |
| 報文剩余長度值異常(remaining-length) | 1167 |
| 報文標識符異常(packet-identifer) | 626 |
| 主題過濾器結構錯誤(topic-filters) | 304 |
| 主題過濾器長度值異常(topic-filter-length) | 414 |
EMQX 在面對這些異常報文時，直接作了丟棄處理，并未發回關于錯誤信息的指示報文。
對于其中一部分錯誤類型，由于錯誤點位的信息比較關鍵，試圖對關鍵信息邊界進行猜測甚至可能造成更大、更無法接受的錯誤。 例如上面剖析過的字符串長度指示值錯誤。如果對主題過濾器及其長度進行猜測，可能會得到錯誤的主題過濾器，造成客戶端得到非預期的主題訂閱。甚至也有可能是主題過濾器長度正確，而主題過濾器的值在傳輸過程中丟失損壞。
這類邏輯錯誤在系統運行中更加難以發現和排查，并且后果更難以接受。所以此時對異常報文直接丟棄成為了更優選擇。
至于其他類型的錯誤，由于錯誤點位過于明顯，相較之下更可能的原因是傳輸過程中的數據丟失、或數據流邊界錯誤導致的異常。所以更傾向于認為這些數據不是 MQTT 報文，也作了丟棄處理，不去耗費額外的資源對這些異常進行處理。
總結本文大致梳理了使用 Synopsys 出品的 Defensics 模糊測試器及配套的 MQTT v3.1 協議測試套件，對 EMQX 的模糊測試過程，并且選取了部分用例進行測試和結果原因分析。
可以看到 EMQX 在對協議的實現上非常完整，即使使用大量錯誤報文進行測試也不會導致 EMQX 失去提供服務的能力，可以保證協議的安全性，為實際項目的穩定運行提供安全保障。
EMQ 致力于為物聯網領域提供高可用、高可靠的 MQTT 消息服務器及其他數據基礎設施軟件。在去年，我們也與 Synopsys 達成了合作，該公司將全面負責 EMQ 各產線產品整個生命周期的安全和質量風險管理。我們希望用戶可以通過 EMQ 的產品，構建更加穩定可靠的物聯網平臺與應用。
EMQX 開源項目也隨時歡迎您的參與，歡迎通過 GitHub：https://github.com/emqx/emqx 向我們提交 PR 或 Issue。
原創文章，作者：EMQ，如若轉載，請注明出處：https://www.emqx.com/zh/blog/mqtt-broker-security-fuzz-testing
