作者 |張淵策上海控安可信軟件創新研究院工控網絡安全組

來源 |鑒源實驗室

社群 |添加微信號“TICPShanghai”加入“上海控安51fusa安全社區”

隨著物聯網技術的快速發展，越來越多的設備加入到互聯網中，形成了龐大的物聯網系統。這些設備之間的通信對于物聯網系統的正常運行至關重要。

MQTT（Message Queuing Telemetry Transport）協議作為一種輕量級、靈活的消息傳輸協議，因其簡單易用的特點被廣泛應用于物聯網設備之間的通信。然而隨著MQTT協議的普及，其安全性和穩定性問題也逐漸突顯出來。攻擊者可以利用協議本身的漏洞或者錯誤來對系統進行攻擊，可能導致系統崩潰、信息泄露等問題。因此，對MQTT協議進行深入研究和測試，發現潛在的問題并提出解決方案，對于保障物聯網系統的安全性和穩定性具有重要意義。

01 MQTT協議簡介

MQTT是一種基于發布/訂閱模式的輕量級消息傳輸協議，最初由IBM開發。它采用輕量級的、簡單的消息發布和訂閱機制，適用于各種網絡環境和設備。MQTT協議旨在為物聯網（IoT）和機器到機器（M2M）通信提供一種簡單、輕量級、可靠的解決方案。以下是MQTT協議的主要特點和工作原理：

（1）MQTT的發布/訂閱模式

MQTT采用發布/訂閱模式，其中設備可以發布（發送）消息到特定的主題，同時其他設備可以訂閱（接收）這些主題的消息。這種模式使得設備之間的通信變得松耦合，設備可以獨立于彼此進行通信，而不需要直接相互交互。在通信過程中主要包括三個角色：

·發布者（Publisher）：負責發布消息的設備或應用程序。

·訂閱者（Subscriber）：負責訂閱感興趣的主題，并接收相關的消息。

·代理服務器（Broker）：負責接收來自發布者的消息，并將其傳遞給訂閱者。

其中代理服務器是MQTT通信的中間人。在MQTT通信中需要一個中間人（Broker）來協調消息的發布和訂閱?？蛻舳讼駼roker發送消息，并由Broker負責將消息路由給對應的訂閱者。具體拓撲圖見圖1：

圖1MQTT通信拓撲圖

（2）MQTT報文類型

MQTT協議通過交換預定義的MQTT控制報文來通信。MQTT控制報文由固定頭(Fixed Header)、可變頭(Variable Header)和有效載荷(Payload)組成，這使得它易于實現和部署。每個MQTT控制報文都包含一個固定報頭，見表1：

表1 固定報頭格式

MQTT的報文總共有15種報文類型，對于MQTT的報文類型的定義以及各類報文的功能，見表2：

表2 控制報文類型

對于每一類報文，都有專門的報文結構和屬性，由于篇幅原因，不在此過多贅述，具體見MQTT Version 5.0 (oasis-open.org)。

（3）MQTT的連接模式

MQTT的持久連接是指客戶端與服務器之間的連接能夠保持長期的狀態，這種持久連接的特性是MQTT協議的一個重要特點，它為設備之間的通信提供了靈活性和效率。在傳統的HTTP通信中，客戶端向服務器發送請求后，服務器響應請求后即刻斷開連接，這種請求/響應模式在某些場景下效率較低，因為每次通信都需要建立新的連接。而在MQTT中，客戶端與服務器通過CONNECT報文連接后，即使在沒有數據傳輸的情況下也能維持連接。為了確保連接的活躍性，客戶端和服務器之間會定期交換心跳包?？蛻舳藭ㄆ诎l送心跳包給服務器，告知自己的狀態；服務器也會定期向客戶端發送心跳包，確?？蛻舳颂幱诨钴S狀態，如圖2。

圖2 MQTT持久連接示意圖

（4）MQTT的訂閱主題

