文 年華 | 圖 lmn

出處:

https://mp.weixin.qq.com/s?__biz=MzUzMjcxMzg5Mg==&mid=2247487921&idx=1&sn=dabc68501c368eef0434bc16bd01dfa4

隨著物聯網的快速發展，當前在物聯網中的常見的五種協議分別是：HTTP、CoAP、XMPP、AMQP、MQTT。但在這麼多協議中，毫無疑問MQTT最具代表性,因為它 佔用頻寬小 、 輕量級 、 簡單易用 等優點最符合物聯網的應用場景。可以毫不誇張的說：每個物聯網開發人員都一定了解MQTT

今天我們將從三個方面來探討一下MQTT的安全性，分別是 登陸認證問題 、 許可權控制問題 以及 Broker自身安全性 的問題（不知道什麼是Broker沒關係，接著往下看就是了）， 如果師傅已經瞭解了MQTT的基礎知識建議直接看第三小節

【本文所有截圖均在模擬環境進行】

1 MQTT簡介術語

為了防止師傅們疑惑，本文使用術語定義如下：

客戶端（Client） ：使用MQTT的程式或裝置，一般分為釋出者和訂閱者

服務端（Server） ：釋出者和訂閱者之間的中介【Broker】

主題（Topic） ：附加在訊息上的一個標籤，Broker會將該訊息傳送給所有訂閱該主題的訂閱者

主題過濾器（Topic Filter） ：訂閱者訂閱時可使用萬用字元同時訂閱一個或多個主題

基本介紹

MQTT的主要工作原理如下圖所示，釋出者和訂閱者就像常見系統中的客戶端一樣，中心伺服器在MQTT中被稱為Broker [1]

那MQTT的設計優點有哪些呢？郭朝斌老師將其歸納為五個方面 [2]

1. 契合物聯網大部分應用場景的 釋出-訂閱模式

2. 能夠滿足物聯網中資源受限裝置需要的 輕量級特性

3. 時刻關注物聯網裝置 低功耗需求的最佳化設計

4. 針對物聯網中多變的網路環境提供的 多種服務質量等級

5. 支援在物聯網應用中越來越被重視的 資料安全

接下來我們分別講解一下這五個特性釋出-訂閱模式

透過上圖可以看到有兩個MQTT客戶端同時訂閱了同一個主題Temperature，當溫度感測器作為釋出者釋出其檢測到的溫度時，訂閱者手機、電腦和後端伺服器都會收到同樣的訊息

釋出-訂閱模式的優點在於釋出者與訂閱者的解耦，這種解耦表現在以下兩個方面 [3] ：

1. 空間解耦 ，訂閱者與釋出者不需要建立直接連線，新的訂閱者想要加入網路時不需要修改釋出者的行為

2. 時間解耦 ，訂閱者和釋出者不需要同時線上，即便不存在訂閱者也不影響釋出者釋出訊息

因為釋出-訂閱模型的應用，使得MQTT允許一個感測器釋出的資料觸發多個訂閱者的一系列動作

輕量級模型

MQTT的輕量體現在兩個方面：

一是MQTT訊息採用二進位制的編碼格式，充分利用位元組位，協議頭緊湊，減少了透過網路傳輸的資料量。下圖展示了MQTT的固定頭格式：

二是MQTT訊息互動流程非常簡單，MQTT 3.1.1一共定義了14種資料包型別，感興趣的朋友可以查閱MQTT的官方手冊，這裡不再贅述

https://mcxiaoke.gitbooks.io

低功耗最佳化

MQTT協議十分注重 低功耗 的最佳化設計， 主要體現在 Keepalive機制

這個機制工作的原理是：Client 和 Broker 都基於 Keepalive 確定時間長度，來判斷一段時間內是否有訊息在雙方之間傳輸。這個時間長度是Client建立連線時設定的，如果超出這個時間長度，雙方沒有收到新的資料包，那麼就判定連線斷開。

雖然 Keepalive 要求一段時間內必須有資料包傳輸，但實際情況是，Client 和 Broker 不可能時刻都在傳輸主題訊息。 因此 MQTT 定義了 PINGREQ 和 PINGRESP 這兩種訊息型別。 它們都沒有可變頭部和訊息體，也就只有 2 個位元組大小。 Client 和 Broker 透過分別傳送 PINGREQ 和 PINGRESP 訊息，就能夠滿足 Keepalive 機制的要求。

此外，MQTT 5.0 還引入了 重複主題 特性，即Client在重複傳送某個Topic的訊息時，可以從第二次開始將Topic長度設定為0

多種QoS

在物聯網環境中網路質量不穩定、網路頻寬低等因素均會影響到釋出者、訂閱與Broker之間的通訊。為了解決這個問題， MQTT協議設計了三種不同的QoS如下 ：

1. QoS 0，表示訊息至多收到一次，即訊息可能丟失，但不會重複投遞

2. QoS 1，表示訊息至少收到一次，即訊息保證送達，但可能重複投遞

3. QoS 2，表示訊息有且只有收到一次

安全傳輸

提到安全傳輸，首先我們要驗證 客戶端是否有許可權接入MQTT Broker

MQTT支援 兩種層次 的認證：

1.傳輸層認證，傳輸層使用TLS認證裝置，並且加密了通訊。

2.應用層認證，支援client id / username / password 等方式認證裝置，但是隻在應用層驗證裝置，不加密通訊

在本文中我們主要分析在應用層認證的MQTT，因為在傳輸層直接使用TLS加密之後我們就沒有辦法嗅探或者做其他操作了。但也這 不是意味著支援 TLS就能解決所有問題，因為MCU/RTOS根本玩不了TLS ，怎麼辦？ 還能怎麼辦，繼續不加密唄

接下來我們再來看看MQTT的認證過程：

客戶端將使用者名稱密碼 使用CONNECT訊息傳送到Broker ，Broker根據認證資訊判斷是否准入， 使用CONNACK訊息返回結果 ，其中認證返回值的具體含義如下：

透過這個表格，其實我們可以判斷， 如果連線某個Broker，返回值為0就代表我們已經成功連線，如果返回值為4說明我們的賬號密碼錯誤，如果返回值為5說明該Broker不支援使用者密碼方式登陸【需要記住】

最後我們還需要注意 Broker支援認證鏈 ，它會按照預設先後順序進行鏈式認證：

主題

MQTT協議基於主題(Topic)進行訊息路由，主題(Topic)類似URL路徑，例如：

chat/room/1sensor/10/temperaturesensor/+/temperature$SYS/broker/metrics/packets/received$SYS/broker/metrics/#

主題(Topic)透過'/'分割層級，支援'+', '#'萬用字元:

'+': 表示通配一個層級，例如a/+，匹配a/x, a/y   '#': 表示通配多個層級，例如a/#，匹配a/x, a/b/c/d

訂閱者可以訂閱含萬用字元主題，但釋出者不允許向含萬用字元主題釋出訊息 [4]

2 MQTT體驗

既然要搞MQTT，怎麼可以連工具都沒有呢？這裡我們直接 使用hbmqtt這個庫來模擬MQTT client ，安裝方式很簡單，直接pip

pip3 install hbmqtt

這裡我們使用eclipse提供的免費broker進行測試，地址如下：

mqtt.eclipseprojects.io

它提供了四種mqtt連線方式，今天我們主要來看看不加密的TCP連線方式，即常見的1883埠

我們開啟一個終端，訂閱/nianhua/iotsecurity這個主題訊息：

hbmqtt_sub --url mqtt://mqtt.eclipseprojects.io:1883 -t /nianhua/iotsecurity

開啟另一個終端，透過hbmqtt_pub釋出一個/nianhua/iotsecurity主題的訊息

hbmqtt_pub --url mqtt://mqtt.eclipseprojects.io:1883 -t /nianhua/iotsecurity -m Hello,World!

如果想了解 命令的執行細節 ，可以在上面的命令中 加上"-d"引數

再次檢視開啟的第一個命令列，我們可以發現我們傳送的Hello,World!已經接收到了。至此，我們已經完成了一次MQTT通訊

另外如果你不喜歡命令列，這裡推薦一個超級好用的 MQTT客戶端 ：MQTTX 下載地址：https://mqttx.app/cn/

Emmmmm，如果你連軟體都不想下，那這裡推薦給你一個 線上的MQTT客戶端 ：

tools.exqx.io

3 MQTT攻擊面

在這一小節我們主要介紹MQTT面臨的安全風險以及如何去攻擊

我們可以使用關鍵字" port=1883 && banner=MQTT "在fofa中搜索使用了預設埠的Broker，搜尋結果如下圖(January 5, 2021)所示，共發現了約26萬可用Broker

接下來我們就從 登陸認證問題 、 許可權控制問題 以及 Broker自身安全性 的問題 來分析MQTT的安全性

登陸認證問題1.匿名登陸

透過使用shodan檢索MQTT協議,我們可以發現很多MQTT Connect code為0，這意味著連線到該MQTT Broker無需進行身份驗證 【詳見1-MQTT簡介/安全傳輸】

經筆者粗略統計 大概有67.9%的可用MQTT Broker設定了匿名登陸 ：

2.使用者名稱密碼暴力破解

說是暴力破解，其實主要還是看 字典【主要是MQTT中常見的弱口令】 ，因為MQTT只是單純驗證使用者名稱和密碼，沒有其他校驗機制，所以我們可以使用暴力破解來嘗試獲取使用者名稱和密碼

藉著暴力破解這一小節，我們介紹一個新工具： MQTT-PWN ，上圖就是我們用MQTT-PWN 破解某個MQTT Broker的成功 截圖，爆破得到了賬號密碼，就可以直接接入Broker

該專案的Github地址如下：

https://github.com/akamai-threat-research/mqtt-pwn

最好使用Docker的安裝方式，pyenv有點問題，暴力破解的命令：

bruteforce --host host --port port -uf USERNAMES_FILE -pf PASSWORDS_FILE

預設使用者和密碼字典在mqtt-pwn的resources/wordlists資料夾中

MQTT-PWN還支援更多功能，如Owntracks (GPS Tracker)、Sonoff Exploiter等 [5]

感興趣的大家自己看下文件去進行測試

3. 嗅探賬號密碼

因為MQTT是基於TCP協議實現的，在 流量傳輸的過程中並未考慮加密 （這裡是指的除去MQTTS之外，即不包含使用TLS的MQTTS），其實這樣做也有利於降低客戶端裝置的成本，畢竟本來微控制器算力就不高

假設我們現在和客戶端裝置位於同一個網路中，我們可以透過嗅探區域網流量（ MIMT中間人攻擊 ）來 抓取賬號密碼

抓取 到 裝置的 賬號密碼後 ，我們就可以透過MQTT工具或者是MQTT-PWN連線到Broker 進行下一步攻擊

4. 從Web應用中獲取賬號密碼

很多廠商為了展示自己的物聯網裝置，往往會開發一個展示螢幕，如這種：

透過 檢視請求資訊 或者是從F12中的 network 檢視該頁面是否有mqtt的連線操作等等，如果有就可以繼續在js檔案中搜索是否存在mqtt的地址、賬號密碼等資訊

5. 硬體層面-韌體提取

對於無法透過一般途徑獲取賬號密碼的客戶端，我們可以透過 提取裝置的韌體 ，對其 逆向分析 ，然後把檔案系統中的 證書 或是 賬號密碼 提取出來

然後我們就可以仿冒該裝置連線到Broker， 訂閱/#【主題萬用字元】 。或者是Broker中的ACL配置有問題，嘗試是否可以控制其他裝置等等

6. 中間人篡改訊息

這個中間人和剛剛的賬號密碼嗅探雖然用的是同一種技術，但是這種方法是 直接在流量中修改傳送者發出訊息

現在攻擊者和客戶端（釋出者/訂閱者）在同一個網路中，攻擊者作為 中間人代理 客戶端和Broker的通訊 [4]

假設攻擊者想篡改 將釋出的主題名從"outTpoic"修改為"outTpuc" ，攻擊者需要從流量中篩選出符合條件的報文進行修改，我們可以 使用Etterfilter配合指令碼 來完成：

#owned.filterif (ip.proto == TCP && tcp.dst == 1883 && ip.dst == 'IP Broker' &&search(DATA.data, "outTopic")) {  replace("outTopic", "outTopuc");  msg("payload replaced\n");}

許可權控制問題

1. 登陸至訂閱者

當我們透過上述方法登陸至Broker之後，我們可以 訂閱該broker的所有主題訊息（使用/#，#是MQTT訊息主題萬用字元） ，如下圖所示

此外我們還編寫了一個指令碼用來提取所有釋出者傳送的訊息，我們可以看到提取出來的資訊 包括姓名、電話、經緯度、暱稱以及其他敏感資訊 等等【實驗資料！！！】

2 . 登陸至釋出者

我們還可以對該系統中的主題進行分析，這裡我們以路燈舉例，路燈作為訂閱者接收來自合法釋出者的控制。如下圖所示，如果我們 冒充合法釋出者對路燈進行惡意控制

此外，我們還可以冒充發布者 釋出 更新韌體指令 ，blah ... 下面我們來看個案例 [6]

智慧大廈場景中存在和停車、安防、燈光、廣播、會議、環境監測等相關的各類感測器，這些感測器將受控於閘道器，並利用閘道器將資料傳輸到雲端呈現。在本案例中，MQTT的通訊安全問題出現在智慧大廈的閘道器盒子中。

拓撲邏輯如下：

在MQTT的通訊場景中，研究員在閘道器前端抓取TCP資料包，並透過盒子的平臺控制盒子的Wi-Fi射頻開啟與關閉，發現其通訊方式使用的是MQTT通訊，其認證方式只用了使用者名稱和密碼。

基於之前的分析，發現只需要一條shell命令即可控制這個通訊過程。事實證明，盒子的Wi-Fi指示燈成功被我們熄滅和點亮。

Broker自身安全性問題1 . 預設賬戶口令

現在有很多開源的Broker實現，在國內較為出名的是EMQ X，它不僅提供高併發能力的叢集特性還支援擴充套件外掛機制。該專案還提供給使用者一個可直觀檢視的web儀表盤，透過web介面可以管理裝置與監控裝置等等。

