作者 |張淵策上海控安可信軟件創(chuàng)新研究院工控網(wǎng)絡(luò)安全組

來(lái)源 |鑒源實(shí)驗(yàn)室

社群 |添加微信號(hào)“TICPShanghai”加入“上海控安51fusa安全社區(qū)”

隨著物聯(lián)網(wǎng)技術(shù)的快速發(fā)展，越來(lái)越多的設(shè)備加入到互聯(lián)網(wǎng)中，形成了龐大的物聯(lián)網(wǎng)系統(tǒng)。這些設(shè)備之間的通信對(duì)于物聯(lián)網(wǎng)系統(tǒng)的正常運(yùn)行至關(guān)重要。

MQTT（Message Queuing Telemetry Transport）協(xié)議作為一種輕量級(jí)、靈活的消息傳輸協(xié)議，因其簡(jiǎn)單易用的特點(diǎn)被廣泛應(yīng)用于物聯(lián)網(wǎng)設(shè)備之間的通信。然而隨著MQTT協(xié)議的普及，其安全性和穩(wěn)定性問(wèn)題也逐漸突顯出來(lái)。攻擊者可以利用協(xié)議本身的漏洞或者錯(cuò)誤來(lái)對(duì)系統(tǒng)進(jìn)行攻擊，可能導(dǎo)致系統(tǒng)崩潰、信息泄露等問(wèn)題。因此，對(duì)MQTT協(xié)議進(jìn)行深入研究和測(cè)試，發(fā)現(xiàn)潛在的問(wèn)題并提出解決方案，對(duì)于保障物聯(lián)網(wǎng)系統(tǒng)的安全性和穩(wěn)定性具有重要意義。

01 MQTT協(xié)議簡(jiǎn)介

MQTT是一種基于發(fā)布/訂閱模式的輕量級(jí)消息傳輸協(xié)議，最初由IBM開(kāi)發(fā)。它采用輕量級(jí)的、簡(jiǎn)單的消息發(fā)布和訂閱機(jī)制，適用于各種網(wǎng)絡(luò)環(huán)境和設(shè)備。MQTT協(xié)議旨在為物聯(lián)網(wǎng)（IoT）和機(jī)器到機(jī)器（M2M）通信提供一種簡(jiǎn)單、輕量級(jí)、可靠的解決方案。以下是MQTT協(xié)議的主要特點(diǎn)和工作原理：

（1）MQTT的發(fā)布/訂閱模式

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

·發(fā)布者（Publisher）：負(fù)責(zé)發(fā)布消息的設(shè)備或應(yīng)用程序。

·訂閱者（Subscriber）：負(fù)責(zé)訂閱感興趣的主題，并接收相關(guān)的消息。

·代理服務(wù)器（Broker）：負(fù)責(zé)接收來(lái)自發(fā)布者的消息，并將其傳遞給訂閱者。

其中代理服務(wù)器是MQTT通信的中間人。在MQTT通信中需要一個(gè)中間人（Broker）來(lái)協(xié)調(diào)消息的發(fā)布和訂閱。客戶(hù)端向Broker發(fā)送消息，并由Broker負(fù)責(zé)將消息路由給對(duì)應(yīng)的訂閱者。具體拓?fù)鋱D見(jiàn)圖1：

圖1MQTT通信拓?fù)鋱D

（2）MQTT報(bào)文類(lèi)型

MQTT協(xié)議通過(guò)交換預(yù)定義的MQTT控制報(bào)文來(lái)通信。MQTT控制報(bào)文由固定頭(Fixed Header)、可變頭(Variable Header)和有效載荷(Payload)組成，這使得它易于實(shí)現(xiàn)和部署。每個(gè)MQTT控制報(bào)文都包含一個(gè)固定報(bào)頭，見(jiàn)表1：

表1 固定報(bào)頭格式

MQTT的報(bào)文總共有15種報(bào)文類(lèi)型，對(duì)于MQTT的報(bào)文類(lèi)型的定義以及各類(lèi)報(bào)文的功能，見(jiàn)表2：

表2 控制報(bào)文類(lèi)型

對(duì)于每一類(lèi)報(bào)文，都有專(zhuān)門(mén)的報(bào)文結(jié)構(gòu)和屬性，由于篇幅原因，不在此過(guò)多贅述，具體見(jiàn)MQTT Version 5.0 (oasis-open.org)。

（3）MQTT的連接模式

