Whispers of the Machines: Exposing MQTT Hidden Talks

Why does IoT need to be secure?

With over 15 billion IoT (Internet of Things) devices interconnected worldwide, machines can now ‘talk’ to each other seamlessly. This is enabled by protocols like Message Queuing Telemetry Transport (MQTT), which orchestrate our smart homes, cities and critical infrastructure. The extensive use of MQTT, a lightweight machine-to-machine protocol critical for IoT communication, carries substantial cybersecurity risks. And unsurprisingly, its vulnerabilities have made it a prime target for hackers, breaching smart homes and industrial networks alike. This emphasises the urgent need for penetration tests to uncover vulnerabilities and thus proactively protect both infrastructure and end-user devices against evolving threats.

Malicious actors have taken advantage of the way MQTT operates to gain unauthorised access to the infrastructure, execute denial of service (DoS) attacks or gain full control over smart home devices.

The history of IoT and MQTT

It has been an exciting journey since 1982 when students at Carnegie Mellon University connected the soda vending machine to the local network, allowing them to remotely check whether cold drinks were available or not and thus creating an IoT device for the first time.

Over the past decade, the Internet of Things has surged, boasting over 15 billion connected devices worldwide. By 2030, Exploding Topics anticipates that the Internet of Things will encompass over 29 billion interconnected devices worldwide.

MQTT has fundamentally contributed to the adoption and proliferation of IoT devices by allowing communication between them. It was specifically designed for environments where devices have limited capabilities and operate on networks with low bandwidth, high latency or unreliable connections.

This machine-to-machine (M2M) protocol is based on the TCP/IP protocol and uses a publish/subscribe messaging model, where a publisher issues messages on a specific subject and a subscriber must subscribe to that subject to receive the message. The messages are published to a broker, with the MQTT broker filtering the messages based on their topic and distributing them to subscribers.

Every MQTT packet contains a fixed header that, among other things, defines the type of packet. The fixed header is structured like this:

The list below shows the value sent in the fixed header:

• CONNECT (1): Initiated by the client to request a connection to the server.
  
• CONNACK (2): The server’s acknowledgement of a successful connection.
  
• PUBLISH (3): Used to send a message from the client to the server or vice versa.
  
• PUBACK (4): Acknowledgement of a PUBLISH packet.
  
• PUBREC (5): Part of a message delivery protocol ensuring the message is received.
  
• PUBREL (6): Further assurance in message delivery, indicating a message release.
  
• PUBCOMP (7): Final part of the message delivery protocol, indicating completion.
  
• SUBSCRIBE (8): A client’s request to listen for messages from a topic.
  
• SUBACK (9): The server’s acknowledgement of a SUBSCRIBE request.
  
• UNSUBSCRIBE (10): A client’s request to stop receiving messages from a topic.
  
• UNSUBACK (11): The server’s response to an UNSUBSCRIBE request.
  
• PINGREQ (12): A heartbeat message sent by the client.
  
• PINGRESP (13): Server’s response to the heartbeat message.
  
• DISCONNECT (14): Initiated by the client to terminate the connection.
  
• Two values, 0 and 15, are marked as reserved, and their use is forbidden.

As can be deduced from the above description, MQTT was deliberately designed to be simple, enabling easy implementation across various environments. As a result, it lacks basic security mechanisms and applying adequate security features is left to the implementation.

In recent years, several critical vulnerabilities have highlighted serious weaknesses either in the implementation of the protocol or in the protocol itself, for instance:

• Remote Memory Leak with QoS 2 Messages (CVE-2023–28366): Vulnerability affecting the Eclipse Mosquitto MQTT broker, where handling Quality of Service (QoS) level 2 messages can lead to a remote memory leak. This issue can allow attackers to exhaust system memory, potentially creating a denial-of-service (DoS) condition.
  
• Insecure Default Configuration (CVE-2017–7650): This vulnerability affects some Eclipse Mosquitto MQTT brokers, where the default configuration does not enforce authentication. This insecure default setting allows attackers to connect to the broker without credentials, potentially leading to unauthorised access and data leakage.
  