但該專案為了方便使用者，直接為web管理臺設定了 預設賬號密碼 ，很多廠商部署了EMQ X之後並不會修改預設賬號密碼，如下圖：

透過shadon我們檢索出 18083埠且title中包含Dashboard 的站點，可以使用預設口令嘗試登陸 【我沒試！！！！！！求生欲強烈！！！】

2 . XSS漏洞

現在很多Broker都支援WEB端管理，管理員可以直接透過瀏覽器檢視client以及topic等資訊。如果我們 使用mqtt直接傳送包含有xss的資訊到Broker就可以直接繞過web端的防禦

這裡我們使用 CVE-2020-13821 做實驗，首先本地搭建一個hivemq 4.3.2：

docker run -p 8080:8080 -p 1883:1883 hivemq/hivemq4:4.3.2

該Broker的 使用者名稱和密碼為admin和hivemq ，如下圖所示：

我們使用hbmqq來發佈一個訊息，其中訊息的內容隨便輸入，指定client-id為xss payload：

hbmqtt_pub --url mqtt://ip:port -t / -m 1 -i "<img src=x onerror=prompt(2);>"

再回到HiveMQ中的Clients功能頁，點選Refresh Snapshot重新整理所有MQTT會話：

Bingo，這裡只是彈窗演示一下， 實際攻擊環境中可以更換為XSS平臺的payload

3. 其他漏洞

現在MQTT Broker供應商越來越多，但是經過這幾天的檢索，發現漏洞其實並沒有想象的那麼多。但是很多攻擊面是可以預見的，像是釋出者傳送訊息到訂閱者，Broker有可能將其存入資料庫，如果 沒有做好轉義 ，是否能夠產生 注入 等等

4 其他

MQTT在殭屍網路中的應用

MQTT在殭屍網路中應用這一思路最早是由Lucas和Neal在DEFCON24上提出 [7] ，如下圖所示

被控IoT裝置即是釋出者也是訂閱者，殭屍裝置 釋出關於裝置自身執行狀態到bot/status主題 ，同時 訂閱用於執行命令的bot/command主題

而 C&C攻擊者可以透過bot/command主題向裝置傳送指令，透過訂閱bot/status主題獲取每個裝置的執行狀態

5 防範措施

1. 使用 MQTTS 防止中間人攻擊

2. 在MQTT Broker上 啟用Topic ACL

3. 儘量 使用客戶端證書 作為裝置身份憑證，以驗證裝置合法性

總之，MQTT協議在安全上做出了很多努力，但是 使用者並不在意這些安全特性，可能是受限於硬體資源或是對於安全的不重視

https://www.hivemq.com/mqtt-security-fundamentals/

以獲得幫助

6 TODO

最近一直在使用MQTT-PWN，但感覺 不是特別好用 。希望有時間 LMN師傅 可以開發一個MQTT的漏洞利用套件 【MQTT-SUIT】

7 參考引用

[1] MQTT: The Standard for IoT Messaging. Retrieved January 7, 2021, from https://mqtt.org/[2] 郭朝斌.(2020, November 25). 物聯網開發實戰. 極客時間. Available January 7, 2021, from https://time.geekbang.org/column/article/312691[3] MQTT 釋出訂閱模式介紹. Retrieved January 7, 2021, from https://www.emqx.io/cn/blog/mqtt-5-introduction-to-publish-subscribe-model[4] MQTT Topic-based Message Routing. Retrieved January 7, 2021, from https://docs.emqx.io/en/enterprise/v3.0/mqtt.html[5] Tiger-Team.(2020, July 31).物聯網安全之MQTT協議安全. 安全課. Retrieved January 7, 2021, from https://www.anquanke.com/post/id/212335[6] https://github.com/akamai-threat-research/mqtt-pwn[7] L, Lundgren.(2016). Light Weight Protocol Serious Equipment Critical Implications. Defcon 24. Retrieved January 7, 2021, from https://www.defcon.org/html/defcon-24/dc-24-speakers.html[8] S. Andy, B. Rahardjo and B. Hanindhito, "Attack scenarios and security analysis of MQTT communication protocol in IoT system," 2017 4th International Conference on Electrical Engineering, Computer Science and Informatics (EECSI), Yogyakarta, 2017, pp. 1-6, doi: 10.1109/EECSI.2017.8239179.[9] D. Evans, “ The Internet of things: how the next evolution of the Internet is changing everything,” Cisco Internet Business Solution Group White Paper, April 2011.

作者:年華不散場

出處:

https://mp.weixin.qq.com/s?__biz=MzUzMjcxMzg5Mg==&mid=2247487921&idx=1&sn=dabc68501c368eef0434bc16bd01dfa4