Vulnerable Designs and Implementations with MQTT and CoAP M2M Protocols


Since their humble origins in industrial automation, machine to machine (M2M) protocols have served as the common tongue used by machines to communicate with each other over networks and the internet. This allows, for example, the conveyance of telemetry data from sensors and commands to actuators, and therefore plays a critical role in today’s IoT.

The importance of security with regard to data being transmitted over the internet is well documented, and has unfortunately been demonstrated time and time again with numerous high profile breaches and hacks. This same importance can be applied to data that is transmitted with M2M protocols, regardless of the infrastructure used to transmit the data. A December 2018 TrendMicro Research paper, “The Fragility of Industrial IoT’s Data BackBone: Security and Privacy Issues in MQTT and CoAP Protocols,” put the issue of M2M security vulnerabilities into clear focus. Due to its important yet lengthy content, we felt that in this article we’d sum up the paper’s key themes and suggestions.

Try Our ARM® Embedded IoT Dev Kit

Netburner ARM Cortex M7 embedded Development Kit for IoT product development and industrial automation.

Or, learn more about NetBurner IoT.

Message Queuing Telemetry Transport (MQTT) and Constrained Application Protocol (CoAP) are two of the leading M2M protocols. Both are very easy to use, adaptable and lightweight protocols suitable for effectively connecting a large array of devices over the internet. They are designed for constrained resource use cases (e.g. low power, high latency, limited bandwidth). IHS Markit, Inc. forecasts that the IoT market will grow from an installed base of 15.4 billion devices in 2015, to 30.7 billion devices in 2020, and 75.4 billion in 2025! [1] That doesn’t even include PCs or mobile phones. It is also expected that a large percentage of these IoT devices will use MQTT or CoAP.

Just like any platform or protocol growing in mass popularity, vulnerabilities are discovered, oftentimes by malevolent actors, and abused. It’s a rapidly evolving space which makes it  easy for even the most conscientious design teams and institutions to be outpaced in their understanding and management of M2M protocol patches, 3rd party library bugs, vulnerabilities and implementation flaws. Therefore, it should be no surprise that IoT devices using these popular M2M protocols are increasingly juicy attack surfaces for black-hat hackers and criminals today, and will be for years to come.

If you want to learn more on using MQTT, check out our prior article, “MQTT: The Go-To Protocol for Distributed IoT and Tutorial”. We’ll work on getting an article out on CoAP soon. Later in this article, we’ll go through a brief technical background for each of the protocols as well.

Risk Overview

There are entire infrastructures and sectors that are common targets of M2M related cyber-threats; potentially putting individuals, businesses, communities, cities and even nations at risk. Manufacturing, defense, aviation, marine, aerospace, healthcare, public administration, energy, building automation, transportation, and agriculture are a few of the sectors that have been vulnerable to some degree. [2]

According to TrendMicro Research, “MQTT and CoAP are found in a variety of IoT and IIoT products (and services), from control and analytics dashboards to the connectivity data plane, all the way down to the firmware running on the field sensors or protocol gateways.” They thereby present a very broad attack surface over the IoT architecture for M2M related vulnerabilities. To make matters worse, M2M 3rd Party library and protocol updates can make keeping up with changes a very challenging feat.

That sounds pretty scary, right? Well, this article isn’t trying to scare you away from using these great protocols, rather, we hope to encourage awareness and safer usage.

Attack Motives, Methods and Types

It’s important to understand the methods and types of attacks when working with these protocols to prevent and mitigate potential data leaks and hacks. Here are the general areas identified in by TrendMicro, which in some cases, work in tandem with or overlap one another.

  • Reconnaissance – Prospecting for personal, technology and business data is widespread, and M2M end-points can leak bits of valuable information. This information is used to prepare for active targeted attacks to the network, business or individuals. Reconnaissance can be passive (eg. sniffing publicly exposed networks) or active (eg. gain access via compromised credentials).
  • Espionage – Almost every major sector has some exposure to espionage: industrial, corporate, political, or international. The attack surface for espionage is growing as rapidly as the Internet of Things. The research from TrendMicro shows that “with simple keyword-based searches, an attacker can elicit business-relevant data that includes, for instance, the location and identifying information of assets and personnel, the technology used by a given company, and business-to-business relations, including the exchanged communication.” Anything from a connected 3D printer to an industrial manufacturing process can be spied on through this sort of M2M espionage. Attacks can be used to spy on competitors, steal data and information.
  • Targeted attacks – Utilizing information gained via reconnaissance orchestrated and targeted offensive attacks are often the next goal. Targeted attacks can be used for a variety of motives and can involve a number of more specific attack types or methods. TrendMicro was able to “show that the [M2M protocol]  technology has design, implementation, and deployment security issues that can facilitate the job of a motivated hacker looking to launch a targeted attack.” They also demonstrate “that current M2M technology can be abused to take control of endpoints or force them in a DoS state”. 2 In other words, an IoT network can be rendered useless. The attack can happen at the client or on the broker or server. Some common M2M IoT attacks include methods to cripple, steal from or further penetrate networks: [3]
  • Lateral movement – This refers to a spreading of a successfully executed targeted attack to additional assets in a network, and may be enabled through malware. [4] According to TrendMicro, “By abusing specific functionality, an attacker can use M2M technology to maintain persistent access to a target via software upgrades or to perform lateral movement, including against other targets.” Infiltration through the cloud and through the supply chain can occur. They also demonstrated “how an attacker can abuse a by-design protocol feature to implement amplification attacks… in… about 17 to 22 percent of the IPv4 autonomous systems on the internet”. [2]

Vulnerable M2M Applications

TrendMicro separates M2M applications into four broad groups to better depict how threats may unfold. All top level bullets are quoted from the paper: [2]

  • Telemetry and notifications refer to a passive use of M2M protocols to transmit data or messages. Here, security risks arise when such data is sensitive from a privacy perspective, or when it triggers automation rules.
    • Tainted data and commands can have far reaching effects on a variety of efforts including research, energy distribution and manufacturing. Anything from user information to a device make, model and location can be exposed. There are many negative outcomes that might come as a result of a bad actor gaining access to detailed IoT telemetry data. Leaked records can add up to massive data sets. Depending on the victim and perpetrator, some of these violations could be enormous and have severe consequences.
    • Examples include:
      • Leaking groupware messaging apps
      • Leaking Healthcare monitors and asset trackers
      • Leaking Smart Farming telemetry
  • Node configuration and management regards the active use of M2M protocols to set up, configure, and manage endpoints. Here, security risks arise because an attacker could take control of a machine during its configuration phase, for instance.
    • Manipulation of a device’s configuration can be especially problematic as they can be set up to run in ways which aren’t necessarily wrong or incorrect, but that leave gaping holes in the device’s security, making them more vulnerable to other types of attacks. These kinds of issues can also be especially difficult to detect.
    • Node configuration and management is an important element to modern IoT architectures. As IoT scales towards IIoT and smart city-type applications the ability to remotely maintain the IoT end-point or gateway (e.g. update firmware) becomes a matter of logistical sustainability.
  • Command queuing refers to an active use of M2M protocols to send direct commands to physical machines. Here, security and safety risks arise because an attacker could subvert such commands and affect the physical environment.
    • Actuators, indicators and relays can be switched by hackers. Combined with telemetry poisoning, a victim may be completely unaware until significant damage or loss becomes plainly evident.
  • Over-the-air upgrades, which are the most critical, refer to the active use of M2M protocols as a transport layer to ship software upgrades to endpoints. Here, the security risk comes from the fact that an attacker could intercept such upgrades to take complete and persistent control of an endpoint.
    • The potential impact of issues related to this category of applications will only grow as more and more IoT devices are deployed to the field, where these kinds of upgrades become necessary.

Summary of Recommendations

In a nutshell, TrendMicro Research  recommends the following at a high-level (top level bullets are quoted directly from the report):

  • Implement proper policies to remove unnecessary M2M services.
  • Run periodic checks using internet-wide scan services or tools to ensure that none of the sensitive company data is inadvertently leaked through public IoT services.
    • Design tests to ensure that less-secure development environments are not migrated to production.
    • Utilize IoT and network scanners as part of functional security testing. See the tools and resources list below.
    • Analyze and periodically audit your network traffic using a tool like Wireshark. Make sure you understand your data flow patterns and what normal data should look like. Learn to identify and inspect unencrypted communications, open ports, and headers that maybe give away too much information. Understand the data you are exposing to the public.
  • Implement a vulnerability management workflow or other means to secure the supply chain.
    • Understand your architecture, from large and enterprise-grade software down to the small, embedded devices, which may be neglected and running outdated firmware.
    • Understand which 3rd party IoT products, libraries and bespoke internal engineering are used and how those could lead to vulnerability.  
    • Be safe by incorporating practices on the control and migration of development environments to production.
    • Make a policy to use and test for end-to-end encryption (eg. SSL/TLS).
    • See the tools and resources list below.
  • Stay up to date with the standards in this space because this technology is evolving rapidly.

And as always, train colleagues, co-workers and employees on safe practices to avoid phishing or social engineered attack. Also, implement strong password policies, utilize end-to-end data encryption and multi-factor authentication whenever practicable, perform checks, tests and audits during development and for deployments. Know what unsecured data, if any, is broadcast over the internet and keep up to date! Finally, consider professional cybersecurity consulting services or pro tools to perform more in depth penetration testing. See the tools and resources list below.

