MQTT Cyber Security Risks Can’t Be Ignored.

MQTT cyber security risks must be considered by security installers and integrators – not only because the protocol is used in sub-systems, but because it’s also used by and supported by many security devices.  

There’s a lot of talk in the security industry about the cyber security levels of controllers and devices. Do the same issues apply to some Internet-facing smart home devices and systems? Yes, and it all comes down to the configuration of communications paths and the level of integration applied between network devices and lightweight management controllers.

While there are proprietary comms protocols in the electronic security industry, in the wider world network comms is going to be some form of Message Queueing Telemetry Transport (MQTT) protocol. OpenStack, Open Geospatial Consortium Sensor, DeltaRail IECC Scalable, Adafruit, EVRYTHNG IoT, Amazon IoT, Home Assistant, Pimatic for Raspberry Pi, MS Azure IoT hub and more, all use MQTT for device communications.

MQTT Cyber Security Risks

What is it? Developed by Andy Stanford-Clark of IBM and Arlen Nipper of Cirrus Link on the back of the SCADA protocol back in 1999, Message Queuing Telemetry Transport is an ISO standard publish-subscribe-based messaging protocol which sits on top of the TCP/IP protocol and it designed to facilitate connection with remote locations when bandwidth and power are in very short supply, which is great for wireless-based home automation applications.

MQTT is a flexible protocol. The application layer runs on top of the TCP/IP network and covers BGP, DHCP, DNS, FTP, HTTP, IMAP, LDAP, MGCP, MQTT, NNTP, NTP, POP, ONC/RPC, RTP, RTSP, RIP, SIP, SMTP, SNMP, SSH Telnet, TLS/SSL, XMPP and more, the Transport layer is just as comprehensive and the Internet and Link layers are well catered for. And it’s compact. The smallest control message might only be 2 bytes in length (the header), though such messages can extend to 256MB.

Operationally, MQTT uses a hierarchy of topics to communicate and it manages this by firing a control message of data to a connected broker, which distributes the data to clients on the network subscribed to that topic. There’s an elegant simplicity to all this that’s just like an RSS feed. Because it was developed as a SCADA protocol, MQTT was created to manage short telemetry data messaging in off-line environments.

Of note, MQTT has no standard, and it can carry any payload you throw at it, publishing it to all ‘subscribers’ in a network. The publishing of a topic needs no information about subscribers, the subscribers need no information about publishers. Use of a topic to as a filtration system and file path via which to communicate with subscribers means a message gets delivered to the right subscribers. This means MQTT is great at bridging gaps between devices siloed by proprietary comms protocols – it forms a sort of auxiliary machine language – a mechanical Esperanto.

In standard trim, MQTT transmits connection credentials in plain text format – there’s no security or authentication applied – you need to use the TCP transport layer to incorporate end-to-end message protection. Alternatively, you could subscribe your devices to a something like the PubNub Network with MQTT for added security, additional functionality, as well as message storage and playback. There’s also now MQTTS, which adds encryption at the cost of an increase in power demand that can be too onerous in some applications.

MQTT Cyber Security Risks

The security issues come into play with MQTT when it comes to configuration of a home automation system around a PC or a mini computer using server software like Mosquitto. If the server security config, such as access control, is muffed, then servers will be exposed on the Internet to basic searches uses programmes like Shodan, and if a hacker gains access to the system then it’s not going to be complicated to gain access to the system and gather information on the state of the alarm system, the times residents come and go, as well as being able to deactivate or activate devices, such as sensors and door locks.

As mentioned, MQTT is often included in smart home hubs where it assists with the delivery of automation capabilities. The automation side of such systems resides onboard the hub and facilitates unification of devices, as well as providing a dashboard for the management of connected devices.

If MQTT is not included in the hub, it can be set up separately – in either case, it allows hubs to subscribe and publish messages about system state and operation, as well as to allow devices to communicate between each other to drive logic – for instance, if the soil sensor detects low threshold soil moisture, activate irrigation.

This capability represents the power of MQTT but also the fragility. A messaging protocol capable of driving system function needs to be thoughtfully configured if it is not to introduce vulnerability into a home automation solution if the server config is mishandled during the process of setup.

Before we go further, consider that a given instance of MQTT uses # to represent all levels at its location – if a device is subscribed to /home/familyroom/# it will receive any message published to /home/familyroom/lock or /home/familyroom/light. If a ? symbol is included in the string /home/?/familyroom/lock/# then the device will get all messages relating to locks.

MQTT really powers up with smart home hubs, which subscribe and publish MQTT messages and deliver logic. Such hubs also generate a dashboard from which users can manage their system. MQTT allows the hub to put messages together and automate disparate devices that don’t understand each other’s language. For instance, when the ambient temperature reaches 30 degrees on the verandah, the air conditioning in the living room will turn on.

This central communication capability is where issues can arise with MQTT. The MQTT server is the interpreter between devices, while the smart hub manages devices and delivers system logic, and MQTT-enabled devices are installed in the system and connected to the MQTT server. The stumbling block is that the MQTT server probably doesn’t have a secure config or may be misconfigured and if anyone can access that server, they can read all a system’s MQTT messages relating to any devices in any location by simply subscribing to # on the system.

It gets worse because some MQTT servers are internet facing and don’t have a password. Users who deploy Mosquitto to manage a home hub, but have no ACL or don’t actively configure an access control list, leave their system open to being subscribed to by network intruders. They will be able to read all communications and can also publish messages that will control MQTT-enabled devices connected to the MQTT server they have breached. In some cases, misconfigured MQTT servers expose the smart hub dashboard to the internet – there are tens of thousands of MQTT servers exposed on the internet.

MQTT Cyber Security Risks Can’t Be Ignored

Things can get trickier still because a lot of MQTT servers feature owntracks/, which is an iOS and Android application that’s fundamentally a GPS tracker used to manage the system based on geo-location. This is problematic because it allows your location to be tracked by showing the GPS co-ordinates and even the altitude of a connected smart device.

Typically, owntracks/ is configured without encryption or authorisation and to set it up, a smart device needs to be exposed to the internet. Then there’s the fact a message is sent to owntracks/ each time a linked phone changes its location. The level of detail is significant and historical with time and date – it even includes the battery level of the smart phone being tracked and this tracking is going on in real time.

MQTT Cyber Security Risks-Applying security to MQTT-governed devices comes with certain challenges. For instance, IoT devices are constantly looking for an opportunity to fall asleep to preserve battery life and manufacturers will minimise processing power and memory to reduce current drain. This means cryptography might ask too much of a device’s expected battery lifespan, so it’s left out.

Further, many IoT devices are self-governing to make setup is easier – that means they are likely to be less secure, not more secure. Then there’s the fact MQTT is meant to be lightweight – it’s not designed for the heavy lifting of secure communications. Does that mean it’s not a useful and flexible automation protocol? Far from it – you just need to be sure security is factored in.

To secure MQTT-enabled systems, you need a physically secure gateway, like a VPN, to carry messages between server and devices. If you don’t want anyone to be able to read your system’s messages, then TLS/SSL will give transport comms encryption that’s relatively easy on processing and quite secure.

At the application level, comms can be encrypted and the identity of parties in the system may be subject to authentication. This may be handled using payload encryption at the application level, which saves the labour of transport encryption. Part of this may be use of whitelists, which only allow connection to trusted applications and URLs rather than attempting to block a list of known threats which must be regularly updated.

You can learn more about MQTT security strategies here or read more SEN news here.

“MQTT Cyber Security Risks Can’t Be Ignored.”