MQTT中客戶端向服務器發送SUBSCRIBE報文用于創建一個或多個訂閱。SUBSCRIBE報文支持通配符，也為每個訂閱指定了最大的QoS等級，服務器根據這些信息分發應用消息給客戶端。當服務器收到SUBSCRIBE報文，必須回復SUBACK報文，其中的報文標識符要與原始SUBSCRIBE報文相同。如果收到的主題過濾器與現有訂閱相同，則應該替換現有訂閱。訂閱的主題過濾器必須是UTF-8字符串，服務器應支持通配符過濾器。每個過濾器后面跟著一個字節，表示請求的最大QoS等級，如圖3。

圖3 MQTT訂閱主題

（5）MQTT的發布消息

MQTT定義了三個不同的服務質量等級（QoS）：

·QoS 0：最多一次交付，消息發布后不做確認。

·QoS 1：至少一次交付，確保消息至少被接收一次。

·QoS 2：恰好一次交付，確保消息僅被接收一次。

QoS值表示應用消息分發的服務質量等級保證。不同的QoS等級決定了PUBLISH控制報文的處理方式。接收者（服務器或客戶端）必須根據PUBLISH報文中的QoS等級發送相應的應答報文。MQTT根據QoS等級分發應用消息。當服務器向多個客戶端（訂閱者）分發消息時，每個客戶端獨立處理。消息的服務質量可能因訂閱者指定的QoS等級而異。發布者在發布消息時指定了服務質量等級。

發布者必須發送QoS為0，DUP為0的PUBLISH報文。這種報文服務器不發送響應，發布者不重試，發送消息時立即丟棄。消息可能僅送達一次或根本不送達。服務器接收PUBLISH報文后將消息分發給訂閱該主題的訂閱者。

QoS1的PUBLISH控制報文確保消息至少送達一次，可能被多次處理。可變報頭包含報文標識符，需要PUBACK報文確認。發布者必須分配未使用的報文標識符，并等待服務器的PUBACK報文確認。發送的PUBLISH報文必須包含報文標識符，QoS為1，DUP為0。如果收到PUBACK報文，發布者可以重復使用標識符。接收者的PUBACK報文必須包含來自PUBLISH報文的標識符。發送PUBACK后，接收者必須將相同標識符的入站PUBLISH報文視為新消息，忽略其DUP標志。

QoS2的PUBLISH控制報文提供最高服務質量，不容忍消息丟失和重復。消息變量頭包含報文標識符。接收者使用兩步確認過程來確認消息。發送者分配未使用的標識符，并等待PUBREC確認。收到PUBREC后，發送PUBREL，并等待PUBCOMP確認。發送PUBREL后不能重發PUBLISH。接收者發送PUBREC后可以存儲消息并分發給訂閱者（方案1），或等待PUBREL后再分發（方案2）。發送PUBCOMP后，可以丟棄標識符（方案1），或分發消息并丟棄（方案2）。接收者發送PUBCOMP后，任何后續PUBLISH報文被視為新的發布。

（6）MQTT取消訂閱

客戶端發送UNSUBSCRIBE報文給服務器以取消訂閱主題。報文固定報頭的特定位必須設置為0,0,1,0。有效載荷包含要取消訂閱的主題過濾器列表，必須是UTF-8編碼字符串。UNSUBSCRIBE報文必須至少包含一個有效載荷，包含已訂閱的主題過濾器。服務器刪除訂閱后不再將該主題的消息發送給客戶端，并完成任何QoS1和QoS2消息的分發。服務器必須發送UNSUBACK報文作為響應，包含與UNSUBSCRIBE相同的報文標識符。即使沒有刪除任何訂閱，服務器也必須發送UNSUBACK響應。

圖4 MQTT取消訂閱

（7）MQTT斷開連接

