Mitigate IoT Attacks with Key MQTT Security Principles

In September 2016, the infamous Mirai malware shook the IoT world with a whip-smart DDoS attack model that infected over 600,000 IoT devices. Such attacks on network-attached devices and IoT devices continue to increase exponentially. With the IDC predicting that there will be 41.6 billion connected IoT devices, generating 79.4 zettabytes (ZB) of data by 2025, we can only imagine the number of malware attacks we will need to endure. That said, we can mitigate such IoT attacks by adhering to key security principles – using secure technologies such as the MQTT protocol.

IoT Security Vulnerabilities: A Problem of Technology and Oversight

As a frequent presenter at IoT conferences, I have the opportunity to interact with numerous stakeholders in the IoT ecosystem. During these interactions, discussions about IoT security are always a hot topic. These conversations confirm that the key factors behind IoT security vulnerabilities typically boil down to choosing the wrong technology or even simple oversight.

A 2018 IoT Security Foundation survey concluded that less than 10% of consumer IoT companies follow vulnerability disclosure guidelines. For a long time, companies in the IoT space have focussed on reducing the time-to-market and overlooked implementing basic security principles. When users take advantage of all security features the protocol offers, the use of MQTT as the communication protocol is a secure technology. The key is to avoid falling prey to any of the commonplace oversights of security principles that we see all too often.

In the same way that public cloud users share the responsibility to secure the infrastructure from their end by adhering to specific security principles, MQTT users must adhere to key principles for securing their MQTT devices and communications.

Misconfigured and poorly configured MQTT clients are a primary cause of security and privacy issues in the IoT space. Without proper configuration and setup, the MQTT protocol allows anybody to subscribe to any topic. Theoretically, every MQTT client can subscribe to any MQTT server that is available on the Internet. It is us – the users – who share the responsibility to secure the communication channel with appropriate measures and comply with key security principles.

The Key Principles of MQTT Security to Reinforce IoT Security Posture

At HiveMQ, we take security very seriously. A few years ago, we released a series of blogs around MQTT Security Essentials. To date, we recommend every customer to implement these best practices, irrespective of how small their deployment is.

Today, I would like to emphasize the following security principles that reinforce the security posture of MQTT and provide a multi-layered defense mechanism:

1. Encryption:

A recent Palo Alto Networks’ data sheet titled IoT Security says, “98% of all IoT device traffic is unencrypted, exposing personal and confidential data on the network. Together with 57% of IoT devices also being vulnerable to medium- or high-severity attacks, this makes IoT a low-hanging fruit for attackers.”

MQTT relies on the TCP transport protocol. TCP connections do not use encrypted communication by default. To encrypt the whole MQTT communication channel, MQTT brokers must use TLS or SSL certificates. One solution is to use certificates that are signed by trusted Certificate Authorities (CAs), such as TrustWave. This is a good solution for a server-only TLS approach like we are using with our SaaS HiveMQ Cloud. Another viable approach for an IoT use case with many, sometimes restricted devices, is the use of self-signed certificates. Enterprise-grade MQTT brokers like HiveMQ fully support the use of self-signed certificates for mutual TLS. Whether you are using a trusted CA or a self-signed certificate with shared trust stores, it is important to prevent man-in-the-middle attacks by using proper hostnames in production.

A simple search on Shodan.io with a query for “port: 1883” might show hundreds of ports on unsecured TCP connections, while a query for “port: 8883” might only return a double-digit number. This is a testimony to just how careless the majority of users still are when configuring their MQTT deployments. And, if your MQTT broker is public-facing, properly managed certificates are a must.

If you want to understand the nitty-gritty of using TLS / SSL to secure your MQTT solution, here’s a detailed blog post.

2. Application-Layer Authentication:

A poorly configured MQTT server that is publicly available on the Internet without any authentication is a disaster waiting to happen. At the transport layer level, you can use a valid client certificate, for example, X.509 certificate, for a client to broker authentication. However, using X.509 certificates does not provide enough security. There is a possibility that a hacker might extract these certificates from the firmware and use the certificate to log in to your MQTT broker.

That’s why I recommend using the username & password offered by the protocol at the application level to secure the MQTT clients. Even better, use a centralized authentication mechanism, such as OAuth 2.0 (JWT), which allows a client to access a resource that is owned by a resource owner without giving unencrypted credentials to the client.

HiveMQ’s Enterprise Security Extension supports centralized authentication and makes it possible to integrate existing enterprise security systems into device authentication and authorization workflow. A multilayered defense system is the best possible way to mitigate risks. This leads us to our next layer of security, which is Authorization.

3. Authorization:

Once an MQTT client successfully authenticates at an MQTT broker it can publish messages or subscribe to topics at will, granting it access to all resources on the broker. To address this, it is best practice to set up MQTT brokers with the right authorization policies for clients and limit their ability to subscribe and publish MQTT messages.

This third layer of protection ensures that an MQTT broker does not connect to a device if a client publishes a topic without proper permission. HiveMQ with its extension SDK facilitates fine-grained & dynamic permissions to ensure you have all the possibilities to secure your MQTT deployment, while being able to integrate virtually any external system like OAuth 2.0 (JWT), Lightweight Directory Access Protocol (LDAP), or any type of database (SQL or no-SQL)

Wrap-Up:

While focusing on securing MQTT deployments, it is also important to focus on securing the central IT infrastructure hosting the MQTT broker. With the exponential rise in the number of smart devices and IoT devices connecting to the cloud and the rise in the use of the cloud to host MQTT brokers, it is needless to say that the instances running on the cloud should be secure too. In an ever-maturing IoT industry, we are gladly seeing less emphasis on simply going to market early with a growing consciousness of following necessary security standards. We have not found a silver bullet to mitigate cyberattacks on connected devices yet, however, by adhering to key security principles we can safeguard the MQTT deployments layer-by-layer and in turn mitigate IoT attacks.

About Florian Raschbichler

Florian serves as the head of the HiveMQ support team with years of first-hand experience overcoming challenges in achieving reliable, scalable, and secure IoT messaging for enterprise customers.

About Florian Raschbichler

Florian serves as the head of the HiveMQ support team with years of first hand experience overcoming challenges in achieving reliable, scalable, and secure IoT messaging for enterprise customers.

Contact Florian