Seit einiger Zeit erhält NSIDE mehr und mehr Anfragen für Sicherheitstests für Lösungen, die auf MQTT aufbauen oder MQTT-Komponenten an zentraler Stelle einsetzen. Dies ist auch nicht erstaunlich: MQTT ist ein IoT-Protokoll. Da IoT immer mehr an Bedeutung gewinnt und es mehr Produkte und Lösungen für den IoT-Sektor gibt, spielt auch MQTT eine immer größer werdende Rolle.

Daher möchten wir in diesem Artikel einen groben Überblick über MQTT-Sicherheit geben. Wie so viele Themen der IT-Sicherheit könnte man auch über die Sicherheit von MQTT eine mehrseitige Abhandlung schreiben. Da dies den Rahmen sprengen würde, beschränken wir uns an dieser Stelle auf eine sehr grobe Einführung.

Kurze Einführung: Was ist MQTT?

MQTT ist zwar ein Protokoll auf Anwendungsebene, konzeptionell handelt es sich allerdings um ein inhaltsagnostisches Transportprotokoll. Die „Anwendung MQTT“ ist somit der Transport beliebiger und beliebig formatierter Daten. MQTT kümmert sich nur um wenige Dinge: primär die Auslieferung und die „Einsortierung“ der Daten auf sogenannte Topics, welche man grob als Kanäle oder Kategorien verstehen kann. Das Protokoll ist sehr einfach aufgebaut und zu verarbeiten. MQTT folgt dem Publisher-Subscriber-Modell: Es gibt einen zentralen Knoten, den sogenannten Broker. Dieser nimmt von allen Geräten und Systemen, die mit ihm verbunden sind, Daten entgegen und kümmert sich um deren Verteilung an andere Systeme und Geräte. Geräte und Systeme melden Interesse daran, Daten eines bestimmten Kanals (= Topic) zu empfangen an, indem sie sich für diese Topic anmelden („subscribe“). Andere Geräte können nun Daten auf diesem Kanal (= Topic) veröffentlichen („publish“). Der Broker kümmert sich nun darum, dass die Nachrichten vom Publisher zum Subscriber kommen. Sämtliche Kontrollmaßnahmen werden durch den zentralen Broker umgesetzt.

Als unkompliziertes und flexibles Protokoll, welches beliebige Daten transportieren kann, sehr datensparsam und rechenleistungseffizient ist, und bei welchem sämtliche „Denkarbeit“ von einem zentralen Knotenpunkt durchgeführt wird, ist MQTT perfekt für IoT und Industrial Iot (IIoT) geeignet. Allerdings finden wir in unseren Tests häufig Sicherheitsprobleme. Das liegt einerseits daran, dass MQTT im Design absichtlich keinen großen Wert auf Sicherheit legt. Andererseits sind viele IoT- und Embedded-Entwickler sowie Entwickler aus dem industriellen Umfeld oft nicht mit Sicherheitsthematiken vertraut. Die Folge: MQTT-Installationen und Komponenten sind häufig unsicher, mit teils gravierenden Folgen.

Problem 1: Authentifizierung

