MQTT Series #2: Potential risks of exposed MQTT brokers

Using Shodan, a list of topics can be found for exposed MQTT brokers, as can be seen in our example below (though not all exposed brokers have a list of topics on Shodan).

This can be done by subscribing to a topic using the wildcard ‘#’. The MQTT client uses wildcards to subscribe to multiple topics simultaneously, and ‘#’ can be used to subscribe to multiple levels of topics simultaneously . A subscriber can use this to subscribe to multiple topics with a single subscription message. However, this feature could be abused if there is no limit on subscriptions. An attacker could obtain any MQTT messages across the entire server by subscribing with the wildcard ‘#’ . Therefore, it is important to restrict the use of wildcards, especially ‘#’, since it allows subscription to any topic and therefore access to a tremendous amount of potentially sensitive data.

It’s important to note that topics listed above without a ‘$’ symbol will be retained messages (These ‘$’- marked topics are reserved for the internal statistics of the MQTT broker). A retained message is a normal MQTT message with the retained flag set to ‘ true ’ . The broker stores the last retained message and the corresponding QoS for that topic, and only one retained message is saved per topic.
Each client that subscribes to a topic of the retained message receives the message immediately after he or she subscribes.

The retained message eliminates the wait for the publishing clients to send the next update.

Since the MQTT protocol is based on the principle of publishing messages and subscribing to topics, subscribers will not be able to know who is publishing a message. Subscribers only subscribe to topics that they are interested in. Therefore, if anyone can connect to a broker and publish a message to the existing topics, it’s easy to alter or overwrite the data.

Furthermore, in order to secure your MQTT brokers and messages, implement Transport Layer Security (TLS) when possible. However, many IoT devices have limited resources and may not be able to support TLS due to its significant overhead. In such a case, it would be good to implement payload encryption. Even if someone sniffs your MQTT messages and gets information on the topic, the payload will be protected. If someone tries to publish a message with a topic but not an encrypted payload, a subscriber would notice that it’s not the right message and someone is trying to overwrite the payload on the topic.

Lastly, Shodan has a “compromised” tag. Even though we are not sure how they define ‘compromised’ devices, it’s interesting to note this detail. Even though the volume is very small, some compromised MQTT brokers are tagged. We’ve checked these brokers, and found that ActiveMQ has more compromised brokers than Mosquitto. Since ActiveMQ is designed for enterprise use, we can conclude that enterprise brokers are likely to be more easily targeted.