Security and dependability of devices are paramount for the IoT ecosystem. Message Queuing Telemetry Transport protocol (MQTT) is the de facto standard and the most common alternative for those limited devices that cannot leverage HTTP. However, the MQTT protocol was designed with no security concern since initially designed for private networks of the oil and gas industry. Since MQTT is widely used for real applications, it is under the lens of the security community, also considering the widespread attacks targeting IoT devices. Following this direction research, in this paper we present an empirical security evaluation of several widespread implementations of MQTT system components, namely five broker libraries and three client libraries. While the results of our research do not capture very critical lfaws, there are several scenarios where some libraries do not fully adhere to the standard and leave some margins that could be maliciously exploited and potentially cause system inconsistencies.
The protocol was conceived with no security concern, since initially designed for private
networks of the oil and gas industry [
Since MQTT is widely used for real applications, it is under the lens of the security
community, also considering the widespread attacks targeting IoT devices. The research is focusing
on shifting towards ensuring secure IoT systems, for example, implementing access control
mechanisms [
Following this research direction, in this paper we present an empirical security evaluation of several widespread implementations of MQTT system components, namely five broker libraries and three client libraries. Moreover, we also applied our security analysis to an MQTT client embedded in a real IoT device, namely a Shelly DUO Bulb. This IoT device is a remote-controlled LED light bulb. It supports Wi-Fi connectivity and acts as an MQTT subscriber to receive commands, like powering on/of or light dimming.
Our evaluation has aimed to verify the responses of the components of the diferent libraries to diferent MQTT messages to see their behaviour in situations where the standard does not indicate clearly how the message (or the connection itself) is supposed to be handled. These mishandling might create interoperability issues or even open doors to malicious attackers. While the results of our research do not capture very critical flaws, there are several scenarios where some of the libraries do not fully adhere to the standard and leave some margins that could be maliciously exploited and potentially cause system inconsistencies.
The structure of the paper is the following: Section 2 reports the state of the art concerning the security analysis of MQTT, while in Section 3 we provide the details about our research methodology. Section 4 reports the results of our security analysis, and the last section concludes the paper with some remarks and future directions.
As the abundance of surveys suggests [
Like all the network protocols becoming a standard, it has undergone many reviews both
formally and empirically. Several papers focus on MQTT formal modelling and performance
analysis [
In [
In [
A diferent methodology based on attack patterns [
Another methodology to perform a dynamic analysis is model-based testing, as proposed
for MQTT applications in [
MQTT implements the publish-subscribe communication paradigm (Figure 1): clients send messages on a topic to servers (named brokers) that are responsible for delivering them to the interested clients, the final recipients of the messages. Brokers are, then, intermediaries that accept messages and forward a copy of each message to the clients who previously subscribed for a given topic. A topic is a UTF-8 string obtained joining one or more topic levels with the slash character, like in /home/basement/kitchen/temperature/ and the client subscriptions can be made to a topic or part of it, thanks to the use of wildcards, like in /home/basement/#.
In a general MQTT session, a client establishes a connection with a broker (CONNECTCONNACK exchange), subscribes to one or several topics (SUBSCRIBE-SUBACK exchange), publishes contents (PUBLISH-PUBACK exchange), receives other client contents (PUBLISH or PUBLISH-PUBREC-PUBREL exchange, according to the QoS) and terminates the session (client DISCONNECT). The CONNECT packet can implement an authentication mechanism, based on username and password. All the exchanges happen using a clear text TCP session on port 1883 or, if TLS is used, using an encrypted session on port 8883. Encrypted exchanges are mainly used when authentication is enforced, so that username and password are protected against eavesdropping.
In addition to the topic, any message also has a Quality-of-Service value (QoS), taken in the range 0–2. A QoS equals 0 corresponds to no guarantees, and it means that the message can be lost or delivered multiple times. A client sending a message with QoS equals 1 requires that the message should never be discarded, while it might be delivered multiple times; in this case the sender stores the message until it receives back a PUBACK packet that ensures reception. Similarly, with a QoS set to 2, the message should never be discarded and it should be delivered exactly one time; in this case the client will wait for a PUBREC packet and, once received, it will discard the PUBLISH and it will send a PUBREL packet. The last packet that the client will receive in this exchange is the PUBCOMP that will release the id of the PUBLISH for reuse. It is important to highlight that the publisher QoS is not associated with the subscriber QoS – unless the implementation supports this non-standardized feature.
The purpose of our research was to compare the behaviour of diferent implementations of MQTT. The first step has been finding and setting up the most popular open-source brokers and client libraries that people use to manage their devices or develop common software solutions. To determine the popularity, we took into account the number of stars and forks on GitHub repositories and the number of blog posts citing the examined brokers.
We focused only on open source libraries, namely: Mosquitto, EMQ X, HiveMQ, Moquette and Aedes for the brokers, paho, mqttools and mqtt.js for the clients. We will discuss the brokers and the clients respectively in Section 4.1 and in Section 4.2. Some of these have thousands of instances running in “production” environments, in common consumer and business-tobusiness solutions. We also tested a popular low-cost Internet-of-Things device, namely the Shelly DUO Bulb (Section 4.3).
The next step has been to evaluate the type of tests to apply, considering the MQTT standard specification, version 3.1.1. We specifically looked for undefined behaviours, unspecified states or other missing information about message handling. Also, we looked for parts of the standard that might lead to a wrong implementation (e.g. expected actions by the broker/client that are implied but not specified or not clearly specified). This allowed us to focus our testing on a restricted subset of cases, as explained in Section 4.
We created diferent sets of experiments to find possible anomalies in MQTT implementations, developing our fuzzer written in python, with the help of the twisted library2. Our custom fuzzer allowed us to manage diferent streams correctly and send custom packets: for example, we could change every bit of the packets to see the brokers behaviour even in the presence of malformed packets. Standard, common MQTT libraries, instead, implement some statemachine which are expected in some part of the protocol (e.g. QoS2): a straightforward use of such libraries would not allow arbitrary changes in the flow of the messages, like out-of-order messages. Each experiment has been codified in a JSON file that specifies the sequence of actions or packets that the test should run on/against the software under test, and the final behaviour of the involved parties have been logged and analyzed.
A broker is a fundamental component in an MQTT architecture. Its job is to accept messages from clients (acting as “publishers") and then forward them to all clients with subscriptions (“subscribers") matching the topic of the message. This loosely coupled architecture allows the clients to not communicate directly with each other.
Modern brokers support many concurrent connections and messages per second. A flaw in message state machines, packet parsing, topic logic, etc., might expose a high impact vulnerability, which a malicious actor might exploit to launch some attacks like a Denial-of-Service.
We analyzed five common MQTT brokers:
• Mosquitto3: it is one of the most used MQTT brokers in the world. It is a single-threaded, lightweight broker written in C. This broker has been widely used thanks to its flexibility. • EMQ X4: it is written in Erlang and it claims to be so eficient to be “the Leader in Open
Source MQTT Broker for IoT". • HiveMQ5: a broker written in Java. It supports MQTT version 3.x and 5.0 and it is widely used in automation and industrial systems. We tested the Community Edition. • Moquette6: another Java-powered open-source broker. It is very lightweight but it is less-known and less-used, when compared to other brokers. • Aedes7: a broker written in JavaScript/NodeJS. It is the successor of MoscaJS. It does not support version 5 of MQTT, but it is fully compatible with version 3.x and supports several extension libraries.
Each broker underwent the same set of tests specified in the next section. We performed more than 60 diferent experiments on a consumer-grade PC with local connections. A summary of the results is in Table 1. 4.1.1. Experiments and results Publish QoS 2 and 1. In this experiment, the client performs the following steps:
2. it sends the first PUBLISH packet with a quality of service 2 and with id 1 over the topic specified in the subscription; 3. it sends the second PUBLISH packet with a quality of service 1, still with id 1 over the topic specified in the subscription; 4. it sends a PUBREL packet for the first packet sent.
We noticed diferent broker behaviours: Mosquitto publishes the first received packet with QoS 2, but then it loses the second packet that is not published to the clients due to the PUBCOMP 3https://mosquitto.org/ 4https://www.emqx.io/ 5https://www.hivemq.com/developers/community/ 6https://github.com/moquette-io/moquette 7https://github.com/moscajs/aedes packet that is not received, and so the packet id is not available for use. The EMQ X broker publishes both packets; it handles the flow for the first packet and then the flow for the second one. In HiveMQ and in Moquette, the client that sends packets receives the publication first and after the pubcomp, concerning the first packet. Additionally, in HiveMQ the client receives the pubcomp back first and then the pubrec. Aedes publishes both packets, but the pubcomp arrives at the client after the two publications. This behaviour repeated several times, also in the other experiments regarding the quality of service that are described below.
Publish QoS 2 and 0. This experiment is very similar to the one described above, but in this case, the client performs the following steps:
2. it sends the first PUBLISH packet with a quality of service 2 and with the id 1 over the topic specified in the subscription; 3. it sends the second PUBLISH packet with a quality of service 0 and with the id 1 over the topic specified in the subscription; 4. it sends a PUBREL packet for the first packet sent.
Mosquitto, in this case, publishes both packets but in reverse order: it handles the one with quality of service 0 first, and then it handles, correctly, all the flow regarding the first packet sent with quality of service 2. EMQ X and HiveMQ maintain the order of the packets published by the client; also, in the case of HiveMQ, the client received back the pubcomp first and then the pubrec regarding the packet with quality of service 2. Moquette behaves similarly to EMQ X, but, in this case, the pubcomp arrives after the publication of the second packet. Aedes has the same behaviour as Mosquitto, but the pubcomp arrives after the publication as in the previous experiment.
Double publish QoS 2. In this experiment, the client performs the following steps:
2. it sends the first PUBLISH packet with a quality of service 2 and with the id 1 over the topic specified in the subscription; 3. it sends the second PUBLISH packet with a quality of service 2 and with the id 1 over the topic specified in the subscription; 4. it sends a PUBREL packet for the first packet sent; 5. it sends a PUBREL packet for the second packet sent.
In Mosquitto, only one publication referred to the first packet sent, but the flow regarding the quality of service is properly handled. EMQ X, in this case, has the same behaviour as Mosquitto. Instead, HiveMQ and Moquette publish both packets in the correct order. In Aedes, there is a diferent behaviour: the broker publishes two packets, but they are the same packet, the first one sent by the client.
Long topic. In the MQTT standard, the maximum length topic is 65536 bytes, but we saw that in the source code of EMQ X there is a constant that represents the maximum length, and its value is 4096. So, we tried to subscribe to a topic with more than 4096 bytes. In Mosquitto the subscription to the topic is successful. Instead, HiveMQ cuts the topic to which the client is subscribing to. In Moquette there is an IOException and then the client disconnection. In Aedes there is a crash of the broker and the client; in particular, the exception thrown by the experiment generated an error like “too many words”. In EMQ X the client disconnects. Other experiments. Further experiments are listed below. They have been briefly summarized, since the behaviour of all the brokers was correct.
• some experiment where the client id value in the packet contains characters non-UTF-8 encoded: no anomalies. In detail, we have built a connection packet with the client id containing particular characters and the experiment was handled correctly by all brokers; • Keep-alive field in connection packet as a string: in all brokers there is the client disconnection due to malformed packet; • subscription (or publication) in an invalid wildcard: in all brokers there is the client disconnection due to “invalid topic”; • topics and wildcard encoded in: utf-16, zzlib, bz2 and base64. In the last three cases, there were no anomalies to report. In the utf-16 experiment, in all brokers the client disconnects. A particular experiment was the one with many “ / ” in the topic value; in Mosquitto, EMQ X, Moquette and Aedes there was client disconnection while in HiveMQ there was a cut of the topic and then the client subscription; • packets flood with QoS 0: all brokers handled the flood well; • invalid protocol name (or version) in the connection packet: in all cases, the client disconnects; • sending a pubrel packet that references a publication packet that was never sent: all brokers, except for Aedes, sent back a pubcomp message. In Aedes there is the client disconnection.
In addition to tests on brokers, we also carried out tests on client libraries available in the web. In particular, we studied three diferent client libraries: paho-mqtt8, mqttools9 and mqtt.js10; the ifrst two are written in python while the third is written in javascript. Again, we considered metrics like the number of stars and forks on GitHub repositories. However, the experiments have not found particular anomalies. Here there is a list of tests we tried: • invalid QoS level: all libraries report an error about the QoS, blocking the sending of the packet; • invalid wildcard subscription: in this case mqtt.js generates an “Invalid topic" error, while the other two libraries timeout; • client id not encoded in utf-8: in mqttools the client cannot connect to the broker, in paho-mqtt there is a successful connection to the broker and mqtt.js generates an error with the consequent client disconnection; • publication (or subscription) to a topic with a length more than 65536 characters: in all libraries there is the client disconnection.
In “home automation” the MQTT protocol is widely used as most smart devices supports it. Many software applications allow you to use the protocol to manage the smart devices, and one of them, for example, is Home Assistant; also Amazon, in AWS IoT, uses MQTT to connect the user’s devices to other devices and other services.
We decided to perform the previous experiments on a physical device. In this case, we tested a Shelly light bulb that supports MQTT: it is possible, for example, to turn on or of the device through specific commands sent in the local network. In this device, the protocol configuration can be done in a simple web interface, available in the local network, where the user has to 8https://pypi.org/project/paho-mqtt/ 9https://pypi.org/project/mqttools/ 10https://github.com/mqttjs/MQTT.js specify the broker’s IP and port. The username and password are not mandatory during the configuration; this could be a security issue, depending on the context. This device does not have an “anti-flood” regarding the packets it receives; for example, it is possible to turn of and on the light bulb repeatedly and quickly by sending a PUBLISH packet on the specific topic with specific content. The software that runs in the light bulb is the same as other Shelly devices, so this problem also afects them. Therefore, it is possible to send many packets that overload the device’s electronic components to make it useless.
To confirm the obtained results in the brokers, we performed on the device the same set of experiments previously carried out on both brokers and clients. For example, the experiment “Publish QoS 2 and 1" (discussed in Section 4.1) has confirmed the expected results. In this case, we sent a “turn on packet” with QoS 2 and then we sent a “turn of packet” with QoS 1. When Mosquitto was the broker used, the light bulb turned on but then did not go of, while in all other cases, the light bulb turned on and then turned of.
In addition to these experiments already performed for the various brokers, we have tried to generate some bufer overflows , through the payload sent to the device, with a consequent DoS. However, the light bulb passed all tests without errors; in particular, the device ignores any form of payload other than what it expects to receive.
Interesting results have been obtained from the experiments carried out on brokers, clients,
and the physical device. In [
In our work, the model of the attacker includes the capability to modify the MQTT packet
lfow, delaying the transmission or making it out of order, or modifying MQTT packets payload,
injecting invalid values. This capability can be exploited with limited access to the broker or
intermediate network devices, or even remotely, by using other attacks like Distributed
Denial-ofService or flooding against a network device in the path of the packet flow (for delaying packets,
for example). Some of these vulnerabilities can be exploited with an older version of TLS
protocol itself11: for example, SSL used a vulnerable Message Authentication Code until TLS [
We described bad behaviours for brokers in Section 4.1.1. Some of them can be classified as vulnerabilities, and they can lead to attacks if some conditions happen. In fact, we saw that brokers publish some messages violating the protocol state machine in some tests. An example of this is the out-of-order Aedes (and other brokers) use of pubcomp, which might be used to trigger a replay attack if the pubcomp itself is delayed or dropped by a malicious actor. This attack can disrupt or even damage some devices: for example, IoT-mechanical devices can be continuously triggered until the mechanical part is over-stressed.
11Note that low-cost IoT devices often implement old protocols, sometimes even partially
Another violation of the standard which leads to a vulnerability (in all brokers but Mosquitto) is the bad handling of long topics: in the MQTT standard, the maximum length topic is 65536 bytes. However, trying to publish to a very long topic (>4096 bytes) leads to a disconnection of the client. A malicious actor that can inject (even indirectly, think user-provided information) some characters in the topic may cause a Denial of Service for that client. Even worst, in Aedes there is a crash of the broker itself, leading to a Denial of Service for the entire MQTT network.
Some violations of the standard are so misinterpreted that each broker does a diferent thing: in Double publish QoS 2 test, nearly all brokers (the only exception is Mosquitto) violates the "unique identifier" feature of MQTT in diferent ways. This causes no direct impact as a violation, but it can be exploited if some client library shows some bad handling of this situation.
Among all brokers, our tests show that Mosquitto seems to be the strongest one in terms of MQTT standard adoption, and so the safest from a security point of view.
Instead, client libraries have shown only minor issues, many of them relating to encoding errors or long topic subscription issues. Our tests show that they are quite robust, sometimes even better than some brokers.
MQTT is considered one of the enabling technologies for the IoT ecosystem. It is adopted by almost all IoT applications that run on devices with limited computational power, thanks to the high availability of open source libraries implementing MQTT. In this paper, we have presented an empirical study of the most popular implementations of both brokers and clients, considering the possible behaviour deviations from the standard that could lead applications to possibly inconsistent or even critical states. We also tested a physical smart-home device. The results of our experiments were noticeable: while almost all the considered libraries are correctly handling most of the interactions, as expected, some anomalies have been detected that could be exploited and target the applications, mainly exposing them to denial of service attacks.
Given the promising results, we plan to expand the number of considered libraries further and to include in our experiments some real applications to create some proof-of-concept attacks that exploit the found anomalies. Similarly, we plan to extend the experiments also considering the libraries that also support the new version of the MQTT protocol, namely version 5.
This research has been partially supported by MIUR (Italian Ministry of Education, University, and Research) under grant “Dipartimenti di eccellenza 2018-2022” of the Computer Science Department of Sapienza University of Rome.