Nowadays security is one of the main IT concerns. Typical security issues include data loss, security breaches, and malicious attacks. These issues are relevant within the new mainstream IT industry – the Internet of things (IoT). IoT devices produce large amounts of data that is uploaded, processed and quite possibly stored. Most of this data can be very sensitive, therefore lack of proper security measures is one of the biggest barriers to an IoT future.
Introduction to IoT
IoT can be defined as a system of interrelated computing devices that are intended for industrial and consumer use and include connected wearable technology, connected health, vehicles, home automation, appliances with remote monitoring capabilities and many other smart device types. Today an IoT device can be anything from a motion sensor to a smartwatch, provided that it is connected to the Internet.
The inter-device communications methods and protocols may vary. Two basic patterns for communication design are request-response and publish-subscribe. These patterns are the foundation of all IoT device communications.
Request-response pattern is a basic communication pattern where the requester (nominal client) sends a request message to a predefined responding system (nominal server) which then processes the request and replies back. Two types of this pattern exist – synchronous and asynchronous. Asynchronous pattern allows different time frames for original request and the generated response, whereas synchronous pattern limits both to the same timeframe. However, both types provide limited scalability and pose technological and operational challenge for midsize and large IoT systems.
The publish-subscribe (pub/sub) pattern provides an efficient and scalable data distribution method for IoT systems. The publisher sends data only once to a publish-subscribe server that is also called a broker. The broker retransmits the data further to subscribers allowing for a significant network traffic reduction. By decoupling the sending (publisher) and receiving (subscriber) parties, and considering both parties as clients, this pattern provides greater scalability and is very suitable for use in large-scale distributed systems. Figure 1 shows pub/sub communication flows.
Figure 1. Pub/sub communication flows
Message Queuing Telemetry Transport (MQTT) Protocol
More than a dozen communication standards and protocols exist in the IoT world, but most large-scale systems, based on Pub/Sub pattern, utilize MQTT protocol.
MQTT is a lightweight protocol that supports persistent TCP connections and provides bidirectional communication between IoT devices. MQTT-capable devices communicate by publishing data to so-called topics. Client MQTT devices subscribe to a certain topic, and whenever new data is published to that topic, it is pushed to all existing subscribers. MQTT gained significant popularity mostly due to low energy consumption and CPU usage.
A reasonable level of security is essential for any transport protocol including MQTT. However, implementing robust security can quickly become resource-demanding, while most IoT devices have limited computing power and memory capacity. An additional load caused by extensive security measures can have a negative impact on the IoT system as a whole. Therefore, MQTT configuration should always strike a balance between security and service level expected from the given IoT system. Security issues are related neither to MQTT protocol itself, nor to the most common server software implementation. The problems are always caused by weak and overly simplistic configurations.
In 2016, Mirai malware turned hundreds of thousands of smart devices, primarily IP cameras and routers, into a large botnet by abusing their default access credentials. Massive DDoS attacks were then successfully commenced against various targets. In 2019, Orvibo smart homes leaked two billion records about their users including usernames, emails, passwords, family names, precise locations of IoT devices, and account reset codes. This security breach was caused by insecure backend configuration and the fact that all data was hashed with the weak MD5 algorithm.
The IoT environment growth rate makes serious attacks a question of time. According to a report, published by Kaspersky Lab’s, the number of attacks against smart home devices throughout the first half of 2019 increased seven times (105 million attacks detected) against the same period in 2018. Most attacks were aimed to build botnets. Many of the affected devices used MQTT protocol for communications.
To gain a better understanding of the possible issues and ways to negate the threats while implementing MQTT in a given system, an analysis follows, reviewing various MQTT connection stages and relevant security mechanisms for each stage.
Username/Password authentication method
The MQTT protocol uses username and password fields in the CONNECT message sent to the broker in order to authenticate. The username uses UTF-8 encoding while the password is transferred as binary data. MQTT has no built-in credential encryption function and requires some type of external transport encryption. It should also be noted that the MQTT standard permits authentication using username only. The broker can respond with different return codes:
- 0: Connection accepted;
- 4: Connection Refused, bad username or password;
- 5: Connection Refused, not authorized.
X.509 client certificate authentication method
Using X.509 client certificates is both advanced and secure mechanism for MQTT authentication. All clients use TLS encryption that requires the public/private key pair to exist on each server. Authentication is performed based on client public/private keys used in the TLS handshake.
The client sends its own certificate during TLS handshake after completing server certificate validation. The server has the option to abort the handshake whenever the client certificate cannot be verified. Thus, authentication happens at the transport level before any MQTT CONNECT messages are sent, the client is authenticated before establishing secure connection to the server.
While having multiple advantages from a security point of view, deploying X.509 client certificates authentication can become a challenge as it requires the IoT system to include a reliable and secure certificate provisioning and revocation mechanism.
Topic permissions on the broker
In MQTT protocol, authorization defines which topics are available for the authenticated client to subscribe and whether this client is permitted to publish to these topics. Permissions implemented on the broker side include:
- Allowed topic - defined topics only or all topics/wildcard subscription
- Allowed operation - publish, subscribe or both
- Allowed QoS level - 0, 1, 2, all
After authorization policies deployment is complete, the broker needs to notify its clients about established permissions. If a client attempts to publish to a topic without permission the broker can either disconnect the publisher or acknowledge publication without actually sending the message to other subscribers. All client subscriptions to various topics are also confirmed by the broker. If a subscriber is not permitted to access a certain topic, the broker notifies this client that subscription was denied. In general publishing and subscription management is based on client IDs and ID prefixes, i.e. “client1/temperature”.
OAuth 2.0 Authorization framework
Despite the fact that OAuth 2.0 was designed specifically for the HTTP protocol, certain OAuth “Client Credential Flow” based implementations are compatible with MQTT. The mechanism requires clients to present their credentials to the authorization server, which processes authentication and returns an access token to the client. The client presents the received access token to the MQTT broker that validates this token by checking with the authorization server and grants specific publishing or subscription permission to the client upon successful validation, see Figure 2.
Figure 2. OAuth Client Credential Flow
By default, TCP connections and traffic are unencrypted and no specific security approach is forced by the MQTT itself. Default communications use port 1883. However. usage of TLS instead of plain TCP to encrypt data and validate its integrity using port 8883 that is exclusively reserved for this (secure-MQTT). A TLS connection is established between the broker and the client. For asymmetric encryption to work the server needs a public/private key pair. During TLS handshake, all clients need to validate presented server certificate that contains the server public key before establishing secure connections. Figure 3 shows TLS encryption usage between the publisher and the MQTT server. In this example, all messages sent from the server to the subscribers are plain text, however, depending on a particular MQTT implementation some link encryption can be used to further improve overall security.
Figure 3. MQTT over TLS
The usage of TLS based on public key certificates can become a significant challenge for some implementations, particularly systems that use resource-constrained end devices. The reason is increased CPU usage required for TLS operation and traffic overhead. A worthy option for such performance-constrained environments is TLS-PSK that uses pre-shared symmetric keys.
Payload encryption and data integrity assurance
Payload encryption is another security option, alternative to TLS. Unlike TLS which encrypts the link between each client and the broker, payload encryption can also provide end-to-end encryption. Essentially, payload encryption takes place on the application level so it is an application-specific feature. The encryption process only involves application data while packet metadata stays unencrypted. All MQTT payloads are binary so the encrypted message is a raw byte array. As a rule, payload encryption is used for MQTT PUBLISH packets only, see Figure 4.
Figure 4. Payload encryption
Data integrity verification mechanisms can be used in conjunction with payload encryption. Integrity can be verified for data sent from a publisher to the broker or subscriber by adding a stamp to the payload either using checksum, message authentication code (MAC), or digital signatures. While checksum and MAC options can only guarantee that the message has not been modified, digital signatures also ensure sender authenticity
Confidentiality, Integrity and Availability impact
Several aspects of data confidentiality are relevant to the MQTT protocol. Systems that feature no authentication methods and allow wildcard subscription are prone to the attacker viewing all published messages, without even residing on the network. Furthermore, as default MQTT configuration does not include encryption, all traffic is vulnerable to man-in-the-middle attacks. Any sensitive data in the MQTT packet can be exposed. Finally, if username/password based authentication is used, the MQTT CONNECT packet will include the credentials, used to connect to the broker, in plain text.
If there is no transport level encryption and data integrity verification implemented, an attacker can modify intercepted MQTT packets at will. In case of payload encryption, an attacker can modify unencrypted packet metadata, such as topic name, client ID or QoS level, during the man-in-the-middle attack and send incorrect data to the broker.
In worst-case scenarios (misconfigured authorization), an attacker will be able to gain full control over IoT devices by publishing different commands to an MQTT topic, i.e. “open the garage door”. Also, an attacker can carry out a Denial of Service (DoS) attack, where a malicious publisher device sends an excessive amount of DoS packets to a subscriber device (or uses large packets for DoS attack). Finally, an IoT device can become a part of a botnet and participate in DDoS attacks later.
From theory to practice
As of today, Shodan search for “MQTT” yields approximately 84,000 results. These are MQTT servers exposed to the Internet. The question is: how many of them have at least some basic security mechanisms in place? A python script was written to send MQTT CONNECT packet to a thousand random MQTT servers, picked from Shodan, 53% of the servers responded with code 0 which means they did not require any authentication. It is hard to overestimate the opportunities it gives to hackers.
For demonstration purposes, we established a connection to an unprotected MQTT broker and subscribed to all available topics. Immediately, we had a lot of incoming messages from the broker. The type of devices we gained access to can be deduced from the packet shown in Figure 5.
Figure 5. Receiving messages as a fake subscriber
In another case, a configuration file containing some interesting information, such as passkey and geolocation data, was received. Part of this configuration file is displayed in Figure 6.
Figure 6. Discovering confidential data in messages
Having access to confidential data is a serious issue. But in some cases, careful control message analysis can allow the attacker to create and publish his own message to gain control over the compromised IoT devices.
Even when authentication and authorization are configured and implemented correctly and transport level encryption is in place, an IoT system can still run other misconfigured services. Figure 7 shows an unprotected web dashboard allowing control over multiple smart home appliances (such as heaters and motion sensors).
Figure 7. Unprotected smart home web dashboard
Apart from HTTP, common attack vectors include poorly configured FTP and SMB services that often reside with MQTT server.
Essentially, not every company involved with IoT system design and development possesses sufficient knowledge and experience in information security. USSC has a significant background in IT security and provides penetration testing and vulnerability assessment services to ensure that IoT solutions such as smart home automation developed by USSC are secure by design. However, any developer can significantly increase an IoT-systems security by following these basic recommendations to configure a secure MQTT-based pub/sub IoT system:
- Avoid sending credentials in cleartext, always use TLS protocol when authenticating with username and password due to lack of encryption in default MQTT configuration. For resource-constrained devices, use TLS-PSK in securing communication over MQTT;
- If TLS is not an option consider using X.509 client certificate authentication with payload encryption and data integrity verification;
- Disable wildcard subscription feature on MQTT broker and control subscriber authorization by prefixing topic strings to client IDs (credentials) for systems with authorized topic access;
- Consider using access tokens with OAuth 2.0 framework for large-scale implementations;
- Consider using additional security mechanism on the application level, such as application ID validation;
- Never rely on a single security mechanism, use layered security approach to protect your IoT implementation whenever possible;
- Configure network security before deploying your IoT system;
- Disable/restrict access from the Internet for all other services that co-reside with MQTT server;
- Perform penetration testing and vulnerability assessment before moving an IoT solution into production phase