Security Week 28: Hacking a Smart Home

What risks do we take on installing a smart home system? The one that steers the light bulbs and a kettle from the application on the smartphone, inside the local network and remotely. If the smart system is tied to security and locks management (as in the case of the Amazon Key) - then it is clear what. If not, then theoretically it would be possible to imagine the danger of a software outage of some coffee maker followed by a fire. But it is better not to dream, but to know for sure.

Experts from the ICS CERT team at Kaspersky Lab decided to conduct a field test on the smart home of one of the company's employees ( news , blog post , technical article ). The hacking was successful: the coffee maker did not suffer, but it was possible to get control over the system, albeit with a couple of (quite realistic) assumptions during the experiment. One of the unpleasant consequences of this attack was the leakage of personal data: the coordinates of the house and, what is the saddest thing, the geolocation of the smartphone. However, the experiment ended on a positive note: the manufacturer of the smart home system has successfully closed vulnerabilities.

Artistic interpretation of the effects of hacking

In the technical article, quite a lot of space is devoted to relatively boring, but important points: what was NOT able to be hacked, and how the smart home system was analyzed for potential vulnerabilities. Before the experiment, researchers already knew the manufacturer of the system. It turned out to be the company Fibaro , which produces a range of its own devices for a modern smart home, as well as providing integration with third-party devices. Moreover, the owner gave an important hint - a permanent IP to enter the admin area. By the way, Fibaro itself does not recommend opening access to the controller over IP - only through the cloud system. In this experiment, this consciously left loophole played a role.
')

Theoretically, such a system can be attacked in three main directions: try to somehow break the control device, look for vulnerabilities in the cloud part of the service, or attack IoT devices connected to the controller. In the latter case, you need to be in close proximity to them, so the first two options look more promising.

The next step is to analyze the device firmware and WebAPI. Usually, on such an analysis, everything ends, and the news comes out in the style of “a password has been found in the device”. But in the case of Fibaro, there were no obvious security holes. But useful information was obtained about the implementation of part of the control logic in PHP. Without authorization, the controller gives only the serial number of the device, and this information is useless for breaking the piece of iron. But, as it turned out, it allows you to hack the cloud part of the service.


Access to the cloud, in turn, allows without authorization to get backups of the SQLite database containing all the device settings, and upload their own. Theoretically, authorization bypass made it possible (until the vulnerability was fixed) to download backup copies of all users of the cloud system. Analysis of the real base of the attacked device provided access to private information, including the coordinates of the house and the smartphone on which the control application is installed. This is already a serious problem, since (with some limitations) it allows you to determine when the owner of the system is not at home.

In addition, the database contained complete information about the connected IoT devices, as well as a password for accessing the settings, but hashed with the addition of salt. Analysis of the firmware showed that the "salt" is not random, but firmly sewn into the device. Theoretically, a very simple password can be cracked, but in this case it did not work. The SQLite database also contained open passwords for connecting to other devices within the network: if these passwords coincided with the main one, the controller could also have been easily cracked.

But again it did not work: the owner of the system was familiar with the basic recommendations for security and did not use the same password for different devices. Therefore it was necessary to apply social engineering. The vulnerability in the cloud system, which allows for a series of actions without authorization, knowing only the serial number of the device (which is given "free" if there is access to the admin from outside), made the following scenario possible. A prepared backup copy of the device into which the malicious script was embedded was uploaded to the “cloud”. A message about the need to "update" the device through the regular capabilities of the cloud system was sent to the owner (via email and SMS).

Since the owner of the system knew about the experiment, he immediately realized that this was not a real patch. But in general, this is a very real scenario, when a plausible message arrives through a familiar communication channel to the user, so a backup has been installed. The malicious code was executed with system privileges due to an oversight in the PHP code that causes the execution of the bash script:


Here, the parameter set by the user (in normal conditions even the system administrator does not have superuser rights on the device), falls into the argument for the command line. The insufficient verification of the arguments allowed the arbitrary code to be executed with the “root” rights and finally to get full control over the device. At the same time, the possibility of conducting a SQL injection was found, but not used:


The researchers did not plan to crack the coffee maker in a real house, so they changed the melody of the alarm clock as a “hello”. The mentioned vulnerabilities both in the cloud system and in the controller code were closed. For obvious reasons, the specific protection bypass methods are not disclosed in the technical article - in order to avoid being used by real intruders on devices that have not yet been updated. But in this experiment, what is usually left out of the news headlines is well shown: many ways to research the protection of a device, most of which end in nothing. In actual experience, both the device manufacturer and its owner were able to avoid the simplest security errors, such as stitched and reused passwords. Nevertheless, a sufficient number of problems were identified that could lead at least to leakage of private data, and in the worst case, to bypassing security systems.

Disclaimer: The opinions expressed in this digest may not always coincide with the official position of Kaspersky Lab. Dear editors generally recommend to treat any opinions with healthy skepticism.