MQTT的持久連接是指客戶(hù)端與服務(wù)器之間的連接能夠保持長(zhǎng)期的狀態(tài)，這種持久連接的特性是MQTT協(xié)議的一個(gè)重要特點(diǎn)，它為設(shè)備之間的通信提供了靈活性和效率。在傳統(tǒng)的HTTP通信中，客戶(hù)端向服務(wù)器發(fā)送請(qǐng)求后，服務(wù)器響應(yīng)請(qǐng)求后即刻斷開(kāi)連接，這種請(qǐng)求/響應(yīng)模式在某些場(chǎng)景下效率較低，因?yàn)槊看瓮ㄐ哦夹枰⑿碌倪B接。而在MQTT中，客戶(hù)端與服務(wù)器通過(guò)CONNECT報(bào)文連接后，即使在沒(méi)有數(shù)據(jù)傳輸?shù)那闆r下也能維持連接。為了確保連接的活躍性，客戶(hù)端和服務(wù)器之間會(huì)定期交換心跳包。客戶(hù)端會(huì)定期發(fā)送心跳包給服務(wù)器，告知自己的狀態(tài)；服務(wù)器也會(huì)定期向客戶(hù)端發(fā)送心跳包，確保客戶(hù)端處于活躍狀態(tài)，如圖2。

圖2 MQTT持久連接示意圖

（4）MQTT的訂閱主題

MQTT中客戶(hù)端向服務(wù)器發(fā)送SUBSCRIBE報(bào)文用于創(chuàng)建一個(gè)或多個(gè)訂閱。SUBSCRIBE報(bào)文支持通配符，也為每個(gè)訂閱指定了最大的QoS等級(jí)，服務(wù)器根據(jù)這些信息分發(fā)應(yīng)用消息給客戶(hù)端。當(dāng)服務(wù)器收到SUBSCRIBE報(bào)文，必須回復(fù)SUBACK報(bào)文，其中的報(bào)文標(biāo)識(shí)符要與原始SUBSCRIBE報(bào)文相同。如果收到的主題過(guò)濾器與現(xiàn)有訂閱相同，則應(yīng)該替換現(xiàn)有訂閱。訂閱的主題過(guò)濾器必須是UTF-8字符串，服務(wù)器應(yīng)支持通配符過(guò)濾器。每個(gè)過(guò)濾器后面跟著一個(gè)字節(jié)，表示請(qǐng)求的最大QoS等級(jí)，如圖3。

圖3 MQTT訂閱主題

（5）MQTT的發(fā)布消息

MQTT定義了三個(gè)不同的服務(wù)質(zhì)量等級(jí)（QoS）：

·QoS 0：最多一次交付，消息發(fā)布后不做確認(rèn)。

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

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

QoS值表示應(yīng)用消息分發(fā)的服務(wù)質(zhì)量等級(jí)保證。不同的QoS等級(jí)決定了PUBLISH控制報(bào)文的處理方式。接收者（服務(wù)器或客戶(hù)端）必須根據(jù)PUBLISH報(bào)文中的QoS等級(jí)發(fā)送相應(yīng)的應(yīng)答報(bào)文。MQTT根據(jù)QoS等級(jí)分發(fā)應(yīng)用消息。當(dāng)服務(wù)器向多個(gè)客戶(hù)端（訂閱者）分發(fā)消息時(shí)，每個(gè)客戶(hù)端獨(dú)立處理。消息的服務(wù)質(zhì)量可能因訂閱者指定的QoS等級(jí)而異。發(fā)布者在發(fā)布消息時(shí)指定了服務(wù)質(zhì)量等級(jí)。

發(fā)布者必須發(fā)送QoS為0，DUP為0的PUBLISH報(bào)文。這種報(bào)文服務(wù)器不發(fā)送響應(yīng)，發(fā)布者不重試，發(fā)送消息時(shí)立即丟棄。消息可能僅送達(dá)一次或根本不送達(dá)。服務(wù)器接收PUBLISH報(bào)文后將消息分發(fā)給訂閱該主題的訂閱者。

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

QoS2的PUBLISH控制報(bào)文提供最高服務(wù)質(zhì)量，不容忍消息丟失和重復(fù)。消息變量頭包含報(bào)文標(biāo)識(shí)符。接收者使用兩步確認(rèn)過(guò)程來(lái)確認(rèn)消息。發(fā)送者分配未使用的標(biāo)識(shí)符，并等待PUBREC確認(rèn)。收到PUBREC后，發(fā)送PUBREL，并等待PUBCOMP確認(rèn)。發(fā)送PUBREL后不能重發(fā)PUBLISH。接收者發(fā)送PUBREC后可以存儲(chǔ)消息并分發(fā)給訂閱者（方案1），或等待PUBREL后再分發(fā)（方案2）。發(fā)送PUBCOMP后，可以丟棄標(biāo)識(shí)符（方案1），或分發(fā)消息并丟棄（方案2）。接收者發(fā)送PUBCOMP后，任何后續(xù)PUBLISH報(bào)文被視為新的發(fā)布。

