Machine-to-Machine (M2M) Technology Design Issues and Implementation Vulnerabilities

Machine-to-Machine (M2M) Technology Design Issues and Implementation Vulnerabilities

In our latest research paper, titled “The Fragility of Industrial IoT’s Data Backbone: Security and Privacy Issues in MQTT and CoAP Protocols” and written with Rainer Vosseler and Davide Quarta, we discussed how MQTT and CoAP are affected by design issues and implementation vulnerabilities that can allow attackers to subvert devices enabled by these two machine-to-machine (M2M) protocols. During our research, we found hundreds of thousands of misconfigured hosts that exposed credentials, sensitive information, and industry-related process data.

In this blog post, we delve into the protocol security issues that may crop up from a technology perspective. The scarce awareness that we’ve observed around the current state of MQTT and CoAP can enable attackers in achieving their goals, ranging from reconnaissance and lateral movement to remote control and targeted attacks.

Technology behind M2M communication

Message Queuing Telemetry Transport (MQTT) is a mature standard and a publish-subscribe protocol that handles one-to-many communication mediated by brokers. We found security issues in the protocol itself and its software implementations. This presents a problem as MQTT is widely adopted commercially for automation and in industrial applications, which could prove crucial for mission-critical M2M.

Constrained Application Protocol (CoAP), on the other hand, follows a client-server model, allowing the creation of the equivalent of HTTP for constrained nodes. Despite being relatively new, CoAP is already implemented in many pieces of internet-of-things (IoT) and industrial-internet-of-things (IIoT) software today. Security issues that we highlight are primarily due to the “connectionless” nature of User Datagram Protocol (UDP), on which it is based. Although the risks are well highlighted in the CoAP Request for Comments (RFC), in this research we empirically measured the bandwidth amplification potential of CoAP services.

MQTT issue in handling topic strings

The MQTT standard has some corner cases that could subject implementations to vulnerabilities. One of the cases involves the Unicode handling in topic strings. The standard leaves it up to the developer to close the connection upon failing the validation of disallowed UTF-8 code points. So if it happens that a broker does not check for disallowed UTF-8 code points, a malicious client could take advantage of the discrepancy to disconnect other clients through invalidly encoded strings.

Of course, if the broker follows the standard, it wouldn’t be an issue. Interestingly, if both the broker and the client do not follow the standard, the issue is also avoided. But if the broker does not follow the standard and the client does, the client will disconnect upon receiving invalid content.

If the broker does not follow the standard, a malicious client could keep all the clients offline with a single “retain message” set to true and the quality of service (QoS) to 2. The clients will then disconnect upon receiving the invalid message and not acknowledge back to the broker. This, in turn, will have the broker assume that the clients never received the message and thus will keep flooding them with the same retained message over and over because of the “retain message” and “QoS = 2”.

Implementation vulnerabilities that attackers can take advantage of

As an example, we here discuss one of the vulnerabilities that we found in some of the MQTT implementations. We also explain the effect of an amplification attack we demonstrated on CoAP.

MQTT Payload Remaining Length (CVE-2018-17614)

The vulnerability is an unbounded write-in caused by a missing check on the “remaining length” field in a popular MQTT library. This allows an attacker to execute arbitrary code on vulnerable devices that implement an MQTT client. An attacker here must either control a rogue MQTT broker, or the broker must be missing proper checks for the remaining length field and just relay MQTT packets “as they are” from publishers to subscribers. The vulnerability can be triggered during the parsing routine for an MQTT PUBLISH packet, and precisely when reading the “remaining length” and “topic length” fields.

Moreover, the overwrite in the callback field can be triggered as many times as an attacker wishes, which could lead to a persistent denial-of-service (DoS) condition. If the broker is malicious (or if a client can force a broker to relay a malicious payload), all vulnerable nodes will be under a persistent DoS state, or will continue to execute arbitrary code “pushed” by the attacker.

There was a fix for this vulnerability. However, the developers could not agree on the best way to implement it. Once we notified the developers through a ZDI advisory, the fix was applied. As mentioned earlier, it is up to the developer whether to close the connection or to discard the packet and leave the connection open. We believe that this case is a good example of how corner cases in the specifications could lead to confusion.

CoAP: IP address spoofing on UDP and the risk of amplification (PoC)

A further look at the protocol specification reveals that CoAP supports “block-wise transfers,” which essentially means that a large response can be divided into smaller responses. Interestingly, “both sides have a say in the block size that actually will be used.” This means that an attacker can craft a request packet asking for the maximum block size, hence bringing the amplification factor up to 32x, which is substantial, considering that CoAP nodes are usually resource-constrained (e.g., running on battery).

A more detailed explanation on these issues and our other findings can be read in our research, “The Fragility of Industrial IoT’s Data Backbone: Security and Privacy Issues in MQTT and CoAP Protocols,” which includes an attack demonstration video. Our full paper also discusses the applications of M2M technology, impact in various sectors, and security considerations.

 

This article was written by  Federico Maggi. He is a Senior Threat Researcher with Trend Micro’s Forward-Looking Threat Research (FTR) team, an elite team of researchers fighting against cyber criminals and scouting the future of the Internet to predict the future evolutions of cybercrime.