DISCONNECT報文是客戶端發給服務端的最后一個控制報文，表示客戶端正常斷開連接。報文的固定報頭保留位必須全為0?？蛻舳税l送DISCONNECT后必須關閉網絡連接，不能再發送其他控制報文。服務端收到DISCONNECT后，必須丟棄與當前連接關聯的未發布的遺囑消息，并在客戶端未關閉網絡連接時主動關閉連接。

圖5 MQTT斷開連接

02 模糊測試技術

模糊測試（Fuzzing Test）是一種通過將隨機數據（非預期輸入）輸入到目標系統以評估是否會出現非預期行為的測試方法，已經在計算機網絡安全測試領域獲得了廣泛應用，在自動化漏洞挖掘方面具備優異表現。在MQTT協議的模糊測試中，我們可以通過向MQTT消息中注入異常數據或者隨機生成各種消息格式和內容的數據包，來測試MQTT服務器的穩定性和安全性。

下面介紹一些通過模糊測試挖掘到的MQTT協議的CVE漏洞：

（1）數據包長度檢測不當

網絡數據包是在網絡上傳輸和接收的格式化數據單元。每個MQTT數據包通常包含四個主要字段：控制頭部、數據包長度、可變頭部和有效載荷。前兩個字段對于每個數據包都是必需的，其他字段是可選的。

圖6 MQTT報文包格式[1]

數據包解析是提取和識別數據包字段的過程。然而，由于數據包構建方法的進步，攻擊者可以利用協議漏洞來錯誤解析數據包，尤其是對于將解析視為順序活動的協議。很多MQTT協議棧實現的漏洞都是由于在解析之前缺少或不正確的長度檢查。例如，在CVE-2021-41036中，Eclipse Paho MQTT 客戶端未驗證收到報文中的剩余長度的大小。類似地，在CVE-2020-10071中，Zephyr MQTT解析代碼對已發布消息的長度字段進行不充分的檢查，這可能導致緩沖區溢出攻擊和遠程代碼執行。還有其他一些漏洞，例如CVE-2020-10070和CVE-2020-10063，它們也是由于不正確的長度檢查而存在。這些漏洞不僅可能導致DoS攻擊，還可能導致其他嚴重威脅，如遠程代碼執行（RCE）或讀取內存內容。

（2）缺乏必要字段檢測

缺乏必要字段檢查是由于在協議實現過程中忽略了對必需字段的驗證而導致的。正如之前所述，在MQTT中，數據包長度和數據包字段隨著數據包類型的不同而變化。因此，應該針對數據包類型明確實施必需字段檢查的實現。例如，如果一個數據包包含用戶名字段，那么相關的密碼字段也必須存在，因為缺少這樣的密碼部分會使實現處于危險之中。在CVE-2019-9749中，Fluent Bit中MQTT輸入插件對一個精心制作的數據包的處理導致服務器崩潰。在CVE-2018-11993中，對MQTT連接請求時訪問堆棧的不當檢查導致緩沖區溢出攻擊。此外，在CVE-2018-8531中，Azure IoT Hub設備對MQTT協議內存訪問的操作限制不當導致遠程代碼執行攻擊。與不正確的必需字段檢查實現缺陷相關的漏洞包括CVE-2016-9877（MQTT代理對具有有效用戶名但省略密碼部分的連接請求進行身份驗證），CVE-2017-2893（MQTT代理在處理沒有訂閱參數的訂閱數據包時崩潰）。

（3）缺少邏輯錯誤檢測

該問題是由于數據包中缺乏邏輯錯誤檢查以及實現中未對其進行識別而引起的。在CVE-2021-42386中，Busybox在運行AWK模式時會導致服務拒絕。在CVE-2019-9749中，Fluent Bit中的MQTT在輸入插件處理特意編輯的數據包時會導致服務器崩潰。在CVE-2018-11998中，處理MQTT中的一個特意制作的數據包解碼請求時發生了一個ace條件，導致緩沖區溢出攻擊。在CVE-2020-13849中，由于缺乏對客戶端發送的Keep-Alive值的邏輯檢查，MQTT服務器受到了拒絕服務攻擊。在CVE-2019-11778中，當處理一個“will delay interval”（ 服務器等待再發布遺囑消息的時間間隔）大于“session expiry interval”（ 客戶端與服務器之間的會話時間）的數據包時，MQTT服務器會崩潰。

