Introduction

Today, we hear a lot about IoT, which stands for Internet of Things. All these smart boxes, light bulbs, shades, thermostats, voice assistants, and smart machines are slowly sneaking into our households, businesses and industrial environments. It’s a logical and inevitable next step, as we include more devices in our homes, that we develop some way to control them.

Interconnecting and controlling smart home devices is possible using the Message Queuing Telemetry Transport (MQTT) protocol.

When implementing the MQTT protocol, users set up a server. For consumers, the server usually lives on a PC or a mini computer such as Raspberry Pi, to which devices can connect to and communicate with. While the MQTT protocol itself is secure, if implemented and configured incorrectly, severe security issues can arise. At Avast, we took a closer look and using the Shodan IoT search engine found more than 49,000 MQTT servers publicly visible on the internet due to a misconfigured MQTT protocol. This includes more than 32,000 servers that had no password protection, putting these smart homes and businesses using such MQTT servers at risk of leaking data. If the MQTT protocol is not properly configured, cybercriminals can gain complete access to a home and for example, learn when their owners are at home, manipulate entertainment systems, voice assistants, household devices, and physically open smart doors.

Focusing on smart homes, you might be asking yourself: Why is a protocol like MQTT necessary, if it could put my home’s security and privacy at risk? Manually controlling a few smart devices is not a problem, but as they increase in number in our homes, they take more time to manage, and become a burden. It’s like managing a big computer network manually. At some point, without automation, managing connected devices becomes more work than the convenience is worth. Then along come more smart devices that connect with each other and cooperate and do tasks on their own without human interaction. For example, your garage door opens automatically as you arrive back home from the office, your house lights turn on, the thermostat is configured to a comfortable temperature, and your stereo begins to play jazz music in the living room.

So far, sounds nice, but what about security? Authentication? Authorization?

Complex systems that allow you to control your whole house from a mobile device, basically from anywhere in the world, are being built. The question is —how secure are these systems? They may not be as secure as you think.

The problem with IoT security

The reason IoT security is lacking is because the devices are built using technology protocols that date back to the 1980s. This is generally because the early use cases for IoT devices were largely industrial. There was high demand for systems that could collect and process data from various machines in factories or production lines. These “networks” weren’t using internet protocols to exchange data. In fact, they usually did not have external connectivity, so security was not a top concern.

The other problem is that people don’t generally  focus on security when setting up IoT devices. If you don’t encourage the user to change the settings (at least to change the default password), they will probably end up using the default configuration.

Meet MQTT

One of the most common protocols that smart devices use to communicate is MQTT. It stands for Message Queuing Telemetry Transport, and was developed in the late 1990s as one of the SCADA protocols. It was used mainly for industrial automation and is, as its name suggests, for transporting short telemetry data messages. There is no standard for the format of data it transports — it will carry virtually any payload. The protocol is meant as a subscriber/publisher model. It works like an RSS feed: you subscribe to a topic, and once someone publishes something on the topic, the payload is delivered to all subscribers.

As mentioned earlier, there isn’t a security issue with the MQTT protocol nor the most common server software that implements this protocol (or broker as it is known in the case of MQTT), which is called Mosquitto. In fact, both MQTT and Mosquitto have broad security capabilities — for example, to provide fine-grained access control by user and topic. As with many things, the problems are created in the implementation and configuration. Let’s explore some real world use cases for MQTT before we dive into what can go wrong.

MQTT is often used to overcome the gap between different protocols, so that different devices can communicate with each other even if they do not communicate using the same protocol. It’s very convenient as it allows topics to be organized in a hierarchical structure, creating a unified namespace for the whole smart home. For example, a topic structure can look like this:

    /myhouse/garage/lights/doorlight

    /myhouse/garage/lights/ceilinglight

    /myhouse/garage/garagedoor

    /myhouse/livingroom/speaker

    /myhouse/kitchen/oven

    /myhouse/kitchen/lights

You can see the structure is hierarchical, in this case outlining a structure for connected devices in a home. One of the things that makes MQTT so useful is that you can use wildcards when subscribing to the topics, similar to how filename or search wildcards work.

MQTT has two wildcards: # and ?

# stands for all levels from its location/occurence, down the hierarchy, so for example by subscribing to:

    /myhouse/garage/#

An IoT device will get any message published to /myhouse/garage/lights or /myhouse/garage/garagedoor.

The ? stands for all categories on any level and can be used anywhere in the hierarchy, more than once. So by subscribing to:

   /myhouse/?/lights/#

the device will receive all messages regarding the lights in any room, as ? in this case can be a kitchen or garage, for example.

By combining subscriptions, you can create a very complex scenario for controlling a group of devices by publishing on just one topic. Publishers can be, for example, MQTT-capable light switches. By pressing them, an MQTT message is published and action is taken. Any device can be a publisher, subscriber, or both.

But to create a really smart home we are still missing one crucial component: Automation.

Home automation usually comes in the form of software, or perhaps a smart box, which contains “business logic” and acts as a “smart home hub” to unify the control of the devices, which is where MQTT comes into the picture. MQTT is included in most smart home hub software solutions, such as Home Assistant, so users can either install a package that includes MQTT or install MQTT separately when setting up their smart home hub. Smart home hubs usually subscribe and publish MQTT messages and provide logic. They also provides some kind of dashboard, either locally or remotely, where you can control the whole “smart” home.

For example, if the hub gets the message from a soil sensor in your garden that the soil is too dry and knows that your water tank has enough water, it can activate the irrigation system to water your flowers. In this way, a number of smart devices can be connected to a smart hub, controlled, and even automated, using the MQTT protocol, even if they weren’t originally designed to work together.  

The problem with MQTT

Let’s lay out the problem more clearly.

We have an MQTT server (broker) with embedded security capabilities, which serves as a “messenger” between all components. We have a smart home hub which orchestrates all our devices and adds real intelligence to the whole system, and we have various MQTT-capable or MQTT-bridged devices that are connected to the MQTT server/broker.

This all sounds good and makes sense, but what if the MQTT server does not have a secure configuration? As with a lot of vulnerabilities, the main issues are insecure and default configurations. What makes the misconfiguration of MQTT worse is that by getting access to the MQTT server, you get access to all the messages flowing through it. How? Remember # as a wildcard? You can subscribe to just # and nothing else. In such cases, every time someone publishes something on any topic, you’ll get that data.

More concerning is that many poorly configured MQTT servers are also publicly available on the internet without any password, allowing a cybercriminal to spy on any house that uses it. The “advantage” for the cybercriminal is that if the server is publicly available, he or she can connect to it from anywhere. Further, as most users don’t set up access controls— in the form of Access Control Lists (ACLs)—when they configure a Mosquitto while setting up their smart home hub, cybercriminals can not only subscribe to the server, but can also publish to it, thus seizing control of all devices in a smart home.

So, what is the scale of this problem? According to the Shodan IoT search engine, there are almost 49,000 MQTT servers exposed on the internet. Of these, there are approximately 32,000 servers with no password protection.

The vulnerabilities reflected by the total results above are most likely due to misconfigured MQTT servers. As users set up these systems to remotely control their smart home, they often expose not only the “dashboard” or control panel of the system, but also the MQTT server, as these two components usually run on the same machine or server. When this happens, it can leave users exposed. We found that, generally, it was not overly clear to users how they securely configure their MQTT connection during the installation process. 

Here are a few examples of what can happen in the event the system is misconfigured.

Five easy ways to hack a smart home

We decided to see how easy it would be to gain access to an exposed smart home:

1) Connecting and subscribing to wildcard topics on an unprotected MQTT server

