Vulnerable Designs and Implementations with MQTT and CoAP M2M Protocols

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]
  • Disrupt network via Denial of Service (DoS) attack
    • Reflective Denial of Service (DoS)
    • Regular expression DoS
    • Distributed Denial of Service (DDoS)
    • DNS Amplification attack
  • Command and Control Server Attack – eg. Botnets. Usually a group of malware infected computers that come under coordinated control. Used for a variety of attacks like DDoS, spam, poisoning of telemetry data or data and identity theft
  • Installing malware to gain command, steal data, or further infect network
  • Man-in-the-middle (MitM) and Spoofing attack
  • Social Engineering Attack (eg. Phishing for credentials or redirect to malware infected site)
• 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:

• MQTT
  • MQTT Payload Remaining Length (CVE-2018-17614)
  • MQTT Unicode Handling in Topic Strings (CVE-2017-7653)
    • Mosquitto MQTT broker by IBM if outdated may be vulnerable
    • Disallowed Characters
  • MQTT URI-Style Topic Validation (CVE-2018-11615)
    • Regular expression denial of service (ReDoS)
  • See other MQTT vulnerabilities in NIST database
• CoAP
  • CoAP Amplification
    • IP Address Spoofing on UDP
  • See other CoAP vulnerabilities in NIST database

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:

• National Vulnerability Database – NIST – Public database of known cyber-vulnerabilities. Search by protocol or keyword.
• NIST Cybersecurity Framework
• NIST Creating a Patch and Vulnerability Management Program
• MQTT Links
  • MQTT Community: https://mqtt.org/faq
  • Oasis MQTT Technical Committee – Specifying body for latest MQTT protocols
  • Report Bugs or Vulnerabilities: https://www.zerodayinitiative.com/
  • MQTT Specification
• CoAP Links
  • CoAP core specification RFC 7252
  • Links to other CoAP specifications
  • CoAP community
• Testing, Scanning and Monitoring Tools:
  • IoT-network search and scan
    • https://iotscanner.bullguard.com/search
    • https://www.shodan.io/
    • https://censys.io/
    • https://ivre.rocks/
    • https://www.thingful.net/
    • https://www.binaryedge.io/
    • https://subgraph.com/vega/
    • https://www.zoomeye.org/
    • https://www.incapsula.com/mirai-scanner/
    • https://www.metasploit.com/
  • Gibson Research Corps old school yet effective free port scanner tool. Scan your network for open ports en masse or individually. MQTT typically uses port 1883 or 8883.
  • TrendMicro’s own home network device scanner
  • Check your public DNS with https://www.dnsleaktest.com/
  • Monitor network traffic with the Wireshark downloadable tool
• Testing tutorials:
  • Test Home Network Security
  • How to secure your router
  • Rate your cybersecurity risk
  • Penetration Test with Wireshark

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

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]

 

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

CoAP

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.”
[2]

 

MQTT vs. CoAP

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]

References:

• http://www.steves-internet-guide.com/iot-messaging-protocols/
• https://www2.deloitte.com/content/dam/Deloitte/sg/Documents/risk/sea-risk-cyber-101-july2017.pdf
• https://dzone.com/articles/which-are-the-iot-messaging-protocols
• https://www.eclipse.org/community/eclipse_newsletter/2014/february/article2.php
• https://www.electronicdesign.com/iot/understanding-protocols-behind-internet-things
• http://docs.oasis-open.org/mqtt/disallowed-chars/v1.0/cn01/disallowed-Chars-v1.0-cn01.pdf
• https://diyprojects.io/8-online-mqtt-brokers-iot-connected-objects-cloud/#.XG12i-j7RPZ
• https://www.beyondsecurity.com/blog/security-testing-the-internet-of-things-iot
• https://www.networkworld.com/article/3112620/security/top-tools-for-preventing-data-leaks.html#slide1
• https://www.networkworld.com/article/2859568/internet-of-things/7-devices-that-make-your-data-vulnerable.html#slide1
• https://www.networkworld.com/article/3112671/security/review-top-tools-for-preventing-data-leaks.html
• https://blog.netwrix.com/2018/05/15/top-10-most-common-types-of-cyber-attacks/