（4）其他錯誤

還有一些CVE漏洞是由于對內容類型、數據類型、身份驗證繞過、無效證書和無效訪問的錯誤處理。由于不正確處理非UTF-8編碼字符的客戶端ID或主題名稱而導致的漏洞CVE-2020-13932，攻擊者利用了Apache ActiveMQ Artemis 2.5.0到2.13.0（MQTT服務器）中的一個漏洞，在服務器接受包含非UTF-8編碼字符的客戶端ID和主題名稱的MQTT數據包。通過利用這種漏洞，攻擊者可以執行任何易受攻擊的腳本或命令來獲取對MQTT服務器的訪問權限，從而允許他進行惡意活動。類似地還有與數據類型相關的漏洞，由于變量的不正確初始化，如在CVE-2019-5917中，通過利用Microsoft Azure的MQTT客戶端服務中的未指定的向量，進行了拒絕服務攻擊。

身份驗證繞過相關的漏洞，主要利用的是網絡上傳輸的信息未加密和未編碼。例如，在CVE-2019-5635中，由于未加密智能橋設備與MQTT代理之間的數據傳輸，攻擊者使用默認用戶名和密碼攻擊了MQTT代理。同樣，無效訪問相關的漏洞是由于錯誤的文件和對象權限導致的。例如，在CVE-2018-8531中，報告了Azure IoT Hub設備訪問內存中的對象漏洞，這種情況下攻擊者可以執行內存損壞的操作。

如果想要自己對MQTT服務器進行模糊測試，可以使用BlitzFuzz工具進行操作。BlitzFuzz（點擊查看詳情）作為一款專門針對工控網絡協議的滲透模糊測試工具，支持CAN、CAN、UDS、SOME/IP、DoIP等汽車常用協議的報文仿真、解析功能，提供相關協議的滲透測試用例包、合規測試用例包以及模糊測試功能。

在BlitzFuzz的模糊測試界面中，可以選擇添加MQTT模糊測試用例來對被測件進行模糊測試。針對不同的MQTT報文類型，可以選擇不同的MQTT報文類型進行參數配置，選擇變異策略進行不同方式的變異策略及模糊數據的生成。同時可以配置多種監控套件對被測件進行監控，查看模糊用例對被測件的影響，如圖7。

圖7 BlitzFuzz MQTT模糊配置界面

首先將將被測件通過網線連接BlitzFuzz工具。測試人員在BlitzFuzz前端界面配置需要進行模糊的MQTT報文信息及相關配置，包括被測件的基礎信息如MAC、IP，以及選擇使用的監控套件參數，用于判斷被測件發送的模糊數據情況。參數填寫完成后選擇測試用例并運行，運行結束后即可在界面查看測試報告，如圖8。

圖8 BlitzFuzz模糊測試示意圖

參考文獻：

[1]Husnain M, Hayat K, Cambiaso E, et al. Preventing mqtt vulnerabilities using iot-enabled intrusion detection system[J]. Sensors, 2022, 22(2): 567.

[2] Hwang, H. C., Park, J., & Shon, J. G. (2016). Design and implementation of a reliable message transmission system based on MQTT protocol in IoT.

[3] Soni D, Makwana A. A survey on mqtt: a protocol of internet of things (iot)[C]//International conference on telecommunication, power analysis and computing techniques (ICTPACT-2017). 2017, 20: 173-177.

[4] Singh M, Rajan M A, Shivraj V L, et al. Secure mqtt for internet of things (iot)[C]//2015 fifth international conference on communication systems and network technologies. IEEE, 2015: 746-751.

審核編輯 黃宇