MQTT (Message Queuing Telemetry Transport), a machine to machine messaging protocol, has gained popularity for IoT (Internet of Things) implementation due to its lean publish/subscribe architecture — which means it’s fast and cheapskates on data.
With today’s need for connectivity, any device, from washing machines to medical equipment, come readily connected to the internet. As these machines require simplistic lean resource protocol, and many times real-time fast communication, MQTT offers a perfect solution.
One aspect of this technology that has not been addressed for far too long is security. As we’ve seen in the past, lack of security measurements in IoT products led 10s of thousands of them being taken over by malicious actors in order to use them in their Botnet armies. These armies are then being used in DDOS (Distributed Denial of Service) attacks — a type of malicious activity that is mostly intended to disrupt the day to day activities of businesses and government offices. It does so by overwhelming their websites with requests until they are forcibly shut down.
There are ways that device manufactures can make sure that products they release are secure. Lack of knowledge, trying to keep the product’s cost low by minimizing resources, or just complete disregard of their role in keeping their products secure are some of the reasons there are probably 100s of thousands of unsecured IoT devices readily available for any perpetrator to take control over.
Even though the most basic implementation of MQTT does not require the use of any security measurements there are several ways to make sure it is secure.
There are two main players in MQTT architecture — Client and Broker.
The client is the IoT device that resides at your home or business and the cloud service that is used to monitor and control it. For example, the Nest Thermostat that sends its status to your phone or can be controlled remotely from your phone wherever you are. The broker is the server that conveys all that information between the IoT devices out there and their cloud service.
· Visible Credentials — The Username and Password are visible since they are sent in clear text
· Ease of Access — Many IoT devices are consumer products that can be easily bought on the internet, after which any hacker can get access to it locally and extract the password or authentication credentials
· Wildcards — The communication between an IoT device and cloud service, which are both clients, is done by creating a Topic on the broker server. Once this Topic is created they both listen/publish messages from/to this Topic in order to communicate between them. The Broker has an option to enable wildcards, which means any client can listen to any topic. That gives malicious actors the option to listen to any Topic and look for unsecured IoT devices.
· Encryption — A user name and password should always be used but since they are sent in clear text it is also recommended to encrypt the messages over TLS protocol using X.509 public key certificate.
· Protecting the product itself — The manufacturers should make sure that the credentials and X.509 certificates are not accessible locally and if they are they should be unique for each device.
· Disable Wildcard — Providers of Broker cloud services should make sure to disable the wildcard option in order to protect their clients from eavesdropping.
These are just 3 simple ways that could quickly increase the IoT product security. They do require investment and resources from the manufacturers, which is probably one of the reasons why many fell short in providing the required security to their customers.
As technology improves, adding these kind of solutions would become easier and leaner, requiring less resources from the manufacturers to implement and manage. As for now, we still have plenty of unprotected devices out there which depend on AI driven security products to detect when they are under attack or used for one.
https://dzone.com/articles/have-we-forgotten-the-ancient-lessons by Wilfred Nilsen