• Excessive CPU Consumption with Empty Connection (CVE-2023–5632): In the Eclipse Mosquitto MQTT broker, before and including 2.0.5, an empty connection request can cause excessive CPU consumption. This flaw allows attackers to potentially create a DoS condition by exhausting CPU resources through repeated empty connection attempts.
  
• Subscription Revocation Issue (CVE-2021–34434): In the Eclipse Mosquitto MQTT broker, improper handling of subscription revocation can lead to unauthorised message delivery. This bug allows attackers to continue receiving messages on revoked subscriptions, potentially leading to information disclosure or unauthorised data access.
  
• Buffer Overflow (CVE-2020–11976): Buffer overflow vulnerabilities in MQTT implementations could be exploited to run remote code execution attacks. This flaw allows attackers to execute arbitrary code and cause a DoS condition by crashing the servers running vulnerable MQTT software.

How can you prevent hackers from abusing these vulnerabilities?

Pentesting MQTT implementations using the same tactics, techniques, and procedures as real adversaries is crucial. This aids in proactive defence against potential cyber threats within IoT environments.

To demonstrate how easy it is to find vulnerable implementations, let’s use the open source intelligence tool Shodan. By entering the string “port:1883 “MQTT”” in Shodan’s search box, we can search for the MQTT protocol on port 1883 – the default port for MQTT brokers that don’t use TLS for security. This helps identify available broker servers. As shown in Figure 3, there are 606,533 brokers with the default port indexed by Shodan.

 Figure 3: MQTT Broker on port 1883 in Shodan

As shown in Figure 4, each broker is accompanied by its MQTT connection code. Brokers with a connection code of “0” are more vulnerable to attacks because they do not use any client authentication mechanism, allowing anonymous publishers or subscribers to connect freely.

Figure 4: MQTT connection code in Shodan

These high results are due to the fact that MQTT authentication is optional. Even if authentication is being performed, encryption is not used by default. Man in the Middle (MITM) attacks can still be executed to steal passwords.

In the context of a real pentest, the expert would focus exclusively on the Target-of-Evaluation. If it happens to be configured in the same way as the ones we found on Shodan, it’s relatively simple to use open source tools, such as the following, to connect and subscribe to all topics:

• https://github.com/bapowell/python-mqtt-client-shell 
• https://github.com/akamai-threat-research/mqtt-pwn 

Once the connection is established, an attacker could ‘listen’ to sensitive data exchanged between the broker and the subscriber.  Even if client authentication is set, it is possible to intercept the credentials if a “Connect” packet from the publisher is sniffed by an attacker/pentester in the same network, since MQTT brokers do not use TLS for security by default.

Figure 5: Sniffing MQTT Connect

The bottom line

Due to the complexity of the IoT ecosystem, we must remember that many protocols and systems like MQTT were not originally designed to take cybersecurity into account.

MQTT is one of the protocols used in IoT systems where the attack surface is particularly wide. Attackers could use search engines like Shodan to find MQTT public servers, run DoS to devices connected to that broker or send malicious data to its clients, potentially compromising the whole IoT infrastructure.

A few tips for MQTT and IoT security

• Avoid relying solely on username and password for authentication.
• Employ mutual TLS between devices and the broker if the devices support it.
• Get certificates and create unique public-private key pairs for each client, minimizing credential-based risks.Only clients with valid certificates will have access to the broker
• Implement Access Control List (ACL), token-based authentication and IP whitelisting/blacklisting.
• Perform authorisation checks after the solution is built.
• Expose only authenticated access to the internet, and avoid internet exposure if possible.
• Keep the broker updated to patch newly discovered vulnerabilities.
• Use MQTT v5 to take advantage of newer features, such as flow control and server authentication.
• Ensure the broker supports security mechanisms to detect attacks like repeated connections or authentication attempts or implement a solution to detect and block such attacks.

Interested in learning more about pentesting? Get in touch with our expert team to schedule a discussion.