Häufige MQTT-Sicherheitslücken und wie Sie sie entschärfen

MQTT-Sicherheitslücken lassen sich einer Handvoll wiederkehrender Klassen zuordnen: schwache oder fehlende Authentifizierung, Lücken in der Autorisierung, Parsing-Bugs in Brokern und Client-Bibliotheken, Informationslecks und Ressourcenerschöpfung. Dieser Artikel geht jede Klasse aus Sicht der Verteidiger durch, erklärt, warum sie entsteht, und listet die wirksamen Gegenmaßnahmen auf. Am Ende haben Sie eine Checkliste für das Schwachstellenmanagement von Brokern, Geräten und den Anwendungen dazwischen.

Wo MQTT-Sicherheitslücken entstehen

Das MQTT-Protokoll selbst ist klein und gut spezifiziert. Die meisten Probleme in der Praxis stammen aus drei Bereichen:

1. Broker-Implementierungen: die Serversoftware, die Pakete parst, Clients authentifiziert und Nachrichten weiterleitet.
2. Client-Bibliotheken und Firmware: der Code auf Geräten und in Anwendungen, der MQTT spricht.
3. Deployments: Konfiguration, Zugangsdaten, Netzwerk-Exposition und Topic-Design.

In der Praxis verursachen Fehler im Deployment die meisten Vorfälle, Implementierungsfehler sind jedoch diejenigen, die gepatcht werden müssen. Beide verdienen einen Plan.

Schwachstellenklassen im Überblick

Schwächen in der Authentifizierung

Die einfachste Schwachstelle ist gar keine Authentifizierung. Broker, die in einem freizügigen Entwicklungsmodus belassen werden, akzeptieren jeden Client, was zu den Problemen führt, die unter offen erreichbare MQTT-Broker beschrieben sind.

Subtilere Probleme treten auf, wenn Authentifizierung zwar existiert, aber Lücken hat. In der Vergangenheit gab es in Broker-Implementierungen Bugs, bei denen bestimmte Kombinationen von Optionen, Plugin-Verhalten oder fehlerhafte Pakete es einem Client erlaubten, eine Prüfung zu überspringen. Muster, auf die Sie achten sollten:

• Authentifizierungs-Plugins, die bei nicht erreichbarem Backend (Datenbank, LDAP) offen ausfallen (Fail Open).
• Listener mit unterschiedlichen Einstellungen, bei denen ein vergessener Listener anonymen Zugriff erlaubt.
• Vertrauen auf Basis der Client ID, bei dem die Kenntnis einer Client ID genügt, um eine Session zu übernehmen.
• Keine Begrenzung von Loginversuchen, wodurch das Erraten von Passwörtern praktikabel wird.

Gegenmaßnahmen: Verlangen Sie Authentifizierung auf jedem Listener, lassen Sie das System bei ausgefallenem Auth-Backend geschlossen ausfallen (Fail Closed), binden Sie Client IDs an Zugangsdaten und drosseln oder sperren Sie wiederholte Fehlversuche. Bei ConnectMQ sind Client IDs an ausgestellte Zugangsdaten gebunden, und IPs werden nach wiederholten fehlgeschlagenen Logins gesperrt.

Lücken in der Autorisierung

Nach dem Verbindungsaufbau sollte ein Client nur seine eigenen Topics berühren können. Häufige Lücken sind:

• Alle Geräte teilen sich ein Konto mit Vollzugriff.
• Wildcard-Subscriptions wie # sind für gewöhnliche Geräte erlaubt.
• Befehls-Topics sind für jeden authentifizierten Client beschreibbar.
• Für MQTT 3.1.1 geschriebene Regeln übersehen MQTT-5-Funktionen wie Shared Subscriptions ($share/group/topic).

Gegenmaßnahmen: Entwerfen Sie Topics so, dass Berechtigungen der Hierarchie folgen können, geben Sie jedem Gerät eindeutige Zugangsdaten und testen Sie die Berechtigungsmatrix bei jedem Release. Selbst gehostete Broker können ACLs nutzen, die im Leitfaden zur MQTT ACL beschrieben sind. Wo der Broker keine Regeln pro Topic bietet, erreichen getrennte Mandanten oder Broker pro Vertrauensdomäne eine stärkere Isolation, als geteilte Zugangsdaten es je könnten.

Parsing-Bugs und Speichersicherheit

MQTT-Pakete enthalten Integer variabler Länge, längenpräfixierte Strings, Binärdaten und in MQTT 5 eine Vielzahl von Properties. Jedes dieser Felder muss validiert werden. Parsing-Bugs in Broker- und Client-Implementierungen haben in der Vergangenheit zu Abstürzen und im schlimmsten Fall zu Speicherkorruption geführt.

