By Ryan Flores, Charles Perine

In the age of cloud computing and machine-to-machine (M2M) communication, software and device vendors have an outsized role in securing their customers' data. Unfortunately, customers may not be fully aware of this and do not demand data security as a result. This leads to a dangerous situation in which software and products leak information without the customer knowing.  This is why the communication protocols and security mechanisms used by software and devices need to be validated, especially for those like Message Queuing Telemetry Transport (MQTT) whose use has increased significantly in the past decade.

MQTT is a standard messaging protocol that facilitates message queue-based communication by allowing endpoints to exchange data in a publish-subscribe fashion. This data exchange is mediated by intermediary entities called brokers; in MQTT, endpoints can publish messages to a broker and/or subscribe to a broker to receive certain messages. These messages are organized according to topics that works like a system for coordinating and routing messages to subscribers.

In 2018, we reported on the various vulnerabilities and insecure implementations of MQTT, a communication protocol widely used in both internet-of-things (IoT) and industrial-internet-of-things (IIoT) deployments. In this follow-up research, we’ll show how easy it is to discover insecure deployments of MQTT, how to identify customers of these insecure deployments, what data is being transmitted, and explore how an attacker can potentially misuse the data or abuse the insecurity of the MQTT broker. 

Discovery

Using online scanning tools like Shodan, Censys and ZoomEye, we discovered tens of thousands of available TLS-secured MQTT (MQTTS) brokers that did not have authentication. We then performed some of our own scanning using Network Mapper (Nmap) and the mqtt-subscribe script to verify that the brokers were still available; NMAP gave us over 9,000 brokers. Filtering for the available unauthenticated brokers based on host names and domain names, we narrowed down our monitoring to almost 100 systems. Reviewing the data we collected from those systems provided interesting insights into the types of data being sent via MQTT and its uses.

Identification

In addition to the data we collected from the MQTTS brokers, we used a few methods to learn about the customers of these services. Some of these methods were obvious, like looking at the domain names (for example, mqtt.companyX.com), subdomain names (for example, companyX.mqttbroker.com) and any identifying information (for example, [email protected]). Combining user discovery with unauthenticated access, an adversary could target a specific company’s data, either by monitoring or manipulating the data. Unauthenticated access to these systems reduces the confidentiality and integrity of the data.

Our aforementioned 2018 research on MQTT security focused on insecure MQTT deployments and vulnerabilities in the protocol itself. We also discovered data from healthcare monitors, assistive technologies, asset trackers, messaging apps, and smart farming.

In our scan of MQTTS brokers in 2022, we found more unique use cases such as industrial temperature monitoring (for use on freezers, refrigerators, or industrial processes), people counters (to monitor foot traffic and capacity of establishments, malls, or event venues), productivity suites (to reserve meeting rooms, take meeting notes and action items, and send reminders), and a warehouse inventory system (containing RFID tracking, and warehouse and shipment information).

What data is being sent and how adversaries can misuse it

In the following subsections, we show some of the data we discovered during our collection phase. While we monitored over 90 servers, these were some of the more interesting use cases. An adversary that could monitor the data below would be able to find customers of the services, gather intelligence on temperature settings for printed circuit board (PCB) baking rooms, discover internal meeting notes from a company, remotely monitor high and low access times to public facilities, or determine production and shipping information based on inventory tracking. If that adversary were to send different data to these systems, they could trigger alarms when the temperatures for certain products exceed the storage requirements, affect the safety of those in a facility by under-representing or over-representing the number of visitors or employees, move inventory around a warehouse, or send equipment to the wrong location.

Temperature

The first area we investigated was temperature probes and the logging of temperature data. We looked at the data being sent and the type of communication between a couple of temperature monitors. We discovered unauthenticated MQTTS on one of devices and were able to perform a man-in-the-middle (MitM) attack on its communication. Initially, we observed what type of data was being transmitted, then monitored the server for a week. We were able to profile some of the temperature data being sent to an MQTT broker. We took those readings and organized them by temperature ranges (Figure 1). 

• Cryogenic temperatures: –273 °C to –123 °C
• Deep freeze temperatures: –122 °C to –20 °C
• Freezing temperatures: –20 °C to 0 °C
• Refrigerator temperatures: 1 °C to 15 °C
• Room temperatures: 15 °C to 30 °C
• Above room temperatures
• Cooking or baking temperatures

Figure 1. Profile of temperature data collected

From here, we may be able to determine what different devices and customers are monitoring. Scientific uses, like those common to fertility clinics and vaccine storage, will likely be –50 degrees Celsius and below. Storage of food and medical materials are normally in the range of 0 to –50 degrees Celsius; there are also  food, medical, and various uses that belong to the refrigerator temperature range. Home-related uses, building environmentals, and nursery automation fall within the room temperature range. Cooking, PCB manufacturing, saunas, and the like will be in the hotter temperature ranges.

Figure 2 shows the tracking of temperature in a residential building and how the temperature fluctuates throughout the week. This data is sent to the MQTT broker and can then be viewed online. The initial data looks like a nice smooth curve.

Figure 2. Unmodified temperature data logged

 Next, we captured data that had been sent, modified the values, then sent the data again to observe what would happen. Once the modified data was replayed, a jagged pattern emerges as both sets of data are displayed, as shown in Figure 3.  This illustrates how the temperature monitoring system's data can be tampered with, enabling a hypothetical attacker to trigger alerts or specific actions, potentially leading to the wastage of essential items like food or medicine due to the strict temperature requirements these products necessitate.

Figure 3. Modified temperature data logged

Productivity suite

One MQTT broker we monitored belongs to a productivity suite company that offers a product designed to schedule meetings, record meeting minutes, notify attendees of upcoming meetings, and set up alerts or action items. From what we could tell, MQTT is being used to dispatch messages to email and SMS alert systems. The following figures show two intercepted messages from the MQTT broker: The first was sent via email (Figure 4), while the other was sent via SMS (Figure 5).

Figure 4. Example of meeting data sent to MQTTS broker

Figure 5. Example of meeting data sent to MQTTS broker

Meeting schedules, reminders, minutes, and alerts are not the only messages sent through MQTT. Over the course of our monitoring, we were able to see security-related messages: One is a notification for the creation of a new user — complete with the user’s full name, username and password — while the other is the message for a verification code that is used for password reset (Figure 6). An example of a notification message for new user creation sent via unencrypted MQTT is as follows:

userservices/user/create || {"tst":"2022-09-19T01:26:35.181671-0600","topic":"userservices/user/create","qos":0,"retain":0,"payloadlen":133,"payload":"{\"login\":\".\",\"password\":\".36\",\"firstname\":\"\",\"lastname\":\"\",\"mail\":\"@.\",\"language\":\"\"}"} ||

Figure 6. Password reset form sent via MQTTS to email

Inventory

We also discovered six subdomains hosting MQTT brokers for large retailers, four of which are Fortune 500 companies. The domain belonged to a company that provides inventory tracking services. In the MQTT data, we found messages containing RFID tracking, warehousing, and shipping information (Figure 7). Here are a few examples of the messages we discovered:

• “Returnable container added to wrong shipment.”
• “Batch belongs on a pallet.”
• “Shipment will be updated with a quantity different than Expected.”
• “The RFID tag is loaded to wrong dock E02, the assigned dock is E03.”

Figure 7. Example of inventory messages

People counting systems

People counting systems are increasingly being implemented by establishments like shopping malls or event venues.  Modern people counting systems are mainly composed of cameras and artificial intelligence (AI) to identify people passing through the doors or gates.  Ingress and egress data is then reported to brokers or dashboards for monitoring. Figure 8 shows data from a shopping mall in a popular tourist location, while Figure 9 shows data from a shopping mall in a suburban area that is directly connected to transport hubs.

Figure 8. Foot traffic data of a mall in a tourist area

Figure 9. Foot traffic data of a mall/transportation hub in a suburban area

Data ownership

We realized that a vast majority of the insecure MQTT brokers are owned and operated by software or device vendors, not the users or customers themselves.  This brings to the fore the challenge that modern enterprises have in tracking where their data is and making sure that such data is properly secured: Sensitive and operational data that can be generated from systems or devices of third-party vendors might be passed on using insecure means or new technologies with security mechanisms that are not yet fully understood or implemented.

Using the European Union’s General Data Protection Regulation (GDPR) as a guide, data controllers (customers) should ensure that data processors (third-party vendors) are compliant in protecting company and personal information.   This implies that data controllers (customers) should compel data processors (vendors), through assessment, audit, and contract; to guarantee the implementation of robust security measures and access controls for data protection.

When considering data processors, data controllers can include a data processor’s cybersecurity, secure development, penetration testing, red-teaming, and vulnerability management practices as part of their purchasing criteria. This is to determine whether these are aligned with their own practices and risk tolerance level.

However, from our experience, it seems data processors still have a lot to improve in their approach to cybersecurity. Not only are hundreds of MQTT brokers insecurely deployed, but it also seems that vendors and data processors are not responsive to vulnerability reports.  We have reached out to a couple of vendors over the course of this research; none of them have acknowledged or acted on our notifications about their insecure MQTT broker or the security weaknesses in their authentication or encryption, as in the case of the temperature monitoring device we looked at.

Recommendations

We recommend the following best practices for data controllers (customers) using these products, as well as for the data processors (vendors) who are designing, building, and programming these systems.

Customers who want to make sure their devices and systems are secure should:

• Review the protocol used by devices or software prior to or during the purchasing process
• Make sure that authentication is properly implemented
• Have their security teams check if security and encryption are properly implemented
• Evaluate the infrastructure, certificates, and setup used by their devices, software, or services to ensure that these do not leak any identifiable or confidential company information
• Evaluate a vendor’s cybersecurity practices in terms of secure development, penetration testing, red-teaming, and their product vulnerability management and response, to determine if it is aligned to your own cybersecurity standards and requirements

Developers or vendors should:

• Make sure that devices and software instances implement proper authentication and certificate checking
• Make sure that devices and software instances only have read and write permissions for the topics to which they require access. Always apply the least-privilege model in their design.
• Obscure domain naming for customers of your service (for example, do not use domains like, “cmqttbroker.com”). Vendors could violate a non-disclosure agreement (NDA) or other legal agreement by creating a subdomain using the name of their customer if the customer did not specifically agree to it.
• Limit the types of data being sent through MQTT. Data related to security procedures, personal identifiable information (PII) and company information should be sent through separate or more secure protocols.

Conclusion

MQTT is a very flexible protocol that’s able to handle deployments across many industries, but its security depends on the vendor implementing it.  An MitM attack is possible if certificate checking is not properly done, and anyone can subscribe to an MQTT broker if it does not check whether the connection request comes with valid credentials. 

In our exploration of MQTT security, we have identified two important trends that underscore the need for better security in the implementation and use of MQTT:

1. The software and devices using MQTT are increasingly becoming out of the customer’s control with the advent of the “as-a-service" business model
2. Operational and business-related data are increasingly generated and processed by third-party providers

This means a lot of the infrastructure, and technical and implementation details, are obscured from the customer or user, making it difficult to identify where the vendor is leaking data or “clues” about the customer. The data flow is likewise obscured, which makes it difficult for customers to determine what exactly is being shared and if access to their data is indeed limited to authorized accounts or devices.

On both points, it is the vendor who has the capability to remove any identifiable information about the customer and ensure that the data generated and processed is securely handled, transmitted, and stored. The customer should work with the vendor in understanding the software, device, or service they are using to identify the areas that might be leaking clues about the company, and make sure the security of these products or services, as well as the data handling, remains compliant with the company’s cybersecurity and data handling policy.

It is time that we take a deeper look at how third-party vendors implement security and how they handle their customer’s data. We should take into consideration whether the devices, software, and services we buy are secure enough to send information that might be abused for reconnaissance and industrial espionage, lead to product wastage or harm. In the case of MQTT, we have observed brokers accepting messages from unauthenticated and unauthorized users, so the problem is not limited to data exposure, but also data manipulation.  Not only does this affect data integrity, but data manipulation might also directly affect manufacturing, the industrial or business processes, and might even subject the company to unnecessary audit. This just shows the power of systems built on MQTT, and why we need to take its security seriously.