Insecure Internet of Things (IoT) devices (quelle surprise?) have leaked over 210 million data points in the last 16 weeks alone, according to new research from Trend Micro.
The opportunity for industrial espionage, denial-of-service and targeted attacks is nigh endless as a result, the company’s researchers warned, with confidential emails among the data leaked.
In a 65-page report the company referred readers to AWS’s IoT setup as an example of best practice that would prevent such leakage.
What’s the Issue?
The Japanese security company found that two of the leading machine-to-machine (M2M) protocols – Message Queuing Telemetry Transport (MQTT) and Constrained Application Protocol (CoAP) – have severe design issues and insecure deployment.
Hundreds of millions of messages have been leaked by exposed brokers and servers as result. Attackers are able to locate these online with simple keyword searches.
Trend Micro’s scanned the internet for exposed MQTT brokers and they were able to collect over 209 million MQTT messages from 78,549 brokers.
Image Source: Trend Micro
Insecure Internet of Things: Leaky Protocols
One example of a leaky MQTT protocol was Bizbox Alpha mobile, an Android groupware application developed by Douzone.
Trend Micro noted [pdf] in a 63-age report that: “One of the brokers used by the app was misconfigured for a while, and leaked 55,475 messages in over four months, of which about 18,000 were email messages.”
In the messages the team at Trend Micro found private information relating to business operations such as business contacts and information exchanged between them.
Implementation and Design Issues
The team also discovered several implementation and design issues with regards to MQTT protocols. They found that Mosquitto, the most popular broker, was allowing a compromised client to send invalid data.
Vulnerability CVE-2017-7653 let a client disconnect from the broker by sending an invalid UTF-8 topic string, this would then cause a denial of service attack.
Constrained Application protocols were also found to be leaking information. CoAP exchanges data by initiating a client node to send a request to a sever node.
At any time, 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,” Trend Micro state.
Scanning for exposed CoAP hosts the researchers discovered over 19 million responses from nearly half a million servers. However, they did not discover any design vulnerabilities within the CoAP protocol.
Greg Young, VP, Cybersecurity, Trend Micro said in a release: “These protocols weren’t designed with security in mind, but are found in an increasingly wide range of mission critical environments and use cases.”
“This represents a major cybersecurity risk. Hackers with even modest resources could exploit these design flaws and vulnerabilities to conduct reconnaissance, lateral movement, covert data theft and denial-of-service attacks.”
So, What’s Best Practice?
As a concrete example of best practices, Trend Micro refers readers to AWS IoT.
“In AWS IoT, it is impossible for a user (even a non-expert user) to connect an IoT device in an unsecure way, or to create an unsecure instance of AWS IoT’s backend. The service is essentially a managed MQTT broker that:
- Enforces TLS encryption. There’s no other way to connect to the broker than over TLS.
- Enforces mutual TLS-based authentication with per-device certificates. Each new “thing” (node) must have a new certificate, which will be used to authenticate the thing onto the server, and a certificate that will allow the thing to authenticate the AWS IoT server. If a node is lost or compromised, the administration dashboard allows the revocation of its certificate.
- Disables QoS = 2 and retained messages. This effectively reduces the risk and power of DoS… if a malicious publisher sends a message with QoS = 2 (i.e., the message
must be confirmed and requires two transfers each side) and “retain option” enabled, this will cause the delivery to be repeated indefinitely, until the subscribers ACK (acknowledge) the message, including all future subscribers. If, because of a failure, a message is not acknowledged, the broker will keep resending it.
- Is usable. All of the above is “wrapped” in a usable web wizard that guides the user from zero to testing with in-line documentation.
“We believe that this deployment should be used by other service providers, and as a reference for system integrators” it includes.