Our first test was to find an open and unprotected MQTT server and subscribe to the # topic. This was easy enough and, once connected, we were able to receive every message published. In the case of some home automation systems, we could see the status of window sensors and open/closed doors. We could see every press of any light switch in the house and even the local weather forecast as you can see in the following image.

A weather forecast in addition to other topics, published
by an unsecured MQTT server

There are usually no ACLs (Access Control Lists), which is a fine grained access control to the topics in place, so once you are connected, you can also publish to topics. In this case, you can control devices or at least poison the data being collected by publishing on behalf of the devices. For example, you can send messages to the hub as if you were the security sensor at the smart home’s front door smart lock, because MQTT messages do not have a sender field so the message receiver is unable to determine where the request came from. Due to this, cybercriminals can easily perform “replay attacks” and send messages on behalf of the devices connected to the hub.

2) Connecting to unprotected smart hub dashboards on a secure MQTT server

What if the server is protected? Can we still get access to the home dashboard? We found that a smart home can be hacked even on a secure MQTT server, as sometimes a dashboard (smart home control panel) runs on the same IP address as the MQTT server.

Many homeowners use open source solutions for their smart home. The most popular software for smart hubs are readily available solutions such as Domoticz, Home Assistant and OpenHAB. When we looked for these, we were able to see a lot of default configurations, which surprisingly required no password. So, even if the MQTT server is secure, the dashboard can be accessed as easily as typing the IP address into a browser. By doing this, onecan get complete access to the house, all through a nice UI, like this:

Example of a publicly available dashboard of a home automation system—allowing full control of all connected appliances

Exploiting this access would allow a cybercriminal to control any of the devices connected via the dashboard including lights, locks, heating and cooling systems, cameras, and more. With this control, a cybercriminal could do any number of things, such as secretly spy on or record people within their home, drastically adjust their home’s temperature, or gain entrance to the home while the homeowners are on vacation or at work, without setting off any alarms.

3) Reading files on a protected MQTT server with a protected dashboard

But what if both the dashboard and the server are protected? There should be no way to gain access to the smart home, right? Well, maybe there is. How? It is as simple as checking other services.

In the case of the Home Assistant software “smart hub,” we found several instances of properly configured MQTT servers that were not exposed and a dashboard that was properly configured and password-protected. But, what was astonishing is that we found open and unsecure SMB shares. SMB is a protocol used for sharing files on internal networks, mainly on the Windows platform. We found publicly shared directories with all the Home Assistant files including configuration files. And that’s not all. Let’s see what else we found:

Home Assistant’s login screen

As you can see in the image, when we tried guessing the password, leaving it blank or using the default password (“welcome”), it didn’t work. So far, so good. The dashboard is protected.

Listing from SHODAN search engine on the same address

We then decided to run a Shodan query on the same IP address. It turned out that there was an SMB (file sharing) service running without a security set. Note that Home Assistant shares all the files of installed software including configuration files.

Content of previously shown unsecured shared directory with configuration files

When we were browsing through the exposed files, a particular one caught our eye. Did you notice the secrets.yaml file in the image above? When we opened it, we were astonished at the file’s content.

Content of the secrets.yaml file

The secrets.yaml file contained usernames and passwords stored in plain text. There are also many other accounts for different cloud services or API keys that can be misused to gain control over them. What we were interested in was the http_password field. Using that field for a login screen, we got this:

Full control over home automation

As you can see, that’s complete control over someone’s house. You can even play audio via Spotify. We were trying to find a reason why there are so many poorly protected instances of Home Assistant.  

We believe that the problem here is that users are not aware of the fact that once they install HomeAssistant on the server (in this case it’s probably HASSBIAN flavor of HomeAssistant intended as a ready made package for installation on various types of underlying hardware) and expose it to the internet to get access into the dashboard, they also often expose a Samba share that is used for accessing the configuration and installation files of HomeAssistant. By doing this, they unwillingly leave the whole system exposed to anyone and leak all the passwords and API keys stored there to the public. It has to be noted that even the tech savvy users sometimes lack basic knowledge of how to properly secure their open source systems.

