The Internet of Things (IoT) is omnipresent, connecting more and more physical devices with the digital world. Nevertheless, the topic of IT security is neglected in the process. Weak passwords are “hardcoded”, data is transmitted unencrypted, and many devices are accessible from the Internet.
Table of contents
Attackers worldwide are grateful for such vulnerabilities and exploit them with increasing frequency. A well-known example of this is the Mirai malware, which has infected numerous IoT components and used them for denial-of-service attacks in recent years.
This article will therefore look at the MQTT protocol, one of the most important IoT protocols, from a security perspective and provide an overview of sensible hardening measures.
MQTT – Overview
The Message Queuing Telemetry Transport (MQTT) protocol is a publish-subscribe protocol that allows data to be easily sent and received between IoT devices (see HiveMQ).
This requires at least the following components within an MQTT network:
- MQTT Broker
- MQTT Client
One of the reasons why MQTT is so popular is that it is a lightweight protocol that works without major problems even on weak hardware such as microcontrollers. Thus, MQTT communication can be realized for almost any IoT device.
However, this very characteristic also brings with it some disadvantages in terms of security. Depending on the IoT device, the use of certain security features is limited by insufficient hardware.
MQTT Broker
The MQTT broker is the pivotal point of MQTT communication. It receives data sent to it by clients. It transmits this data to other clients that – depending on the type of data – have registered as subscribers. So-called topics are used, which specify which data is sent. A topic can look like this, for example:
Production/Control System/Temperature
A client can thus subscribe to the topic Production/Control System, for example, and will then receive all data published on this topic.
MQTT Client
An MQTT network can consist of any number of MQTT clients. These can be both publishers and subscribers. As a publisher, a client publishes new data within a topic and sends it to the MQTT broker, which distributes it further. As a subscriber, a client can subscribe to one or more topics and receives data about these topics, as described above.
It should be noted that a client can act as a subscriber and as a publisher at the same time. In addition, the communication is event-driven. Only when new data is sent, a transmission takes place.
An overview of the individual roles within an MQTT network is shown in the following illustration:
MQTT – Attack Vectors and Hardening Measures
In the following, an overview of the best-known attack vectors within the MQTT protocol is given and reasonable hardening measures are derived from these.
1. Missing Encryption
As in many other IoT protocols, the topic of encryption is regularly neglected in the MQTT protocol as well.
In addition to port 1883 for the unencrypted transmission of data, there is also port 8883, which has been reserved by the Internet Assigned Numbers Authority for data transmission using TLS/SSL by MQTT. Nevertheless, many companies still do not encrypt data traffic today, so that sensitive information such as passwords continues to be transmitted in plain text and can be read by a potential attacker.
This is a major risk, especially if the MQTT devices are connected to the Internet.
Just as with a transmission using the HTTP protocol, encryption should therefore also be used by default within the MQTT protocol.
For this, it is recommended to configure the broker accordingly so that it encrypts connections via TLS by default. This involves setting up a new listener on the previously mentioned port 8883, through which the connection is made. It is also important to note that the minimum TLS version should be specified. This ensures that connections do not use insecure TLS versions, such as TLS 1.0 or TLS 1.1.
2. Absence or Weakness of Access Control
The same applies to authentication/authorization: MQTT provides the necessary functionalities, but it is up to the developers to implement them correctly.
In the default settings, many MQTT servers do not check the identity when a connection is established. This allows arbitrary users to subscribe to individual or all topics (by using wildcard parameters, such as “#”) and to read the sent data.
Here, too, the risk of a successful attack increases if the MQTT device is connected to the Internet.
Various methods can be used to check authenticity. The simplest way is a combination of username and password, which is sent from the client to a broker. Some MQTT brokers are also able to handle X509 client certificates or even use an Oauth 2.0 flow, which increases the security further.
Particularly for more complex methods, many brokers nowadays offer corresponding plugins, which make it comparatively easy to set up secure access control.
Further information on access control can be found at:
- https://mosquitto.org/documentation/authentication-methods/
- http://www.steves-internet-guide.com/creating-and-using-client-certificates-with-mqtt-and-mosquitto/
- https://www.hivemq.com/blog/mqtt-security-fundamentals-oauth-2-0-mqtt/
3. Missing Checks in the Registration of New Devices
In many cases, an attacker is able to set up their own MQTT clients and connect them to the MQTT network. This is due to the fact that in most cases no mechanism is implemented to ensure that only trusted devices can be included into the network.
It is therefore recommended to identify each connected client via a unique identifier and to add new devices only after sufficient verification. As before, many manufacturers have already implemented such mechanisms as a standard feature, so that the use of identity control can be activated without much effort.
4. No Compliance With the Principle of Least Privilege
Within an MQTT network, each client is authorized to both create new topics and subscribe to any topics. While this ensures easy use of the network, it also poses a potential risk. An attacker who has successfully registered a client in the network thus has access to the entire network. For this reason, the so-called “principle of least privilege” should be applied, which grants each device only as many rights as necessary. This ensures that only selected clients are allowed to create topics and publish data, while all other clients are only allowed to subscribe to certain topics.
Some MQTT brokers provide Access Control Lists (ACLs) for this purpose, which can be used to assign permissions in a fine-grained manner. Rules can be created for all or only for individual clients. It is advisable to restrict the rights of the clients as far as possible before creating individual exceptions. This ensures that clients that are added to the network at a later time do not automatically have excessive rights.
Conclusion
The MQTT protocol is one of the most widely used and important IoT protocols and is used in a large number of companies. While the protocol offers sufficient options to ensure secure operation, these must be configured manually.
However, once one is aware of the risks, implementing the measures significantly increases the security of the company. Performing a penetration test of individual IoT devices as well as interconnected networks can provide valuable assistance and identify vulnerabilities. In these as well as in all other cyber security topics, we are happy to help. We look forward to hearing from you:
