- Nouvelles de sécurité
- Internet of Things
- MQTT and CoAP: Security and Privacy Issues in IoT and IIoT Communication Protocols
View The Fragility of Industrial IoT’s Data Backbone
Machine-to-machine (M2M) communication protocols, which enable machines to “talk” with one another so that commands are communicated and data is transmitted, are indispensable to applications and systems that make use of the internet of things (IoT) and the industrial internet of things (IIoT).
Message Queuing Telemetry Transport (MQTT) is a communication protocol widely used in both IoT and IIoT deployments. MQTT is a publish-subscribe protocol that facilitates one-to-many communication mediated by brokers. Clients can publish messages to a broker and/or subscribe to a broker to receive certain messages. Messages are organized by topics, which essentially are “labels” that act as a system for dispatching messages to subscribers.
Constrained Application Protocol (CoAP), on the other hand, is a client-server protocol that, unlike MQTT, is not yet standardized. With CoAP, a client node can command another node by sending a CoAP packet. The CoAP server will interpret it, extract the payload, and decide what to do depending on its logic. The server does not necessarily have to acknowledge the request.
A high-level view of the interaction models of MQTT (left) and CoAP (right)
MQTT is preferred over CoAP for mission-critical communications because it can enforce quality of service and ensure message delivery. CoAP, for its part, is preferred for gathering telemetry data transmitted from transient, low-power nodes like tiny field sensors. Despite fulfilling different needs, both protocols are fundamental in IoT and IIoT deployments, where fast and flexible data exchange is a basic operational requirement.
An internet-wide scan on exposed MQTT endpoints conducted by IOActive’s Lucas Lundgren between 2016 and 2017 presented a clear deployment problem among tens of thousands of unsecure MQTT hosts. A smart-home-centric MQTT research was also released by Avast this year, highlighting the lack of secure configurations and the likelihood of misconfigurations in home devices that use MQTT. We decided to look into the same problem — and include CoAP in the picture — and to see if there has been more awareness surrounding it.
What we found was striking: Hundreds of thousands of MQTT and CoAP hosts combined are reachable via public-facing IP addresses. Overall, this provides attackers with millions of exposed records. Finding exposed endpoints in virtually every country is feasible due to the inherent openness of the protocols and publicly searchable deployments.
Geographical distribution of MQTT brokers (top) and CoAP servers (bottom)
Note: We recorded 17,226 MQTT brokers in the Asia-Pacific (AP) region. However, limitations in Shodan’s geolocation metadata inhibited us from determining more precise country or territory locations for the counts.
We also outlined design issues and implementation vulnerabilities, which can contribute to the number of unsecure deployments that we found. A design issue that we discovered (designated as CVE-2017-7653 for Mosquitto, the most popular broker), for instance, can allow a malicious client to supply invalid data. By using the message-retain option and modifying the quality of service (QoS), an attacker can lead clients to be flooded with the same (retained) message over and over.
Unsecure endpoints, moreover, can expose records and leak information, some of which we found to be related to critical sectors, for any casual attacker to see. Vulnerable endpoints can also run the risk of denial-of-service (DoS) attacks or even be taken advantage of to gain full control.
Here we discuss how unsecure deployments and the lack of well-defined security in M2M technology can be abused to turn into unforeseen problems in critical and large-scale environments like smart factories and cities.
M2M technology forms the core of IIoT systems for maintaining smart factories and building smart cities. As more of these connected environments crop up, the more it becomes difficult to manage and protect large volumes of data exchanged by the IoT-enabled devices.
While looking for leaked data related to smart cities, we noticed a group of records that contained email addresses and location names of certain businesses. When we dug a bit more, we found that these records were all taxi or car-sharing rides booked by employees traveling to and from their offices. The records furthermore contained precise timing information that could allow an attacker to learn who was going where.
Taxi or car-sharing data containing business names and business email addresses
We also found instances of data exposure related to the manufacturing sector. Records were leaked by a programmable logic controller (PLC), which was sending out telemetry data via an open MQTT broker. Exposed records could indicate names assigned to particular control systems, details of the manufacturing processes, and even urgent maintenance requests like the one below.
Urgent alert or maintenance request for a company specializing in the manufacturing of the automotive body assembly system and body parts
Such information can be used for target reconnaissance so that connected machines or employees of potentially high-profile companies can be tracked. These are just two examples of how exposed data in smart cities, factories, and even certain sectors could allow an attacker to prepare for an attack with the help of leaked sensitive data.
The number of connected devices and machines has nowhere to go but up, and more and more critical services are relying on communication protocols to provide immediate and essential response. This gives further responsibility to manufacturers and service providers to ensure both the reliability and the security of protocols and applications.
Considering the emergence of these protocols, it’s reasonable to expect that attackers will catch up and abuse M2M technology for their malicious activities. We even expect poisoning of telemetry data to be a feasible and indirect attack method in the future.
Certain considerations like not having security built in and protocols having concepts such as wild-card topics and linked resources can be turned against users by exposing their resources and collecting data about them. Moreover, MQTT and CoAP do not check the data or payload that they transport, which means that the information can be really anything, posing data validation issues on the connected systems.
Organizations and manufacturers should then pay adequate attention to IoT and IIoT security. Organizations’ security teams should ensure that proper security mechanisms are in place when using protocols. Solutions do exist to secure M2M communications — they are just not employed by all.
It is very important for organizations to conduct risk assessments. Our research aims to raise awareness on potential risks in IoT and IIoT devices that use MQTT or CoAP, help organizations to identify weak points in their deployments, and follow the best practices we outlined in the paper. For in-depth analyses and insights, read our research, “The Fragility of Industrial IoT’s Data Backbone: Security and Privacy Issues in MQTT and CoAP Protocols.” In our research, we discuss how attackers can subvert MQTT- and CoAP-enabled implementations and even take advantage of exposed data that includes personal and company-sensitive information for attacks.
Like it? Add this infographic to your site:
1. Click on the box below. 2. Press Ctrl+A to select all. 3. Press Ctrl+C to copy. 4. Paste the code into your page (Ctrl+V).
Image will appear the same size as you see above.