（6）MQTT取消訂閱

客戶(hù)端發(fā)送UNSUBSCRIBE報(bào)文給服務(wù)器以取消訂閱主題。報(bào)文固定報(bào)頭的特定位必須設(shè)置為0,0,1,0。有效載荷包含要取消訂閱的主題過(guò)濾器列表，必須是UTF-8編碼字符串。UNSUBSCRIBE報(bào)文必須至少包含一個(gè)有效載荷，包含已訂閱的主題過(guò)濾器。服務(wù)器刪除訂閱后不再將該主題的消息發(fā)送給客戶(hù)端，并完成任何QoS1和QoS2消息的分發(fā)。服務(wù)器必須發(fā)送UNSUBACK報(bào)文作為響應(yīng)，包含與UNSUBSCRIBE相同的報(bào)文標(biāo)識(shí)符。即使沒(méi)有刪除任何訂閱，服務(wù)器也必須發(fā)送UNSUBACK響應(yīng)。

圖4 MQTT取消訂閱

（7）MQTT斷開(kāi)連接

DISCONNECT報(bào)文是客戶(hù)端發(fā)給服務(wù)端的最后一個(gè)控制報(bào)文，表示客戶(hù)端正常斷開(kāi)連接。報(bào)文的固定報(bào)頭保留位必須全為0。客戶(hù)端發(fā)送DISCONNECT后必須關(guān)閉網(wǎng)絡(luò)連接，不能再發(fā)送其他控制報(bào)文。服務(wù)端收到DISCONNECT后，必須丟棄與當(dāng)前連接關(guān)聯(lián)的未發(fā)布的遺囑消息，并在客戶(hù)端未關(guān)閉網(wǎng)絡(luò)連接時(shí)主動(dòng)關(guān)閉連接。

圖5 MQTT斷開(kāi)連接

02 模糊測(cè)試技術(shù)

模糊測(cè)試（Fuzzing Test）是一種通過(guò)將隨機(jī)數(shù)據(jù)（非預(yù)期輸入）輸入到目標(biāo)系統(tǒng)以評(píng)估是否會(huì)出現(xiàn)非預(yù)期行為的測(cè)試方法，已經(jīng)在計(jì)算機(jī)網(wǎng)絡(luò)安全測(cè)試領(lǐng)域獲得了廣泛應(yīng)用，在自動(dòng)化漏洞挖掘方面具備優(yōu)異表現(xiàn)。在MQTT協(xié)議的模糊測(cè)試中，我們可以通過(guò)向MQTT消息中注入異常數(shù)據(jù)或者隨機(jī)生成各種消息格式和內(nèi)容的數(shù)據(jù)包，來(lái)測(cè)試MQTT服務(wù)器的穩(wěn)定性和安全性。

下面介紹一些通過(guò)模糊測(cè)試挖掘到的MQTT協(xié)議的CVE漏洞：

（1）數(shù)據(jù)包長(zhǎng)度檢測(cè)不當(dāng)

網(wǎng)絡(luò)數(shù)據(jù)包是在網(wǎng)絡(luò)上傳輸和接收的格式化數(shù)據(jù)單元。每個(gè)MQTT數(shù)據(jù)包通常包含四個(gè)主要字段：控制頭部、數(shù)據(jù)包長(zhǎng)度、可變頭部和有效載荷。前兩個(gè)字段對(duì)于每個(gè)數(shù)據(jù)包都是必需的，其他字段是可選的。

圖6 MQTT報(bào)文包格式[1]

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

（2）缺乏必要字段檢測(cè)

