Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT

Researcher Finds MQTT Hole in IoT Defenses

A commonly used protocol provides a gaping backdoor when misconfigured.

It started with a simple wish: Martin Horn, security researcher at Avast, wanted a smart home. As he began his research into systems, he found that many devices included set-up instructions with no security provisions. And then, it got worse.

Horn realized that many of the hubs gathering IoT devices into a unified system run Message Queuing Telemetry Transport (MQTT) protocol, an ISO standard for device-to-device communications. And quite a lot of the devices acting as MQTT servers have no security at all. It's not that they use a default user name and password, Horn says, it's that they don't have user names or passwords - period.

"It's not a flaw in IoT devices themselves, it's just a lack of security," Horn says. "In this case, it's wide open, with no password at all." It's important to note, he explains in an Avast blog post, that the MQTT protocol itself is secure, if implemented and configured correctly. The lack of security is the fault of the implementation, not the underlying protocol.

And the faulty implementations are widespread. Horn says that a relatively simple Shodan search found more than 49,000 MQTT servers visible on the Internet because MQTT has been improperly configured. Of those, more than 32,000 have no password protection at all.

Once compromised, the MQTT servers are primarily a threat to their owners. "This is more about leaking the data, not about becoming part of a botnet," Horn says. "I can imagine the possibility, if you could update firmware over MQTT, of recruitment [into a botnet], but it's mainly about leaking the data or losing control of the home system."

And the problem is that the MQTT server, by dint of its central position in the IoT network, becomes a central point of security failure that can open the entire network to to compromise even if the individual endpoints are configured securely. Connecting to the unprotected MQTT server and using it to control other devices or reading data from the connected devices becomes almost trivial, according to Horn's blog post.

Protecting these vulnerable devices is simple in concept: Add a username and password. In some cases that's a trivial step in a configuration process. In other cases, it's impossible, because the device manufacturer didn't make allowances for the addition.

Horn says in his post:  "…we have called for better device-level security for IoT and for manufacturers to develop their products in such a way that encourages and makes it simple for all consumers to properly set up their devices and all the pieces related and connected to it, in order to ensure users’ entire smart ecosystem is secure."

Related Content:

 

Learn from the industry's most knowledgeable CISOs and IT security experts in a setting that is conducive to interaction and conversation. Early bird rate ends August 31. Click for more info

Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
A96.uk
50%
50%
A96.uk,
User Rank: Apprentice
8/22/2018 | 12:57:36 PM
Re: MQTT is IT not IoT
Yes it is IT security that fails here with MQTT implimentation.

 

It comes under configuration management.

Security needs to be abstracted away from business requirements.

Its a given in IoT.

 

Example used here already people 2016

 

https://www.wolfssl.com/wolfmqtt-v0-3-and-mqtt-secure-firmware-update-example/

https://www.wolfssl.com/docs/atmel/

 

My own IoT design's are designed to show the IT world how to do SECURITY.

In hardware. Like U2F from FIDO/FIDO2 for humans.

 

508a/608a or SAML11 for your edge nodes.

SAML11 for youre secure IoT hub talking MQTT over HTTPS.

 

It does not matter if your IP security fails.

The data is protected by hardware security.

Your heart beat system will tell you of DOS on your IP part.

 

ONLY PUBLIC KEYS are in the wild in secure IoT systems.
Kunchen
50%
50%
Kunchen,
User Rank: Apprentice
8/22/2018 | 12:37:55 PM
Re: MQTT is IT not IoT
Doesn't that go back to security policies? Disabling/securing services/ports? 
A96.uk
50%
50%
A96.uk,
User Rank: Apprentice
8/22/2018 | 3:06:24 AM
MQTT is IT not IoT
The Internet of things (IoT) is the network of physical devices, sensors, actuators, and secure network connectivity which enable these objects to collect and exchange data

People need to know who to blame for poor design & security with IT systems.

 

IoT is a subset of IT, linked in a Venne diagram by the overlap, this is the place for the secure hub.

IoT securely designed does not rely on MQTT security.

IT security configuration has always been an issue.

If you cannot configure MQTT don't even think about adding on a IoT sub system.

 

Regards

 

https://a96.uk/
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11844
PUBLISHED: 2020-05-29
There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
CVE-2020-6937
PUBLISHED: 2020-05-29
A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
CVE-2020-7648
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
CVE-2020-7650
PUBLISHED: 2020-05-29
All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
CVE-2020-7654
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.