Ein Problem, welches viele andere Protokolle und die Entwickler, die sie nutzen, bereits hinter sich gebracht haben, ist bei MQTT nach wie vor nicht flächendeckend gelöst: Fehlende Authentifizierung. Viele MQTT-Server sind so konfiguriert, dass sich beliebige Parteien auch ohne gültigen Nutzernamen und Passwort verbinden können. Da MQTT auch sogenannte Wildcard-Selektoren für Topics unterstützt (Wildcard-Selektoren wie + und # erlauben es, sich für Topics anzumelden, ohne ihren genauen Namen zu kennen), können somit unbefugte Personen – auch ohne Kenntnis gültiger Topic-Namen – beliebigen Datenverkehr, der über den Broker geleitet wird, mitlesen.

Problem 2: Autorisierung

MQTT unterstützt auf Protokollebene keine Zugriffsschutzmaßnahmen. Das bedeutet, dass sich der Broker darum kümmern muss, wer berechtigt ist, auf welchen Kanälen/Topics Daten zu veröffentlichen und auf welchen Kanälen/Topics Daten zu empfangen. Einige Broker implementieren hierfür ACLs (Access Control Lists), die aber leider von Administratoren und Entwicklern oft nicht benutzt werden. Autorisierung hängt außerdem auch von Authentifizierung ab – wenn man Parteien nicht identifizieren kann, kann man auch nicht korrekt beschränken, was diese tun dürfen und was nicht. Und zu guter Letzt führen auch die bereits genannten Wildcard-Selektoren zu Problemen: Wenn man ACLs falsch aufbaut und Wildcard-Selektoren nicht bedenkt, kann es sein, dass Nutzer und Geräte dennoch an Topics gelangen, auf die sie nicht zugreifen können sollten.

Problem 3: Implizites Vertrauen

Viele Betreiber und Entwickler von MQTT-Ökosystemen gehen oft leider von der falschen impliziten Annahme aus, dass alle Daten, die über den Broker laufen, auch von Geräten und/oder Nutzern stammen, denen sie vertrauen können. Warum? Schließlich haben sie den Broker für ihre Geräte/Nutzer aufgesetzt und „nur diese kennen ihn“. Insbesondere dann, wenn Authentifizierung und/oder Autorisierung nicht korrekt umgesetzt ist – aber nicht nur dann! – ist dies eine gefährliche Annahme, denn Geräte können auch kompromittiert werden. Daten ungerechtfertigterweise zu vertrauen kann zu allen möglichen Problemen führen – dies gilt insbesondere im industriellen Umfeld, wo gefälschte Daten sehr leicht die Produktion lahmlegen können. Ist ein Angreifer beispielsweise in der Lage, die Temperaturwerte oder Rotationsgeschwindigkeit einer Anlage oder Kühlung zu fälschen, kann dies schnell zu einem Not-Aus führen – da die Betreiber bzw. Not-Aus-Logik von einer gefährlichen Fehlfunktion, Überhitzungsgefahr oder Gefahr für Leib und Leben ausgehen (müssen). Auch kann es passieren, dass Steuerbefehle und Betriebssystemkommandos über MQTT an Geräte- oder Sensoren-Flotten verteilt werden. Wenn ein Angreifer diese fälschen kann, kann er ganze Sensor- oder Geräte-Flotten und somit Industrieanlagen unter seine Kontrolle bringen. Das waren nur wenige Beispiele. Da aber industrielle Anwendungen häufig Sensoren und Aktuatoren vereinigen, können gefälschte MQTT-Daten sehr schnell sehr gefährlich werden.

Problem 4: Second-Order-Angriffe

Oft werden Daten, die ursprünglich per MQTT übertragen wurden, an weitere Systeme jenseits der MQTT-Installation geschickt und dort gespeichert und verarbeitet. Hierbei kann es sich zum Beispiel um Datenbanken handeln, die Sensorwerte langfristig speichern, oder Web-Frontends, welche den Zustand von Maschinen oder technischen Anlagen anzeigen. Beim Einspielen der Daten, die über MQTT übertragen wurden, müssen diese allerdings sicher für den Zielkontext kodiert werden: Sonst kann es passieren, dass Daten, die in einer Datenbank gespeichert werden, auch erlauben, die Datenbank zu manipulieren oder zu zerstören (z.B. üer sogenannte SQL injection). Genau so kann es möglich sein, dass Daten, die auf einer Webseite angezeigt werden, so manipuliert werden können, dass bösartiger Script-Code in die Webseite injiziert wird – falls dies nicht aktiv verhindert wird. Diese Angriffsklasse nennt man Second-Order-Injections. Generell erlauben solche Angriffe, Daten, die in einem Kontext nicht schädlich sind (MQTT), in einen anderen Kontext so einzubringen, dass sie dort Schaden anrichten (z.B. Datenbanken, Webseiten, E-Mail, uvm.).

Problem 5: Preisgabe und Manipulation von Systemdaten

Viele Broker haben vordefinierte Topics (= Kanäle), unter welchen Systeminfos veröffentlicht werden. Diese Topics werden daher auch System-Topics genannt. Leider sind diese oft aktiv und zweitens für alle Welt (falls kein Authentifizierungsschutz) oder alle Geräte/Systeme/Nutzer (falls mangelhafte Autorisierung) lesbar – teils sogar schreibbar.

Problem 6: Zweckentfremdung

Einige Male schon hat NSIDE MQTT im Einsatz gefunden, wo es eigentlich nicht eingesetzt werden sollte – beispielsweise, weil eine REST-Schnittstelle geeigneter wäre. Dies führt dann dazu, dass über MQTT viele Sicherheitsmechanismen (unsicher!) nachgebaut wurden, die für REST (oder andere Protokolle) bereits entweder als Teil des Protokolls vorhanden sind oder als Bibliotheken zur Verfügung stehen. Aus dem Nachbau solcher Mechanismen oder durch den Einsatz von MQTT jenseits seines eigentlich gedachten Einsatzzweckes entstehen oft Sicherheitsschwachstellen, die kaum behoben werden können, sondern architektonische Änderungen erfordern.

Problem 7: Mangelnde oder schwache Verschlüsselung

MQTT kann entweder unverschlüsselt (üblicherweise TCP Port 1883) oder per TLS verschlüsselt (üblicherweise TCP Port 8883) betrieben werden. Sichere Verschlüsselung per TLS ist ein Problem, welches bei regulären Geräten („edge devices“ – Smartphones, Computer, Server) prinzipiell, korrekte Konfiguration vorausgesetzt, bereits gelöst ist. Auch hier sieht es in der IoT und IIoT-Welt wiederum anders aus: Die Kapazitäten und Bibliotheken, die auf IoT-Geräten zur Verfügung stehen, sind begrenzt. Auch ist die Anbindung an die öffentliche TLS-Zertifikats-PKI teilweise nicht gegeben. Schlüssel- und Zertifikatsmanagement ist, mangels entsprechender Prozesse, Tools und Wartungsschnittstellen oft auch nicht möglich. Dies führt dann dazu, dass Verschlüsselung bei MQTT erst gar nicht zum Einsatz kommt oder auf Seite der IoT/IIoT-Geräte so schwach konfiguriert ist, dass Angreifer die Verschlüsselung aufbrechen können oder sich als Mittelsmann (Man in the Middle) dazwischen schalten können. Dadurch können Angreifer dann nicht nur Daten (zum Beispiel Zugangsdaten für den MQTT-Broker, aber auch sensible Nutzlastdaten) mitlesen, sondern auch manipulieren. Und, wie bereits erörtert, kann in industriellen Anwendungsgebieten die Manipulation von Daten schnell zu Schäden (da Aktuatoren falsch reagieren) oder Runterfahren der Produktion durch Vortäuschen einer Not-Aus-Bedingung führen. Beides resultiert in großen finanziellen Schäden.

Zusammenfassung

MQTT ist ein für viele IoT- und IIoT-Anwendungen gut geeignetes Protokoll. Von Hause aus bietet es allerdings keine Sicherheitsmechanismen und die sichere Verwendung müsste zwar in vielen Anwendungen sichergestellt werden, wird sie aber in der Praxis nicht. In diesem Artikel haben wir einige Sicherheitsprobleme im Zusammenhang mit MQTT vorgestellt, jedoch gibt es noch viele weitere. Wie mit allen Technologien gilt: Man muss ihre Funktionsweise verstehen und sich ihrer Risiken bewusst sein, um diese korrekt absichern zu können.
Falls Sie Unterstützung beim Testen oder Absichern ihrer MQTT-Installation benötigen: Sprechen Sie uns gerne an!