4) Creating a UI on an unprotected MQTT server

Here are some interesting tools/apps out there that let you create a simple dashboard for an MQTT-based smart home. We found an application called MQTT Dash for Android and iOS that allows you to create your own dashboard and control panel for your home by placing various tiles on the screen and linking them with MQTT topics. What is most interesting is how the application stores the layout of the dashboard and configuration. Instead of creating a special file on your device, you can publish the whole setting to the topic of the MQTT server, and by doing so, can easily replicate the settings on as many devices as you wish.

That’s very convenient, but if the MQTT server is  not secure, a cybercriminal can easily get the same UI as the user. This provides an easy way to hack someone’s home and even get their UI with just one connection to their MQTT server. Again, the default configuration makes it easier, and if there is a dashboard in use, such as one set up with the MQTT Dash app, you’ll most likely find a topic with the name “metrics/exchange,” a so-called “retained” topic. If you subscribe to a retained topic, you’ll receive the last stored payload/data, which basically means you can easily load the whole dashboard, as you can see in the following picture:

MQTT Dash application in Android emulator on PC

5) Tracking device location

What could be worse? MQTT servers typically concentrate on a lot of interesting and real time data. What we found is that many MQTT servers, some of which were not even connected to a smart home system, contain one very interesting topic beginning with owntracks/…..  If you do a short Google search, you can see that OwnTracks is an Android and iOS application that works as a personal GPS tracker. What is even more interesting is that it supports the MQTT protocol to share your location with your friends or family. Up until now, this sounds like an innocent function, right? Wrong! This feature is usually configured by connecting to an MQTT server without any encryption or authorization. Moreover, to be able to connect your phone to an MQTT server, you need to expose it to the internet and unfortunately, many users setup the configuration without considering any security measures. OwnTracks then sends a JSON message to the MQTT topic owntracks/… each time the phone changes location. Creepy right? Let’s see what the message looks like:

Message delivered to MQTT server by OwnTracks application

Recorded positions during the course of one week

The lon (longitude), lat (latitude) and alt (altitude) fields are self explanatory. You can even see the battery level of the phone is also sent to the server. The “tst” field is actually a timestamp for the position and is written in the UNIX epoch format and after decoding we found out the timestamp is from: Tue 7 August 2018 11:26:48 UTC. Using all this information you can easily reconstruct someone’s position during the day, month or year. And remember, all this information is available as real-time data.

Now you’re probably asking yourself, why share your location with the MQTT server? Well the answer is ….automation and convenience. Some of the “smart home” hubs or systems allow you to share your position with them to provide you with a better experience. Remember the scenario where your house automatically turns on the lights as you get close to home? Or, you could have your system turn off all the lights whenever nobody is at home. The sharing of GPS location information is exactly what the system needs to provide this functionality. The problem here again is security, more specifically, unsecured protocols and unencrypted OwnTracks messages. All because users rely on default configurations.

Conclusion

Because there are still many poorly secured protocols dating back to bygone technology eras when security was not a top concern, it is frighteningly easy to gain access and control of a person’s smart home. The convenience of IoT devices and smart home hubs connected to the internet is a double-edged sword, and there is a trade-off between ease-of-use and security.

Consumers need to be aware of the security concerns of connecting IoT devices that control personal parts of their home to services they don’t fully understand and the importance of properly configuring their devices. Industry-wide, we have called for better device-level security for IoT devices. In order to ensure users’ entire smart home ecosystem is secured, manufacturers need to develop IoT devices which are simple for consumers to set up with a high-level of security.  Lastly, there is a need for more secure control solutions that allow consumers to confidently use technology in their homes with the knowledge that it is secure and their privacy protected.

IoT devices are slowly creeping their way into our homes—it is crucial to implement them correctly now, as we will only be adding more as time goes on.