Exposed IoT Automation Servers and Cybercrime

by: Stephen Hilt, Numaan Huq, Martin Rösler, and Akira Urano

In our latest research “Cybersecurity Risks in Complex IoT Environments: Threats to Smart Homes, Buildings and Other Structures,” we tested possible threat scenarios against complex IoT environments such as in smart homes and smart buildings. A significant part of the research also involved a look into exposed automation platforms or servers, which are integral components of complex IoT environments.

We define Complex IoT Environments (CIEs) as being made up of enough IoT devices — 10 from our experience — to create a web of dynamic interactions based on set rules. In these environments, an automation server functionally chains the devices together and enables functional interactions of devices that characterize such environments. There are two types of automation servers an IoT environment could have: the open-source server and the commercial server. Both not only have great control over devices but also hold important information. These servers are critical for such an environment – with each additional device added, the number of possible interactions and rules grows exponentially.

If a server is unknowingly exposed online, it could allow attackers to reprogram automation rules or steal hardcoded information. As the automation rules get more and more complex with more devices added, an administrator will have a hard time noticing attacker’s logic changes even after inspection. Checking if an automation server is exposed online is therefore a significant aspect of CIE security. For our research, we used Shodan to see if there were indeed any exposed automation servers and share details on those that we found in this post.

General findings

We searched through Shodan, a search engine for internet-connected devices, and came across a number of open-source automation servers. What sets open-source automation servers apart is their programmable logic layer, which allows users to change rules and add devices to a CIE. Compared to commercial automation servers we will discuss later, open-source servers are a lot more versatile.

The most common exposed open-source IoT automation servers that we found were Domoticz, Home Assistant, openHAB, and Fibaro Home Center. Countries that had the most number of exposed servers were mostly industrial nations in Europe, North America, Australia, and Japan. Of note are the automation servers we found in Thailand, Vietnam, Chile and Argentina, which could be an indication that although IoT automation is still in its early stages, it is quickly spreading globally.

Figure 1. Exposed IoT servers found using Shodan

Figure 1. Exposed IoT servers found using Shodan

The count is based purely on servers found in Shodan, so we need to point out certain considerations: 1) Shodan data does not include all exposed servers, 2) not all automation servers are exposed on the internet, and 3) daily results are constantly changing because of dynamic IP addresses. Therefore, the actual total number of exposed automation servers could be greater.

Whatever the actual number is, the fact that it is in the tens of thousands is concerning. Exposed systems can contain sensitive information and provide access to anyone who finds them. This is demonstrated by the exposed open-source servers Home Assistant, FHEM, and Node RED, which we will discuss further.

Open-source home automation servers

As can be seen in Figure 1, we found thousands of Home Assistant servers exposed in Shodan. Home Assistant is an open-source home automation server that allows users to run all their connected home devices from a single, mobile-friendly interface. Home Assistant runs on a dedicated server, whether RPi or local, so all device data is stored locally and not in the cloud. Home Assistant out-of-the-box supports many of the popular IoT devices, rules can be programmed via the GUI as well as written in YAML.

We found more than 6,200 exposed Home Assistant servers online, most of which were from the U.S. and Europe. Home Assistant has a history feature that shows the operational status of devices and, once accessed, could indicate when the inhabitants are away from home. In some exposed homes, their Home Assistant configuration file contained important credentials, like hardcoded router username and password. It is good to note however, that Home Assistant enforces password protection and most of the exposed home servers were password protected.

Figure 2. Exposed history of devices

Figure 2. Exposed history of devices

On the other hand, we found fewer exposed smart homes using FHEM servers. FHEM is a home automation server popular in Europe, a fact that coincides with our findings as most of the exposed FHEM servers were from Austria and Germany. It’s a Perl server that can be used to automate repetitive day-to-day tasks at home, like controlling the thermostat, switching lights on and off, and regulating power consumption. Like Home Assistant, its program runs on a dedicated device and can be controlled using the web, a smartphone, Telnet, or TCP/IP.

Information on the exposed FHEM servers included configuration files and device activities. Configuration files contain a wealth of information, like hardcoded credentials, lists of all devices in the home, and each device’s location. Exposed FHEM servers could also show others details from the devices connected to it, like device status, sensor readings, and even electricity usage.

Open-source home and industrial servers

Another type of automation server we found exposed online was Node-RED, a flow-based programming tool for chaining together devices, APIs, and online services. What sets Node-Red apart is its support for both smart homes and industrial processes. This crossover support for IoT and IIoT spaces is a capability that we think will eventually be possible for other IoT automation platforms.

Figure 3. Exposed detailed log files recording all events triggered, found in the same location as the configuration file

Figure 3. Exposed detailed log files recording all events triggered, found in the same location as the configuration file

We found around 880 exposed Node-RED servers online. Most of these were located in the U.S., Germany, Japan, U.K., and the Netherlands. Since Node-RED can be used for both home and industrial applications, these servers came from a wide variety of settings. Examples that we found that were not smart homes included a greenhouse and a parking garage flow in Japan.

Figure 4. Exposed automation flow for a parking garage in Japan

Figure 4. Exposed automation flow for a parking garage in Japan

Commercial automation servers

We’re adding in this discussion the few commercial home automation servers we came across in our Shodan search. Commercial automation servers offer a lot less flexibility than open-source servers. This means they can’t integrate as wide a range of IoT devices in their systems. However, they are still capable of some level of control over households since they can be used to operate preinstalled devices.

Potential attackers would not be able to conduct significant smart attacks against exposed commercial automation servers using the logic layer — commercial ones do not have a user-programmable logic. However, these exposed servers freely share information and access to anyone querying them without requiring proper authentication. Some of the controls that we found included those for the intercom, cameras, lights, and alarm systems.

Figure 5. Exposed controls for a home alarm system

Figure 5. Exposed controls for a home alarm system

Security and control

Exposure of automation servers opens smart homes and even smart buildings to several attack scenarios. For open-source automation servers, attackers can reprogram rules which, in turn, lead to a slew of different other attacks — from secretly adding devices to the system to turning off all security setups. Even exposed commercial servers can give attackers physical control over a household by allowing them to interact with controls like alarm systems. Exposed automation servers in buildings and industrial settings could impede business operations should their setups be tampered with. In addition, attackers can monitor and note patterns in resident behaviors using the information readily available in the exposed server.

In securing a CIE, a good place to start is its automation server. Since automation servers do not alert users if there had been a change in its rules, users should frequently check the logic layer for any changes. In this regard, using version control software would help users track changes in their code, as well as revert their code quickly to its original version in case of compromise. Users should also filter the information their automation servers hold. An automation server is a powerful tool that makes CIEs run smoothly and efficiently. As such, it is crucial for its control to remain in the right hands and not fall into the hands of unforeseen attackers.

To get a fuller understanding of other threat scenarios, you can read the rest of our findings in our paper “Cybersecurity Risks in Complex IoT Environments: Threats to Smart Homes, Buildings and Other Structures.” We also detail best practices to help build safer CIEs.

The post Exposed IoT Automation Servers and Cybercrime appeared first on .

This post appeared first on Trend Macro Blog
Author: Trend Micro