Typische Ursachen:

• Remaining-Length-Werte, die nicht zu den tatsächlichen Daten passen.
• Property-Listen mit doppelten oder unerwarteten Properties.
• Ungültiges UTF-8 oder verbotene Zeichen in Topic-Namen.
• Sehr tiefe Topic-Hierarchien oder extrem lange Strings.

Gegenmaßnahmen: Halten Sie Broker und Client-Bibliotheken auf unterstützten, gepatchten Versionen; abonnieren Sie Sicherheitshinweise für jede MQTT-Komponente, die Sie ausliefern; und führen Sie Fuzzing nur gegen isolierte Staging-Broker durch, die Ihnen gehören. Die Methodik für den MQTT-Penetrationstest erklärt, wie Sie das sicher abgrenzen. Bevorzugen Sie auf Embedded-Geräten gepflegte Bibliotheken gegenüber eigenen Parsern.

Offenlegung von Informationen

Informationslecks sind selten spektakulär, aber oft nützlich für Angreifer:

• $SYS-Topics, die Broker-Version, Uptime und Client-Zahlen verraten.
• Retained Messages, die lange nach Projektende auf Topics liegen bleiben.
• Debug- oder Diagnose-Topics, die Konfiguration, IP-Adressen oder Tokens veröffentlichen.
• Fehlermeldungen, die verraten, ob ein Benutzername existiert.
• Topic-Namen, die Standorte, Kunden oder Anlagen detailliert beschreiben.

Gegenmaßnahmen: Schränken Sie ein, wer Metadaten-Topics lesen darf, prüfen und bereinigen Sie Retained-Topics, halten Sie Geheimnisse vollständig aus Payloads heraus und verwenden Sie undurchsichtige Bezeichner, wo Topic-Namen zu viel verraten würden. In einem Unified Namespace (UNS) nach ISA-95 sind sprechende Pfade wie acme/werk-stuttgart/montage/linie-1 dagegen gewollt, denn sie bilden die Anlagenstruktur ab; schützen Sie diesen Baum über Authentifizierung und Autorisierung statt über Verschleierung.

Ressourcenerschöpfung

Ohne Limits kann ein einzelner Client Verbindungen, Speicher oder Bandbreite verbrauchen, bis der Broker in die Knie geht. Fluten können böswillig sein oder einfach das Ergebnis von Firmware-Bugs und Reconnect-Stürmen.

Gegenmaßnahmen: Nachrichtenratenlimits pro Client, maximale Paketgröße, Obergrenzen für Subscriptions und Verbindungen sowie clientseitiges Backoff. ConnectMQ wendet Quotas pro Plan mit dem MQTT-5-Reason-Code 0x97 und Flood Protection an. Details finden Sie unter MQTT-Rate-Limiting und DoS-Schutz.

Clientseitige Schwachstellen

Clients sind oft das schwächste Glied, weil sie auf vielen Geräten mit langen Update-Zyklen laufen.

• Nicht validierte Payloads: Ein Subscriber, der eine Payload an einen Shell-Befehl, eine SQL-Abfrage oder eval weitergibt, hat den Broker in einen Angriffskanal verwandelt.
• Deaktivierte TLS-Prüfung: Clients, die den „insecure"-Modus setzen, um Zertifikatsfehler zu umgehen, können abgefangen werden.
• Fest einprogrammierte Zugangsdaten: Firmware-Images lassen sich leicht extrahieren. Der Leitfaden MQTT-Zugangsdaten auf Geräten schützen behandelt die Speicheroptionen.
• Veraltete Bibliotheken: Geräte, die sich nicht aktualisieren lassen, behalten bekannte Bugs für immer.

Ein sicherer Subscriber behandelt jede Payload als nicht vertrauenswürdige Eingabe:

import json
import paho.mqtt.client as mqtt

ALLOWED_COMMANDS = {"set_interval": (5, 3600), "set_threshold": (0, 100)}

def on_message(client, userdata, msg):
    try:
        data = json.loads(msg.payload.decode("utf-8"))
        cmd, value = data["cmd"], float(data["value"])
    except (ValueError, KeyError, UnicodeDecodeError):
        print("rejected malformed payload on", msg.topic)
        return
    if cmd not in ALLOWED_COMMANDS:
        print("rejected unknown command", cmd)
        return
    low, high = ALLOWED_COMMANDS[cmd]
    if not low <= value <= high:
        print("rejected out-of-range value", value)
        return
    print(f"applying {cmd}={value}")  # hier Ihren eigenen sicheren Handler aufrufen

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_message = on_message
client.on_connect = lambda c, u, f, rc, p: c.subscribe("connectmq/site1/device42/cmd", qos=1)
client.connect("YOUR_BROKER_HOST", 8883)
client.loop_forever()

