Analysis of Risks in MQTT Protocol Interfaces

xxhzz

@PortalLab Lab

MQTT is a “lightweight” communication protocol based on the publish/subscribe model, built on the TCP/IP protocol. It is lightweight, open, simple, and designed to be easy to implement, making these features particularly suitable for constrained environments such as machine-to-machine (M2M) and Internet of Things (IoT) environments.

Publish/Subscribe Model

In the MQTT protocol, there are three roles and one main concept: the three roles are Publisher, Subscriber, and Broker, with the main concept being Topic.

The sender of the message is called the Publisher, and the receiver of the message is called the Subscriber. Both the sender and the Subscriber will connect to the Broker, which is generally the server. The container that stores messages in the Broker is called the Topic. The Publisher sends messages to the Topic, and the Subscriber must first “subscribe to the Topic” before receiving messages. In each subscription, the Subscriber can receive all messages from the Topic.

The simplified diagram is as follows:

Main Features:

• The publish-subscribe model differs from the traditional client-server model, as Publishers and Subscribers do not need to establish direct contact.

• It allows multiple Publishers to send messages to a single Subscriber and multiple Subscribers to simultaneously receive messages from a single Publisher. The core of this is that the MQTT Broker is responsible for all message routing and distribution, minimizing network traffic with very low transmission consumption and protocol data exchange.

• The Broker can filter messages, ensuring that each Subscriber only receives messages of interest.

MQTT Topic

The Topic is an identifier (ID) used by the MQTT Broker to identify legitimate clients transmitting messages. Every client that wants to send a message will publish it on a certain Topic, and every client that wants to receive messages will subscribe to a certain Topic.

The Topic is a string that can consist of one or more Topic levels, with each level separated by a forward slash (/), for example: raspberrypi/model3/sensor/data.

A Topic:

• Must have at least one character.

• The Topic string can contain spaces to allow for more readable or descriptive topics.

• A single forward slash is a valid Topic, which can represent broad topics or serve as a wildcard for simultaneously subscribing to multiple Topics.

• MQTT Topics have “+” and “#” wildcards, as shown in the figure below:





• Is case-sensitive, for example: raspberrypi/model3/sensor/data and Raspberrypi/Model3/Sensor/Data are two different Topics.

For example, some Topic examples from the official website:

Application Scenarios

The MQTT protocol is widely used in Internet of Things (IoT), Industrial Internet of Things (IIoT), and machine-to-machine (M2M) applications.

MQTT Message Types

The types of MQTT messages are mainly divided into CONNECT, CONNACK, ONNECT, SUBSCRIBE, SUBACK, UNSUBSCRIBE, etc.

The payload actually refers to the message content (the content of the message published by the application). The above message types are categorized according to the roles of Publisher, Subscriber, and Broker, and the request order. For example, CONNECT represents the first message sent from the client (Publisher) to the Broker; CONNACK is the message returned to the client by the Broker after receiving the client’s message for the first time. It is worth noting that the payload (message content) of each message type is different.

CONNECT Message

To initialize the connection, the client must send a CONNECT message to the Broker.

If this CONNECT message is formatted incorrectly or if opening the socket (because it is based on the TCP/IP protocol stack that requires initializing the Socket connection) takes too long, or if the connection message takes too long to send, the Broker will close this connection.

A MQTT client sends a CONNECT message, which may include the following information:

For other related information fields, you can refer to: https://xie.infoq.cn/article/e345e3a4b3ad74c5893bb8cb8

MQTT Protocol Packet Structure

An MQTT packet consists of three parts: Fixed header, Variable header, and Payload.

• Fixed header: Exists in all MQTT packets, indicating the packet type and the grouping class identifier.

• Variable header: Exists in some MQTT packets, the packet type determines whether the variable header exists and its specific content.

• Payload: Exists in some MQTT packets, indicating the specific content received by the client. MQTT is data-agnostic and can send any text, images, encrypted data, and binary data.

All MQTT packets contain the above three parts, and the difference in each message type lies in the differences in the Payload, for example:

The risks of MQTT API being vulnerable mainly come from three aspects: authentication/authorization flaws, insecure transmission processes, and security vulnerabilities in the application itself. Below, we summarize the attack risks of the MQTT API from these aspects.

Authentication/Authorization Flaws

1. Anonymous Connection Login/Unauthorized Connection

MQTT allows clients to connect to the message broker anonymously without authentication or providing credentials, meaning anyone can access the message broker simply by establishing an MQTT connection without verifying their identity. Anyone can publish or subscribe to messages through the MQTT API, which can lead to security consequences such as sensitive data leakage or malicious attackers sending harmful commands.

For MQTT services that may have this security risk, testing can be conducted through some online MQTT access platforms, such as: http://www.emqx.io/online-mqtt-client/

After logging in anonymously or unauthorized, one can check for sensitive information by attempting to enumerate other topics.

2. User Password Brute Force

Since MQTT uses a simple verification method through username and account, it is vulnerable to username and password brute force attacks in the absence of other login authentication mechanisms. This is not much different from traditional login brute force attacks, and due to human negligence, usernames and passwords may be set too simply, allowing malicious attackers to easily succeed in brute-forcing through common weak password dictionaries for MQTT devices.

Tools for MQTT user password brute forcing can use mqtt-pwn, https://github.com/akamai-threat-research/mqtt-pwn

The brute force command is as follows:

bruteforce --host host --port port -uf USERNAMES_FILE -pf PASSWORDS_FILE

The brute force dictionary is stored in the mqtt-pwn/resources/wordlists folder.

3. Spoofing Subscriber/Publisher Attack

When we connect to the MQTT Broker through anonymous login/unauthorized access or by brute forcing username and password, due to the related MQTT API permission control flaws, malicious attackers can impersonate subscribers by using the MQTT wildcard # to subscribe to all message topics.

Of course, in the case of permission control failure, malicious attackers can also impersonate legitimate publishers and issue malicious commands to the corresponding subscribers.

Insecure Transmission Process

1. Sniffing Account Passwords from Traffic

Based on the TCP protocol, the MQTT protocol does not use TLS encryption during traffic transmission, which allows malicious attackers to sniff usernames and passwords from traffic. Of course, using MQTTS eliminates this risk.

Below is a capture of some MQTT traffic, where the usernames and passwords of the MQTT service can be clearly seen.

After obtaining the usernames and passwords, further attacks can be utilized.

2. Man-in-the-Middle Attack

The reason is also that the MQTT protocol does not use TLS encryption during traffic transmission, allowing malicious attackers to directly modify the messages sent by the sender in the traffic. This is similar to using Burp Suite as a middle proxy between the client and the Broker to modify the messages during transmission.

Application Security Vulnerabilities

1. Vulnerabilities in the Application Itself

Risks of security vulnerabilities caused by code defects in MQTT-related applications, such as CVE-2017-7296, CVE-2017-7650, CVE-2018-17614, CVE-2019-5432, CVE-2020-13849, etc.

For example, CVE-2020-13821, HiveMQ is an enterprise-level MQTT Broker that provides high-performance, high-availability, high-scalability, and high-security enterprise services. In this vulnerable version, there is a stored XSS vulnerability. Below are the details of the vulnerability:

By using a connection tool, an XSS attack payload <img/src=x onerror=alert(1)> is added to the client ID in the connection configuration.

Returning to the management platform, clicking Refresh Snapshot in the clients module triggers the attack.

HiveMQ management platform successfully pops up the window.

2. Default Passwords on Management Platforms

In addition to MQTT applications, there are also management platforms, one typical example being EMQX, which provides users with an intuitive web dashboard for managing and monitoring devices, etc. Due to human negligence, management platforms may use default passwords for login.

The default password is: admin/public.

Other Security Risks

Web Applications Leaking Account Passwords

In some IoT devices, some connect directly to the MQTT Broker to subscribe to topics to display related information, which allows malicious attackers to find the connecting host, port, username, and password information through JavaScript files.

Next, we will analyze several CVE vulnerabilities to understand the principles behind the generation of vulnerabilities in the MQTT protocol.

CVE-2017-7650

This vulnerability originates from Mosquitto, an open-source MQTT message broker used for implementing the MQTT protocol. It allows devices and applications to communicate messages between different networks, enabling real-time communication and data exchange. Mosquitto provides many features such as publishing (Publish) and subscribing (Subscribe), and QoS (Quality of Service) level control, etc.

In Mosquitto versions before 1.4.12, there is a privilege escalation vulnerability that allows locally or remotely connected clients to access MQTT topics they should not have access to, and similar issues may exist in Mosquitto’s third-party authentication/access control plugins.

For Mosquitto, not only can usernames and passwords be used to restrict access to the MQTT Broker, but ACL (Access Control Lists) can also be used to restrict users’ access to topics. Here are a few examples:

# Grant all permissions to user1user user1topic readwrite #
# Allow user2 read and write permissions for topic foo/bar/bazuser user2topic foo/bar/#
# Allow jaythree to read/write anythinguser jaythreetopic #

The cause of the vulnerability is that when using ACL files to restrict users’ access to topics, if the username/client ID is set to “#” or “+”, it can bypass the ACL restrictions.

Below is the patch for version 1.4.x, clearly showing that checks for “+” and “#” have been added to the relevant functions for authentication permissions.

CVE-2017-7651

This vulnerability also exists in all versions of Mosquitto 1.4.14 and earlier. This vulnerability allows unauthenticated clients to send carefully crafted CONNECT packets, causing the broker to use a large amount of memory. If multiple clients do this, it can cause out-of-memory conditions, and the system may become unresponsive, or the broker may be terminated by the operating system.

Below is the patch for version 1.4.15, which resolves the issue by limiting the size of CONNECT packets and adding a memory_limit configuration option that allows the broker to limit the amount of memory it uses.

Combining the previously discussed common attack methods for MQTT, bypassing login permission verification or sniffing account passwords makes exploiting this vulnerability even easier.