More Detail on the Vulnerabilities

TrendMicro’s recent research and evidence that shows MQTT brokers handing out sensitive data to any curious soul or attacker. Experts have been able to identify threats associated with both the underlying protocols and developer implementation patterns. So it’s good to be aware of both angles. Here’s a list of some of these more detailed vulnerabilities:

Tools and Resources

We thought we’d add this section as an additional resource to begin your own testing. If you don’t have the capability to hire a professional here are some ways to get started with securing your M2M and IoT networks:

MQTT and CoAP Technology Summary

To better understand the risks, vulnerabilities, and threats, it pays to get a better understanding of the protocols and how they work. The details of which are deep and worth reading up on.


MQTT, Message Queuing Telemetry Transport, is a very simple and lightweight messaging protocol. It was developed for devices with constrained resources to communicate with optimal performance over less than optimal networks that might be suffering from  low-bandwidth, high-latency or that are just plain unreliable. [5] It sits on top of TCP and utilizes a publish/subscribe model with subscribing “clients” and data “brokers” playing middleman. [5] The model works like a newswire distribution service, where a “broker” like AP or Reuters allows reporters to “publish” reports to their wire service. Meanwhile, while listening newsrooms that have “subscribed” to that wire are able to receive news feeds through the broker.

According to the MQTT FAQ, the protocol’s “design principles are to minimize network bandwidth and device resource requirements, whilst also attempting to ensure reliability and some degree of assurance of delivery.” It also states that these principles make the protocol ideal for the latest generation of M2M systems, IoT, and “mobile applications where bandwidth and battery power are at a premium”. It is a fairly mature protocol that has been around since 1999, and is still evolving to better meet the needs for security, low power and latency. MQTT works via TCP/IP over port 1883 with IANA while TCP/IP port 8883 is registered for using MQTT over SSL. [6]

MQTT diagram


Notional diagram of the MQTT protocol’s publisher/subscriber/broker model.

Here’s a post and tutorial of ours on MQTT for IoT. Also check out and OASIS, the organization leading the charge on the latest protocol updates for MQTT.


Constrained Application Protocol (CoAP) is a younger and yet-to-be-officially-standardized “proto-protocol”, if you will. According to the official website, it is “designed for machine-to-machine (M2M) applications such as smart energy and building automation”. [7]  From Wikipedia, “CoAP is also being used via other mechanisms, such as SMS on mobile communication networks”. [8]

It is designed for power or network constrained devices over the internet or network, but utilizes User Datagram Protocol (UDP) rather than TCP. [9]  According to the Eclipse Foundation, “CoAP packets are much smaller than HTTP TCP flows. Bitfields and mappings from strings to integers are used extensively to save space. Packets are simple to generate and can be parsed in place without consuming extra RAM in constrained devices.” [5] There is no mechanism to support QoS to ensure packets were received.

CoAP follows a client/server model and is interoperable with HTTP and a RESTful API and software design paradigm.[5] Because it’s based on UDP, CoAP does not require the client to keep a connection open to a server, which is considered a benefit in many use cases.  

According to TrendMicro Research, “a client can send one CoAP packet to a server. Each request has a few options, with the most important one being the Uniform Resource Identifier (URI), which indicates the “path” to the requested resource — much like Uniform Resource Locators (URLs) for websites. Note that a node could be both server and client at the same time, implementing a point-to-point, full-duplex data layer.”

CoAP M2M diagram


Notional CoAP architecture utilizing both CoAP and HTTPS with a REST API. Note the flexible topologies. Here, the CoAP client nodes sit within the constrained environment. Orange arrows are CoAP connections and yellow are HTTPS (as an example).


TrendMicro provides an excellent comparison of the two protocols in their paper:

“CoAP is much more lightweight than MQTT, in terms of both operational requirements (i.e., no broker setup is needed) and memory and network overhead (i.e., UDP does not require keeping a connection open, and messages are much smaller in size). Thus, it meets the requirements of low-power IoT nodes: It minimizes the transmission cost and does not impose an always-on connection.

For its part, MQTT is thus preferred over CoAP for mission-critical M2M: It allows the enforcement of quality of service and ensures message delivery. On the other hand, CoAP is preferred over MQTT in gathering telemetry data transmitted from transient, low-power nodes like tiny field sensors. An extreme application use case for CoAP is satellite communication: The European Space Agency’s Advanced Research in Telecommunications Systems (ARTES) program has recently kick-started a research project on M2M communication in satellite networks (where latency can be very high), and CoAP is unsurprisingly listed among the chosen protocols.” [2]


Share this post

Subscribe to our Newsletter

Get monthly updates from our Learn Blog with the latest in IoT and Embedded technology news, trends, tutorial and best practices. Or just opt in for product change notifications.

Leave a Reply