缺乏必要字段檢查是由于在協(xié)議實(shí)現(xiàn)過(guò)程中忽略了對(duì)必需字段的驗(yàn)證而導(dǎo)致的。正如之前所述，在MQTT中，數(shù)據(jù)包長(zhǎng)度和數(shù)據(jù)包字段隨著數(shù)據(jù)包類(lèi)型的不同而變化。因此，應(yīng)該針對(duì)數(shù)據(jù)包類(lèi)型明確實(shí)施必需字段檢查的實(shí)現(xiàn)。例如，如果一個(gè)數(shù)據(jù)包包含用戶(hù)名字段，那么相關(guān)的密碼字段也必須存在，因?yàn)槿鄙龠@樣的密碼部分會(huì)使實(shí)現(xiàn)處于危險(xiǎn)之中。在CVE-2019-9749中，F(xiàn)luent Bit中MQTT輸入插件對(duì)一個(gè)精心制作的數(shù)據(jù)包的處理導(dǎo)致服務(wù)器崩潰。在CVE-2018-11993中，對(duì)MQTT連接請(qǐng)求時(shí)訪(fǎng)問(wèn)堆棧的不當(dāng)檢查導(dǎo)致緩沖區(qū)溢出攻擊。此外，在CVE-2018-8531中，Azure IoT Hub設(shè)備對(duì)MQTT協(xié)議內(nèi)存訪(fǎng)問(wèn)的操作限制不當(dāng)導(dǎo)致遠(yuǎn)程代碼執(zhí)行攻擊。與不正確的必需字段檢查實(shí)現(xiàn)缺陷相關(guān)的漏洞包括CVE-2016-9877（MQTT代理對(duì)具有有效用戶(hù)名但省略密碼部分的連接請(qǐng)求進(jìn)行身份驗(yàn)證），CVE-2017-2893（MQTT代理在處理沒(méi)有訂閱參數(shù)的訂閱數(shù)據(jù)包時(shí)崩潰）。

（3）缺少邏輯錯(cuò)誤檢測(cè)

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

（4）其他錯(cuò)誤

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

身份驗(yàn)證繞過(guò)相關(guān)的漏洞，主要利用的是網(wǎng)絡(luò)上傳輸?shù)男畔⑽醇用芎臀淳幋a。例如，在CVE-2019-5635中，由于未加密智能橋設(shè)備與MQTT代理之間的數(shù)據(jù)傳輸，攻擊者使用默認(rèn)用戶(hù)名和密碼攻擊了MQTT代理。同樣，無(wú)效訪(fǎng)問(wèn)相關(guān)的漏洞是由于錯(cuò)誤的文件和對(duì)象權(quán)限導(dǎo)致的。例如，在CVE-2018-8531中，報(bào)告了Azure IoT Hub設(shè)備訪(fǎng)問(wèn)內(nèi)存中的對(duì)象漏洞，這種情況下攻擊者可以執(zhí)行內(nèi)存損壞的操作。

如果想要自己對(duì)MQTT服務(wù)器進(jìn)行模糊測(cè)試，可以使用BlitzFuzz工具進(jìn)行操作。BlitzFuzz（點(diǎn)擊查看詳情）作為一款專(zhuān)門(mén)針對(duì)工控網(wǎng)絡(luò)協(xié)議的滲透模糊測(cè)試工具，支持CAN、CAN、UDS、SOME/IP、DoIP等汽車(chē)常用協(xié)議的報(bào)文仿真、解析功能，提供相關(guān)協(xié)議的滲透測(cè)試用例包、合規(guī)測(cè)試用例包以及模糊測(cè)試功能。

在BlitzFuzz的模糊測(cè)試界面中，可以選擇添加MQTT模糊測(cè)試用例來(lái)對(duì)被測(cè)件進(jìn)行模糊測(cè)試。針對(duì)不同的MQTT報(bào)文類(lèi)型，可以選擇不同的MQTT報(bào)文類(lèi)型進(jìn)行參數(shù)配置，選擇變異策略進(jìn)行不同方式的變異策略及模糊數(shù)據(jù)的生成。同時(shí)可以配置多種監(jiān)控套件對(duì)被測(cè)件進(jìn)行監(jiān)控，查看模糊用例對(duì)被測(cè)件的影響，如圖7。

圖7 BlitzFuzz MQTT模糊配置界面

首先將將被測(cè)件通過(guò)網(wǎng)線(xiàn)連接BlitzFuzz工具。測(cè)試人員在BlitzFuzz前端界面配置需要進(jìn)行模糊的MQTT報(bào)文信息及相關(guān)配置，包括被測(cè)件的基礎(chǔ)信息如MAC、IP，以及選擇使用的監(jiān)控套件參數(shù)，用于判斷被測(cè)件發(fā)送的模糊數(shù)據(jù)情況。參數(shù)填寫(xiě)完成后選擇測(cè)試用例并運(yùn)行，運(yùn)行結(jié)束后即可在界面查看測(cè)試報(bào)告，如圖8。

圖8 BlitzFuzz模糊測(cè)試示意圖

參考文獻(xiàn)：

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

審核編輯 黃宇