Das Muster ist einfach: strikt parsen, Befehle per Allowlist zulassen, Wertebereiche prüfen und niemals Payload-Inhalte ausführen.

Patch-Strategie: selbst betrieben oder verwaltet

Schwachstellenmanagement ist eine Daueraufgabe. Bei einem selbst betriebenen Broker muss jemand Sicherheitshinweise verfolgen, Upgrades testen, Wartungsfenster planen und anschließend prüfen, ob die Konfiguration noch stimmt. Aus dem Internet erreichbare Broker, die bei Updates hinterherhinken, sind genau das, wonach Angreifer suchen. Für industrielle Umgebungen beschreibt IEC 62443-2-3 ein strukturiertes Patch-Management, und der EU Cyber Resilience Act verpflichtet Hersteller vernetzter Produkte, Schwachstellen über den Supportzeitraum zu behandeln und Sicherheitsupdates bereitzustellen. Mehr dazu im Artikel zum EU Cyber Resilience Act.

Ein verwalteter MQTT-Broker verlagert das Patchen des Brokers zum Anbieter. Bei ConnectMQ werden die Broker-Software, TLS-Zertifikate und Plattformschutzmaßnahmen wie Mandantenisolation für Sie betrieben, während Sie für Geräte-Firmware, Client-Bibliotheken, Zugangsdaten und den Umgang mit Payloads verantwortlich bleiben. Wer versteht, was ein MQTT-Broker tut, kann diese Grenze klar ziehen.

Checkliste für das Schwachstellenmanagement

1. Pflegen Sie ein Inventar aller eingesetzten Broker, Client-Bibliotheken und Firmware-Versionen.
2. Abonnieren Sie Sicherheitshinweise für jede Komponente.
3. Verlangen Sie Authentifizierung und TLS auf jedem aus dem Internet erreichbaren Listener.
4. Geben Sie jedem Gerät eindeutige, widerrufbare Zugangsdaten und Zugriff nach dem Least-Privilege-Prinzip.
5. Konfigurieren Sie Limits für Größe, Rate und Verbindungen; behandeln Sie Reason Codes in den Clients.
6. Validieren Sie alle Payloads bei den Subscribern; führen Sie niemals Payload-Inhalte aus.
7. Entfernen Sie Geheimnisse aus Payloads und bereinigen Sie Retained-Topics.
8. Stellen Sie einen sicheren Firmware-Update-Pfad für Geräte bereit.
9. Testen Sie Authentifizierung und Autorisierung nach jedem Upgrade erneut.
10. Dokumentieren Sie in einer Tabelle der geteilten Verantwortung, wer was patcht.

Verkleinern Sie Ihre Angriffsfläche mit ConnectMQ

Streichen Sie zuerst das Patchen des Brokers von Ihrer Liste. Erstellen Sie unter app.connectmq.com einen privaten Broker im kostenlosen Serverless-Plan (ohne Kreditkarte), verbinden Sie Ihre Clients über TLS mit generierten Zugangsdaten und konzentrieren Sie Ihren Sicherheitsaufwand auf Geräte und Anwendungen. Der Leitfaden Best Practices für MQTT-Sicherheit ist der nächste Schritt zur Härtung der Clients.

Häufig gestellte Fragen

Ist das MQTT-Protokoll selbst unsicher?

Nein. MQTT unterstützt Authentifizierung und läuft über TLS, erzwingt aber beides nicht. Die meisten Probleme stammen aus Implementierungen und aus Deployments, die diese Maßnahmen auslassen.

Welche MQTT-Sicherheitslücke ist in der Praxis am häufigsten?

Fehlende oder schwache Authentifizierung auf aus dem Internet erreichbaren Brokern, oft kombiniert mit dem unverschlüsselten Port 1883, ist das häufigste Problem, über das öffentliche Untersuchungen berichten.

Wie halte ich MQTT-Client-Bibliotheken sicher?

Fixieren Sie Bibliotheksversionen, verfolgen Sie deren Sicherheitshinweise und aktualisieren Sie sie im Rahmen normaler Releases. Planen Sie auf Geräten einen Over-the-Air-Update-Pfad, damit Korrekturen die Flotte auch tatsächlich erreichen.

Beseitigt ein verwalteter MQTT-Broker alle MQTT-Sicherheitslücken?

Er nimmt Ihnen das Patchen des Brokers und die Härtung der Plattform ab, doch Client-Code, Firmware, Zugangsdaten und die Validierung von Payloads bleiben Ihre Verantwortung.