作者 |張淵策上??匕部尚跑浖?chuàng)新研究院工控網(wǎng)絡(luò)安全組
來源 |鑒源實驗室
社群 |添加微信號“TICPShanghai”加入“上??匕?1fusa安全社區(qū)”
隨著物聯(lián)網(wǎng)技術(shù)的快速發(fā)展,越來越多的設(shè)備加入到互聯(lián)網(wǎng)中,形成了龐大的物聯(lián)網(wǎng)系統(tǒng)。這些設(shè)備之間的通信對于物聯(lián)網(wǎng)系統(tǒng)的正常運(yùn)行至關(guān)重要。
MQTT(Message Queuing Telemetry Transport)協(xié)議作為一種輕量級、靈活的消息傳輸協(xié)議,因其簡單易用的特點(diǎn)被廣泛應(yīng)用于物聯(lián)網(wǎng)設(shè)備之間的通信。然而隨著MQTT協(xié)議的普及,其安全性和穩(wěn)定性問題也逐漸突顯出來。攻擊者可以利用協(xié)議本身的漏洞或者錯誤來對系統(tǒng)進(jìn)行攻擊,可能導(dǎo)致系統(tǒng)崩潰、信息泄露等問題。因此,對MQTT協(xié)議進(jìn)行深入研究和測試,發(fā)現(xiàn)潛在的問題并提出解決方案,對于保障物聯(lián)網(wǎng)系統(tǒng)的安全性和穩(wěn)定性具有重要意義。
01 MQTT協(xié)議簡介
MQTT是一種基于發(fā)布/訂閱模式的輕量級消息傳輸協(xié)議,最初由IBM開發(fā)。它采用輕量級的、簡單的消息發(fā)布和訂閱機(jī)制,適用于各種網(wǎng)絡(luò)環(huán)境和設(shè)備。MQTT協(xié)議旨在為物聯(lián)網(wǎng)(IoT)和機(jī)器到機(jī)器(M2M)通信提供一種簡單、輕量級、可靠的解決方案。以下是MQTT協(xié)議的主要特點(diǎn)和工作原理:
(1)MQTT的發(fā)布/訂閱模式
MQTT采用發(fā)布/訂閱模式,其中設(shè)備可以發(fā)布(發(fā)送)消息到特定的主題,同時其他設(shè)備可以訂閱(接收)這些主題的消息。這種模式使得設(shè)備之間的通信變得松耦合,設(shè)備可以獨(dú)立于彼此進(jìn)行通信,而不需要直接相互交互。在通信過程中主要包括三個角色:
·發(fā)布者(Publisher):負(fù)責(zé)發(fā)布消息的設(shè)備或應(yīng)用程序。
·訂閱者(Subscriber):負(fù)責(zé)訂閱感興趣的主題,并接收相關(guān)的消息。
·代理服務(wù)器(Broker):負(fù)責(zé)接收來自發(fā)布者的消息,并將其傳遞給訂閱者。
其中代理服務(wù)器是MQTT通信的中間人。在MQTT通信中需要一個中間人(Broker)來協(xié)調(diào)消息的發(fā)布和訂閱??蛻舳讼駼roker發(fā)送消息,并由Broker負(fù)責(zé)將消息路由給對應(yīng)的訂閱者。具體拓?fù)鋱D見圖1:
圖1MQTT通信拓?fù)鋱D
(2)MQTT報文類型
MQTT協(xié)議通過交換預(yù)定義的MQTT控制報文來通信。MQTT控制報文由固定頭(Fixed Header)、可變頭(Variable Header)和有效載荷(Payload)組成,這使得它易于實現(xiàn)和部署。每個MQTT控制報文都包含一個固定報頭,見表1:
表1 固定報頭格式
MQTT的報文總共有15種報文類型,對于MQTT的報文類型的定義以及各類報文的功能,見表2:
表2 控制報文類型
對于每一類報文,都有專門的報文結(jié)構(gòu)和屬性,由于篇幅原因,不在此過多贅述,具體見MQTT Version 5.0 (oasis-open.org)。
(3)MQTT的連接模式
MQTT的持久連接是指客戶端與服務(wù)器之間的連接能夠保持長期的狀態(tài),這種持久連接的特性是MQTT協(xié)議的一個重要特點(diǎn),它為設(shè)備之間的通信提供了靈活性和效率。在傳統(tǒng)的HTTP通信中,客戶端向服務(wù)器發(fā)送請求后,服務(wù)器響應(yīng)請求后即刻斷開連接,這種請求/響應(yīng)模式在某些場景下效率較低,因為每次通信都需要建立新的連接。而在MQTT中,客戶端與服務(wù)器通過CONNECT報文連接后,即使在沒有數(shù)據(jù)傳輸?shù)那闆r下也能維持連接。為了確保連接的活躍性,客戶端和服務(wù)器之間會定期交換心跳包??蛻舳藭ㄆ诎l(fā)送心跳包給服務(wù)器,告知自己的狀態(tài);服務(wù)器也會定期向客戶端發(fā)送心跳包,確??蛻舳颂幱诨钴S狀態(tài),如圖2。
圖2 MQTT持久連接示意圖
(4)MQTT的訂閱主題
MQTT中客戶端向服務(wù)器發(fā)送SUBSCRIBE報文用于創(chuàng)建一個或多個訂閱。SUBSCRIBE報文支持通配符,也為每個訂閱指定了最大的QoS等級,服務(wù)器根據(jù)這些信息分發(fā)應(yīng)用消息給客戶端。當(dāng)服務(wù)器收到SUBSCRIBE報文,必須回復(fù)SUBACK報文,其中的報文標(biāo)識符要與原始SUBSCRIBE報文相同。如果收到的主題過濾器與現(xiàn)有訂閱相同,則應(yīng)該替換現(xiàn)有訂閱。訂閱的主題過濾器必須是UTF-8字符串,服務(wù)器應(yīng)支持通配符過濾器。每個過濾器后面跟著一個字節(jié),表示請求的最大QoS等級,如圖3。
圖3 MQTT訂閱主題
(5)MQTT的發(fā)布消息
MQTT定義了三個不同的服務(wù)質(zhì)量等級(QoS):
·QoS 0:最多一次交付,消息發(fā)布后不做確認(rèn)。
·QoS 1:至少一次交付,確保消息至少被接收一次。
·QoS 2:恰好一次交付,確保消息僅被接收一次。
QoS值表示應(yīng)用消息分發(fā)的服務(wù)質(zhì)量等級保證。不同的QoS等級決定了PUBLISH控制報文的處理方式。接收者(服務(wù)器或客戶端)必須根據(jù)PUBLISH報文中的QoS等級發(fā)送相應(yīng)的應(yīng)答報文。MQTT根據(jù)QoS等級分發(fā)應(yīng)用消息。當(dāng)服務(wù)器向多個客戶端(訂閱者)分發(fā)消息時,每個客戶端獨(dú)立處理。消息的服務(wù)質(zhì)量可能因訂閱者指定的QoS等級而異。發(fā)布者在發(fā)布消息時指定了服務(wù)質(zhì)量等級。
發(fā)布者必須發(fā)送QoS為0,DUP為0的PUBLISH報文。這種報文服務(wù)器不發(fā)送響應(yīng),發(fā)布者不重試,發(fā)送消息時立即丟棄。消息可能僅送達(dá)一次或根本不送達(dá)。服務(wù)器接收PUBLISH報文后將消息分發(fā)給訂閱該主題的訂閱者。
QoS1的PUBLISH控制報文確保消息至少送達(dá)一次,可能被多次處理??勺儓箢^包含報文標(biāo)識符,需要PUBACK報文確認(rèn)。發(fā)布者必須分配未使用的報文標(biāo)識符,并等待服務(wù)器的PUBACK報文確認(rèn)。發(fā)送的PUBLISH報文必須包含報文標(biāo)識符,QoS為1,DUP為0。如果收到PUBACK報文,發(fā)布者可以重復(fù)使用標(biāo)識符。接收者的PUBACK報文必須包含來自PUBLISH報文的標(biāo)識符。發(fā)送PUBACK后,接收者必須將相同標(biāo)識符的入站PUBLISH報文視為新消息,忽略其DUP標(biāo)志。
QoS2的PUBLISH控制報文提供最高服務(wù)質(zhì)量,不容忍消息丟失和重復(fù)。消息變量頭包含報文標(biāo)識符。接收者使用兩步確認(rèn)過程來確認(rèn)消息。發(fā)送者分配未使用的標(biāo)識符,并等待PUBREC確認(rèn)。收到PUBREC后,發(fā)送PUBREL,并等待PUBCOMP確認(rèn)。發(fā)送PUBREL后不能重發(fā)PUBLISH。接收者發(fā)送PUBREC后可以存儲消息并分發(fā)給訂閱者(方案1),或等待PUBREL后再分發(fā)(方案2)。發(fā)送PUBCOMP后,可以丟棄標(biāo)識符(方案1),或分發(fā)消息并丟棄(方案2)。接收者發(fā)送PUBCOMP后,任何后續(xù)PUBLISH報文被視為新的發(fā)布。
(6)MQTT取消訂閱
客戶端發(fā)送UNSUBSCRIBE報文給服務(wù)器以取消訂閱主題。報文固定報頭的特定位必須設(shè)置為0,0,1,0。有效載荷包含要取消訂閱的主題過濾器列表,必須是UTF-8編碼字符串。UNSUBSCRIBE報文必須至少包含一個有效載荷,包含已訂閱的主題過濾器。服務(wù)器刪除訂閱后不再將該主題的消息發(fā)送給客戶端,并完成任何QoS1和QoS2消息的分發(fā)。服務(wù)器必須發(fā)送UNSUBACK報文作為響應(yīng),包含與UNSUBSCRIBE相同的報文標(biāo)識符。即使沒有刪除任何訂閱,服務(wù)器也必須發(fā)送UNSUBACK響應(yīng)。
圖4 MQTT取消訂閱
(7)MQTT斷開連接
DISCONNECT報文是客戶端發(fā)給服務(wù)端的最后一個控制報文,表示客戶端正常斷開連接。報文的固定報頭保留位必須全為0??蛻舳税l(fā)送DISCONNECT后必須關(guān)閉網(wǎng)絡(luò)連接,不能再發(fā)送其他控制報文。服務(wù)端收到DISCONNECT后,必須丟棄與當(dāng)前連接關(guān)聯(lián)的未發(fā)布的遺囑消息,并在客戶端未關(guān)閉網(wǎng)絡(luò)連接時主動關(guān)閉連接。
圖5 MQTT斷開連接
02 模糊測試技術(shù)
模糊測試(Fuzzing Test)是一種通過將隨機(jī)數(shù)據(jù)(非預(yù)期輸入)輸入到目標(biāo)系統(tǒng)以評估是否會出現(xiàn)非預(yù)期行為的測試方法,已經(jīng)在計算機(jī)網(wǎng)絡(luò)安全測試領(lǐng)域獲得了廣泛應(yīng)用,在自動化漏洞挖掘方面具備優(yōu)異表現(xiàn)。在MQTT協(xié)議的模糊測試中,我們可以通過向MQTT消息中注入異常數(shù)據(jù)或者隨機(jī)生成各種消息格式和內(nèi)容的數(shù)據(jù)包,來測試MQTT服務(wù)器的穩(wěn)定性和安全性。
下面介紹一些通過模糊測試挖掘到的MQTT協(xié)議的CVE漏洞:
(1)數(shù)據(jù)包長度檢測不當(dāng)
網(wǎng)絡(luò)數(shù)據(jù)包是在網(wǎng)絡(luò)上傳輸和接收的格式化數(shù)據(jù)單元。每個MQTT數(shù)據(jù)包通常包含四個主要字段:控制頭部、數(shù)據(jù)包長度、可變頭部和有效載荷。前兩個字段對于每個數(shù)據(jù)包都是必需的,其他字段是可選的。
圖6 MQTT報文包格式[1]
數(shù)據(jù)包解析是提取和識別數(shù)據(jù)包字段的過程。然而,由于數(shù)據(jù)包構(gòu)建方法的進(jìn)步,攻擊者可以利用協(xié)議漏洞來錯誤解析數(shù)據(jù)包,尤其是對于將解析視為順序活動的協(xié)議。很多MQTT協(xié)議棧實現(xiàn)的漏洞都是由于在解析之前缺少或不正確的長度檢查。例如,在CVE-2021-41036中,Eclipse Paho MQTT 客戶端未驗證收到報文中的剩余長度的大小。類似地,在CVE-2020-10071中,Zephyr MQTT解析代碼對已發(fā)布消息的長度字段進(jìn)行不充分的檢查,這可能導(dǎo)致緩沖區(qū)溢出攻擊和遠(yuǎn)程代碼執(zhí)行。還有其他一些漏洞,例如CVE-2020-10070和CVE-2020-10063,它們也是由于不正確的長度檢查而存在。這些漏洞不僅可能導(dǎo)致DoS攻擊,還可能導(dǎo)致其他嚴(yán)重威脅,如遠(yuǎn)程代碼執(zhí)行(RCE)或讀取內(nèi)存內(nèi)容。
(2)缺乏必要字段檢測
缺乏必要字段檢查是由于在協(xié)議實現(xiàn)過程中忽略了對必需字段的驗證而導(dǎo)致的。正如之前所述,在MQTT中,數(shù)據(jù)包長度和數(shù)據(jù)包字段隨著數(shù)據(jù)包類型的不同而變化。因此,應(yīng)該針對數(shù)據(jù)包類型明確實施必需字段檢查的實現(xiàn)。例如,如果一個數(shù)據(jù)包包含用戶名字段,那么相關(guān)的密碼字段也必須存在,因為缺少這樣的密碼部分會使實現(xiàn)處于危險之中。在CVE-2019-9749中,F(xiàn)luent Bit中MQTT輸入插件對一個精心制作的數(shù)據(jù)包的處理導(dǎo)致服務(wù)器崩潰。在CVE-2018-11993中,對MQTT連接請求時訪問堆棧的不當(dāng)檢查導(dǎo)致緩沖區(qū)溢出攻擊。此外,在CVE-2018-8531中,Azure IoT Hub設(shè)備對MQTT協(xié)議內(nèi)存訪問的操作限制不當(dāng)導(dǎo)致遠(yuǎn)程代碼執(zhí)行攻擊。與不正確的必需字段檢查實現(xiàn)缺陷相關(guān)的漏洞包括CVE-2016-9877(MQTT代理對具有有效用戶名但省略密碼部分的連接請求進(jìn)行身份驗證),CVE-2017-2893(MQTT代理在處理沒有訂閱參數(shù)的訂閱數(shù)據(jù)包時崩潰)。
(3)缺少邏輯錯誤檢測
該問題是由于數(shù)據(jù)包中缺乏邏輯錯誤檢查以及實現(xiàn)中未對其進(jìn)行識別而引起的。在CVE-2021-42386中,Busybox在運(yùn)行AWK模式時會導(dǎo)致服務(wù)拒絕。在CVE-2019-9749中,F(xiàn)luent Bit中的MQTT在輸入插件處理特意編輯的數(shù)據(jù)包時會導(dǎo)致服務(wù)器崩潰。在CVE-2018-11998中,處理MQTT中的一個特意制作的數(shù)據(jù)包解碼請求時發(fā)生了一個ace條件,導(dǎo)致緩沖區(qū)溢出攻擊。在CVE-2020-13849中,由于缺乏對客戶端發(fā)送的Keep-Alive值的邏輯檢查,MQTT服務(wù)器受到了拒絕服務(wù)攻擊。在CVE-2019-11778中,當(dāng)處理一個“will delay interval”( 服務(wù)器等待再發(fā)布遺囑消息的時間間隔)大于“session expiry interval”( 客戶端與服務(wù)器之間的會話時間)的數(shù)據(jù)包時,MQTT服務(wù)器會崩潰。
(4)其他錯誤
還有一些CVE漏洞是由于對內(nèi)容類型、數(shù)據(jù)類型、身份驗證繞過、無效證書和無效訪問的錯誤處理。由于不正確處理非UTF-8編碼字符的客戶端ID或主題名稱而導(dǎo)致的漏洞CVE-2020-13932,攻擊者利用了Apache ActiveMQ Artemis 2.5.0到2.13.0(MQTT服務(wù)器)中的一個漏洞,在服務(wù)器接受包含非UTF-8編碼字符的客戶端ID和主題名稱的MQTT數(shù)據(jù)包。通過利用這種漏洞,攻擊者可以執(zhí)行任何易受攻擊的腳本或命令來獲取對MQTT服務(wù)器的訪問權(quán)限,從而允許他進(jìn)行惡意活動。類似地還有與數(shù)據(jù)類型相關(guān)的漏洞,由于變量的不正確初始化,如在CVE-2019-5917中,通過利用Microsoft Azure的MQTT客戶端服務(wù)中的未指定的向量,進(jìn)行了拒絕服務(wù)攻擊。
身份驗證繞過相關(guān)的漏洞,主要利用的是網(wǎng)絡(luò)上傳輸?shù)男畔⑽醇用芎臀淳幋a。例如,在CVE-2019-5635中,由于未加密智能橋設(shè)備與MQTT代理之間的數(shù)據(jù)傳輸,攻擊者使用默認(rèn)用戶名和密碼攻擊了MQTT代理。同樣,無效訪問相關(guān)的漏洞是由于錯誤的文件和對象權(quán)限導(dǎo)致的。例如,在CVE-2018-8531中,報告了Azure IoT Hub設(shè)備訪問內(nèi)存中的對象漏洞,這種情況下攻擊者可以執(zhí)行內(nèi)存損壞的操作。
如果想要自己對MQTT服務(wù)器進(jìn)行模糊測試,可以使用BlitzFuzz工具進(jìn)行操作。BlitzFuzz(點(diǎn)擊查看詳情)作為一款專門針對工控網(wǎng)絡(luò)協(xié)議的滲透模糊測試工具,支持CAN、CAN、UDS、SOME/IP、DoIP等汽車常用協(xié)議的報文仿真、解析功能,提供相關(guān)協(xié)議的滲透測試用例包、合規(guī)測試用例包以及模糊測試功能。
在BlitzFuzz的模糊測試界面中,可以選擇添加MQTT模糊測試用例來對被測件進(jìn)行模糊測試。針對不同的MQTT報文類型,可以選擇不同的MQTT報文類型進(jìn)行參數(shù)配置,選擇變異策略進(jìn)行不同方式的變異策略及模糊數(shù)據(jù)的生成。同時可以配置多種監(jiān)控套件對被測件進(jìn)行監(jiān)控,查看模糊用例對被測件的影響,如圖7。
圖7 BlitzFuzz MQTT模糊配置界面
首先將將被測件通過網(wǎng)線連接BlitzFuzz工具。測試人員在BlitzFuzz前端界面配置需要進(jìn)行模糊的MQTT報文信息及相關(guān)配置,包括被測件的基礎(chǔ)信息如MAC、IP,以及選擇使用的監(jiān)控套件參數(shù),用于判斷被測件發(fā)送的模糊數(shù)據(jù)情況。參數(shù)填寫完成后選擇測試用例并運(yùn)行,運(yùn)行結(jié)束后即可在界面查看測試報告,如圖8。
圖8 BlitzFuzz模糊測試示意圖
參考文獻(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.
審核編輯 黃宇
-
測試
+關(guān)注
關(guān)注
8文章
4926瀏覽量
125948 -
物聯(lián)網(wǎng)
+關(guān)注
關(guān)注
2894文章
43313瀏覽量
366411 -
MQTT
+關(guān)注
關(guān)注
5文章
629瀏覽量
22286
發(fā)布評論請先 登錄
相關(guān)推薦
評論