Introduction

In today’s interconnected world, more and more devices are being connected to the internet, including everyday household items like pet feeders that are becoming smart by virtue of this simple fact. However, as these devices become more sophisticated, they also become more vulnerable to cyberattacks. In this blog post, we’ll discuss the results of a vulnerability research study focused on a popular model of smart pet feeder. The findings of the study reveal a number of serious security issues, including the use of hard-coded credentials, and an insecure firmware update process. These vulnerabilities could allow an attacker to gain unauthorized access to the device and steal sensitive information, such as video footage, potentially turning the feeder into a surveillance tool. In addition, tampering with the feeding schedules could endanger the pet’s health and place an additional financial and emotional burden on the owner. Finally, it highlights the risks of a chain reaction type of attack, as once an attacker gains control of a pet feeder in the home network, it can be used as a hub to launch more attacks against other devices in the network.

Smart pet feeders: What they do

Smart pet feeders are internet-connected devices that dispense pre-set portions of food according to a pre-set schedule and allow you to monitor or communicate with your pet remotely. For the latter purpose they are often equipped with a microphone, speaker and camera.

Typically, pet feeders are controlled by a mobile application that allows you to set, update and manage them. Communication between the device and the app takes place via a cloud server. The first time the feeder is used, the user must set up the wireless network that the feeder will use from this app.

Methodology

For this research, we chose a popular Dogness device model and were able to identify security issues in it. We approached the device by first analyzing the network communication traffic between the mobile application and the cloud, and between the cloud and the pet feeder. We did this by placing the device in a sandboxed environment from the outset. We also used dynamic instrumentation to bypass SSL certificate verification (SSL pinning) from the application. For convenience, the app ran on a single board computer ARM64 (Raspberry Pi 4b) running Android 11.

The described setup allowed us to verify the information passing through, for example, during the over-the-air update process.

Then, more specifically, we analyzed the mobile application itself using static reverse engineering of the different use cases.

We also proceeded to crack open the device, looking for debugging interfaces that would allow us to interact with the running device while having full access to its internals. Further hardware analysis of the circuit board helped us identify chips. We later managed to extract the firmware from the EEPROM for further static reverse engineering. Where relevant, fuzzing of some key libraries was performed to try to identify memory corruption bugs in the request handling functions.

Telnet running with hard-coded root credentials

One of the major vulnerabilities discovered in the smart pet feeder is the presence of a Telnet server running on the default port, with a root account that can be accessed remotely. The root account credentials for this Telnet server can be easily recovered by extracting the firmware from the device and cracking the hashes from the /etc/shadow file. A hard-coded root password is a significant security issue because all devices of the same model share the same root password.

The hard-coded root password

This root account can be used over the previously mentioned Telnet service on port 23 to gain full access to the device.

Connection to Telnet port 23 using the hard-coded root password

A remote attacker with such access can execute arbitrary code, modify the device settings, and steal sensitive information, including live video being recorded and sent to the cloud server.

Plaintext communication with the cloud

Not only is gaining access trivial, but the feeder’s communication with the cloud, including the authentication process, is in cleartext. This vulnerability is also particularly dangerous because it allows a remote attacker sitting between the device and the cloud to gain persistence on the pet feeder – even without having access to the device firmware – and to launch further attacks against other devices in the network and potentially steal more sensitive information such as personal identification information, credit card details, or other personal information.

Smart device manufacturers should focus on adding security features such as dynamic credential generation and secure communication protocols to ensure the safety of their products.

MQTT broker for Alexa support with hard-coded credentials

The Dogness smart pet feeder device has the ability to work with Alexa, allowing users to control the device through voice commands. The device uses an executable file that connects to a Message Queuing Telemetry Transport (MQTT) broker to receive and process Alexa commands. The problem with this setup is that the user name and password for the MQTT broker are hard-coded into the executable. This means that the credentials are embedded in the software and are the same for all devices of the same model.

The hard-coded MQTT broker credentials

The Alexa communication process is as follows. The device launches a binary called mqtt_alex that embeds the MQTT client code, which tries to connect to a server IP provided as an argument, and then tries to connect to a hard-coded domain name if it fails. Another IP address is found in the bash script called run_alex.sh that launches the mqtt_alex binary, but it’s commented out, which may indicate that this IP address belongs to a vendor test environment.

Upon successful connection, a series of subscription calls is made to the following topics, where the last subtopic level corresponds to the device ID.

Subscription calls

The device ID used is a 20-byte string generated by the /usr/sbin/get_uid utility at first boot based on the MAC address and two values called ‘uboot UID’ and ‘uboot encrypt’, which are then stored in a temporary file at /tmp/ipcam.txt. The latter two values are static and retrieved from NVRAM, while the first is obviously the only device-dependent value. The device ID is later loaded at the beginning of the MQTT client launch for further communication.

Device ID generation

An attacker connected to the MQTT broker could subscribe to a wildcard topic such as /voice/# to easily get notified of all messages, including the identifiers of other devices. Armed with these identifiers, any command related to the pet’s feeding schedule or food dispensing can be sent to any of the devices whose identifiers have been previously collected by publishing an MQTT message. So, the moment you connect your pet feeder to the MQTT broker to enable voice command control via Alexa, you need to be aware that you are no longer the only one who can set your pets’ feeding schedule.

The hard-coded credentials pose a significant security risk because an attacker can use them to connect to the MQTT broker. Once connected, an attacker can intercept and modify commands being sent to the device, potentially allowing them to take control of the device. It is critical that manufacturers use dynamic and unique credentials for each device.

Alexa voice command functionality denial of service

The aforementioned MQTT client for handling voice commands receives messages in JSON format, structured like the following example:

{"cmd": "shootreq","feedweight": "1","audioindex": "0","rand": "0"}

The client code responsible for parsing the received MQTT payload simply uses a set of JSON utility functions that call cJSON_GetObjectItem to get each attribute in a separate variable for later use in further internal communication.

JSON utility functions

Although there is no guarantee these calls to the cJSON_GetObjectItem function will not return NULL, the code assumes that they never will. Upon receiving a correctly formatted JSON, with all the attributes, the device will handle it normally and acknowledge with a corresponding resp topic.

Command messages

However, if it receives an incomplete JSON in which at least one of the attributes is missing, the client simply crashes. The following illustrates a JSON payload with the audioindex attribute removed. By exploiting this vulnerability, an attacker would be limited to performing a denial-of-service attack on the device’s voice control functionality. We also need to keep in mind that the run_alex.sh script will restart the binary if it stops.

Broken command message

The bug in the code that parses MQTT messages can lead to a potential denial of service, preventing this functionality from working normally. Although the MQTT client is reloaded after a crash, the attacker can repeatedly send broken commands, rendering the voice command interface inoperable.

Insecure communication with the backend server

While from the mobile application point of view communication with the cloud is handled via HTTPS with certificate pinning, the device itself behaves differently. The device functions that handle communication are located in a shared library that includes j_processCommandUploadVideo, which is used to upload footage to the backend.

Device functions including j_processCommandUploadVideo

The video footage is pushed to the server using the curl utility, with multiple parameters, including the device ID and an upload key that is hard-coded into the binary. As you can see in the image below, the request is made over a cleartext HTTP connection to the backend server.

Pushing video footage to the cloud

This issue could significantly impact confidentiality, as the device works as a continuous recording camera that is likely to be used indoors, with a strong possibility of capturing a private home environment that may contain sensitive information.

Insecure update process

The Dogness smart pet feeder uses an insecure firmware update process that allows attackers to potentially compromise the device. The firmware update process uses HTTP, an unencrypted protocol, to download the update package from the update server. The package is a compressed archive protected by a password. This password is hard-coded in one of the scripts used in the update process.

The hard-coded ZIP archive password

The HTTP URL to the latest firmware file is generated by the device after receiving the information from a URL hard-coded into the firmware.

http://                       /IMG_Server/images/server_list.txt

Attempting to provide a firmware verification routine that relies on a password-protected archive is insecure because the password can easily be extracted from the firmware, bypassing this verification. However, no other verification mechanisms, such as a digital signature, are implemented in these devices. This is a security issue because an attacker could modify the legitimate firmware or craft new firmware and load it to the device. In addition, because the communication is in cleartext over the network, an attacker could intercept the data and use it to inject malicious code into the firmware.

Manufacturers should sign their firmware files and establish a reliable signature verification mechanism to ensure the firmware is legitimate and has not been tampered with. Also, any such communication over the network should initially be over secure protocols such as HTTPS.

Conclusion

Assessing the security of devices such as smart pet feeders is not that different from auditing a smart camera with physical actuators that can be remotely controlled. The typical architecture includes various parts, including mobile applications, cloud backend and the device itself, all of which are involved in the operation and maintenance of the device.

To keep users safe, vendors must ensure that all communications to and from the device are protected from eavesdropping and tampering, especially during critical operations such as firmware updates. Using HTTPS instead of HTTP and enforcing certificate pinning not only in the app, but also on the device itself, typically makes it unlikely that an attacker can perform a man-in-the-middle attack. As an additional measure, enforcing firmware signature verification is one way to ensure a firmware update has not been modified or corrupted during the download process. In addition, implementing firmware verification at the boot level also adds another layer of protection by preventing modification via direct hardware access to the memory chip.

Secure credentials management in embedded devices is not necessarily a straightforward issue. Ensuring no hard-coded credentials provide access to anything on the device is a good security practice. Manufacturers must generate credentials at the time of manufacture on a per-device basis, in a way that cannot be guessed based on any available information. For example, using the device’s MAC address as a unique seed for a hash algorithm could eventually be reversed by a motivated attacker. The same concept applies to user-generated/provided credentials that may be stored on the device. Ensuring they are stored in a secure manner that prevents or makes it difficult for an attacker with physical access to extract them is an important security requirement.

Also, any services that can be accessed remotely must undergo a thorough security assessment, especially those that don’t serve the primary purpose of the device. Ideally, if any of these expose users to potential security risks, the vendor should make that clear to the users, along with some practical ways to mitigate those risks. When a firmware update comes out, it is also good practice to point out what kind of security issues it fixes, when it fixes them, and emphasize the risks being eliminated.

Finally, as with any system, users need to keep it updated to ensure they have the vendor’s latest software fixes, including those related to security. As for personal data, it is reasonable to assume the device may store information such as the user’s Wi-Fi credentials in a way that is potentially accessible to anyone with physical access to it, so it is important to perform a hard reset as described in the product manual before reselling or disposing of the device. For the more tech-savvy, a good practice is to connect these devices in a separate network away from critical devices such as home and work computers. Internet providers now ship home routers that can, for example, spin up an additional guest network. This might be a place to consider connecting such IoT devices to reduce the potential damage from unpatched or undiscovered vulnerabilities.

Timeline of communication with the vendor

• 17/10/2022        First attempt to establish contact with the vendor by email -> No answer
• 07/11/2022        Second attempt to establish contact with the vendor by email and via social media accounts -> No answer
• 15/11/2022        Third attempt to establish contact with the vendor by email -> No answer
• 08/02/2023        Attempt to establish contact with the vendor through the US customer support line by phone -> No answer
• 21/02/2023        First attempt to establish contact with the vendor through the Chinese customer support line by phone à Promised to share an R&D contact à No answer
• 06/03/2023        Second attempt to establish contact with the vendor through Chinese customer support line by phone -> Shared R&D email contact at Dogness
• 08/03/2023        Attempt to establish a secure channel for communication with the vendor by email   -> No answer

Kaspersky Lab’s many years of cyberthreat research would suggest that any device with access to the Internet will inevitably be hacked. In recent years, we have seen hacked toys, kettles, cameras, and irons. It would seem that no gadget has escaped the attention of hackers, yet there is one last bastion: “smart” devices for animals. For example, trackers to monitor their location. Such gadgets can have access to the owner’s home network and phone, and their pet’s location.

This report highlights the potential risks for users and manufacturers. In it, we examine several trackers for potential vulnerabilities. For the study, we chose some popular models that have received positive reviews:

• Kippy Vita
• LINK AKC Smart Dog Collar
• Nuzzle Pet Activity and GPS Tracker
• TrackR bravo and pixel
• Tractive GPS Pet Tracker
• Weenect WE301
• Whistle 3 GPS Pet Tracker & Activity Monitor

Technologies used: Bluetooth LE

The four trackers in the study use Bluetooth Low Energy (BLE), which in many cases is the weak spot in the device’s protective armor. Let’s take a closer look at this technology. BLE is an energy-saving Bluetooth specification widely used in IoT devices. What we’re interested in is the lack of authentication and the availability of services and characteristics.

Unlike “classic” Bluetooth, where peer devices are connected using a PIN code, BLE is aimed at non-peer devices, one of which may not have a screen or keyboard. Thus, PIN code protection is not implemented in BLE — authentication depends entirely on the developers of the device, and experience shows that it is often neglected.

The second feature of interest to us is the availability of services, characteristics, and descriptors. They form the basis for data transfer between devices in the BLE specification. As we already noted, BLE works with non-peer devices, one of which (the one that does the connecting) is usually a smartphone. The other device, in our case, is a tracker. After connecting to it, several BLE services are available to the smartphone. Each of them contains characteristics which in turn may have descriptors. Both characteristics and descriptors can be used for data transfer.

Hence, the correct approach to device security in the case of BLE involves pre-authentication before characteristics and descriptors are made available for reading and writing. Moreover, it is good practice to break the link shortly after connecting if the pre-authentication stage is not passed. In this case, authentication should be based on something secret that is not accessible to the attacker—for example, the first part of the data can be encrypted with a specific key on the server (rather than the app) side. Or transmitted data and the MAC address of the connected device can be confirmed via additional communication channels, for example, a built-in SIM card.

Kippy Vita

This tracker transfers GPS coordinates to the server via its built-in SIM card, and the pet’s location is displayed in the mobile app. The tracker does not interface “directly” with the smartphone. We could not detect any problems in the device itself, so we turned our focus to the mobile apps.

Here, too, everything looked pretty good: SSL Pinning was implemented, unlike in any other app we tested. Moreover, the Android app encrypts important data before saving it to its own folder.

The only problem we did detect was that the app for Android logs data that is transmitted to the server. This data can include the user’s password and login, as well as an authentication token.

Output of the Kippy Vita app with user login and password

Despite the fact that not all apps can read logs (only system apps or ones with superuser rights), it is still a major security issue.

Registered CVE:
CVE-2018-9916

Link AKC

This tracker monitors the pet’s location via GPS and transfers coordinates via the built-in SIM card. What’s more, it can interface with the owner’s phone directly — via Bluetooth LE. And this means that it is always ready to connect devices, which makes a good starting point for the study.

We were pleasantly surprised by Link AKC: the developers did everything right in terms of securing the connection to the smartphone. We couldn’t find any major problems, which is rare for devices with BLE support.

After the smartphone connects to the device and discovers services, it should enable notifications (that is, inform the tracker of expected changes) in two characteristics and a descriptor (otherwise the tracker breaks the link). After that Link AKC is ready to receive commands. They should contain the user ID; if the user does not have rights to use the tracker, the command is not executed. This maintains control over access rights. Even using the ID obtained from the tested device, we could not make the gadget execute a command from another smartphone—it appears that the tracker checks the smartphone’s MAC address.

However, the device cannot be described as completely secure. In the app for Android, we found that the developers had forgotten to disable logging. As a result, the app transfers lots of data to logcat, including:

• the app’s authorization token, which if intercepted can be used to sign into the service and discover the pet’s location:

• User registration data, including name and email address:

• Device coordinates:

Starting with Android 4.1, only some system apps or apps with superuser rights can read the logs of other programs. It is also possible to gain access when connecting the smartphone to a computer, but this requires Android developer mode to be activated.

Despite these restrictions, it is still a problem: attackers can get hold of data to access the victim’s account, even if the likelihood of this happening is small.

On top of that, the Android app does not verify the server’s HTTPS certificate, exposing it to man-in-the-middle (MITM) attacks. For a successful attack, attackers need only install their own certificate on the smartphone (which is quite simple to do), allowing them to intercept all transmitted data, including passwords and tokens used for account access:

The Link AKC app for Android is vulnerable to MITM attacks

The authorization token is also stored in unencrypted form in the app folder. Although superuser rights are needed to access it, it is still not the best place to store important data.

The authorization token is stored in unencrypted form

Registered CVE:
CVE-2018-7041

Nuzzle

In terms of functionality, Nuzzle is like the previous tracker: It too uses a SIM card to transmit the pet’s GPS coordinates and can directly connect to a smartphone via BLE. But on the latter point, Nuzzle performed less well than Link AKC: the lack of authorization and access control means that the device is ready to interface with any smartphone. This lets an attacker take control of the device, just like the owner. For example, it can quickly discharge the battery by turning on the light bulb (for which the value of just one attribute needs changing).

An attacker can receive data from the device as soon as a connection is made. Data is available in two characteristics: one contains telemetry information, including device location, while the other provides device status information (in particular, temperature and battery charge).

What is worse, the continuous reading of data from the telemetry characteristic results in the device being “lost”: to save battery power, the gadget does not transmit coordinates via the mobile network if they have already been sent via BLE. Thus, it is possible to conceal the location of the pet simply by connecting to the tracker using a smartphone.

We detected another security hole in the process of updating the device firmware. The integrity control was found to be easy to bypass. Basically, the firmware consists of two files with the extensions DAT and BIN. The first contains information about the firmware, including the checksum (CRC16) used in the integrity control, and the second contains the firmware itself. All it takes to install modified software on the tracker is to change the checksum in the DAT file.

AT commands in Nuzzle firmware

To cripple the device, we didn’t even need to analyze the firmware: it is not encrypted or packed, so just by opening it in a hex editor we were able to find the AT commands and the host used to send data by means of the SIM card. After we changed several bytes in the host, updated the firmware checksum, and uploaded it to the device, the tracker stopped working.

As in the case of Link AKC, the Nuzzle app for Android does not check the server certificate, and the authentication token and user email address are stored in the app folder in unencrypted form.

Unencrypted authorization token and user email address

Registered CVE:
CVE-2018-7043
CVE-2018-7042
CVE-2018-7045
CVE-2018-7044

TrackR

Two TrackR devices featured in our study: Bravo and Pixel. These “trinkets” differ from previous devices in that their tracking range (if indeed they are intended to track pets) is limited to 100 meters: unlike other models, they have no GPS module or SIM card, and the only link to them is via Bluetooth LE. Their main purpose is to locate keys, remote controls, etc. around the apartment. However, the developers have equipped the devices with an option that lets them partially track the movements of something: the trackers location can be  transmitted “via” the smartphones of other TrackR app users. If the app is running on the smartphone, it will transfer data to the service about all “trinkets” detected nearby, together with the smartphone coordinates. Therein lies the first defect: anyone can sign into the mobile app and send fake coordinates.

We managed to identify a few more problems, but as it turned out, most of them had already been discovered by our colleagues at Rapid7. Although their research was published more than a year ago, some vulnerabilities had yet to be fixed at the time of penning this article.

For instance, the devices have no authentication when connecting via Bluetooth LE, which means they are open to intruders. An attacker could easily connect and turn on the audio signal, for example, simply by changing the value of one characteristics. This could let an attacker find the animal before its owner does or run down the tracker battery.

Structure of TrackR services and attributes

Besides, the app for Android does not verify server certificates, meaning that an MITM attack could lead to the interception of the password, authentication token, user email address, and device coordinates.

TrackR Android app requests contain an authentication token

On the bright side, the app does not store the authentication token or password in their own folder, which is the proper way to guard against Trojans that use superuser rights to steal data.

Registered CVE:
CVE-2018-7040
CVE-2016-6541

Tractive

Unlike most devices we studied, this tracker does not communicate directly with the smartphone—only through its own servers. This approach is secure enough, but we detected some minor issues in the Android app. First, as in other cases, it does not verify the server certificate, which facilitates MITM attacks. What’s more, the app stores the authentication token in unencrypted form:

As well as pet movement data:

It should be noted that this data is not so easy to steal, since other apps cannot read it. But there are Trojans that can steal data from other apps by exploiting superuser rights.

Update from 31.05.2018:
After the publication of our research, the vendor contacted us and let us know that an updated app has been available from February this year. We checked the app and can confirm that the vendor has added SSL-pinning to their app making the MitM attack impossible. The unencrypted token issue is still in place in the updated version. We appreciate the vendor’s efforts in making its products more secure.

Weenect WE301

This is another tracker that doesn’t interface with the owner’s smartphone directly, but transfers pet coordinates to the server via a built-in SIM card. We didn’t encounter any security issues with this tracker, but problems similar to those in Tractive were detected in the Android version of the app.

First, it does not prevent MITM attacks, allowing attackers to access the user’s account or intercept geoinformation. Second, authentication data is stored in the app folder in unencrypted form, exposing it to Trojans with superuser rights on the device.

Whistle 3

This is one of the most technically interesting trackers in the study. It can transfer GPS coordinates via its built-in SIM card, via Wi-Fi to its server (if the owner provides a Wi-Fi network password), or directly to the owner’s smartphone via BLE.

We looked at Wi-Fi first of all and found that the developers had taken care to secure the connection: The device transmits small portions of data over HTTPS (that is, in encrypted form).

Wi-Fi data transfer is secured using HTTPS

Next, we checked the BLE connection and found many security issues. The first is the lack of proper authentication. After connecting, the device waits for a certain sequence of actions to be performed, which could be described as pre-authentication. The sequence is so simple that a third party can easily reproduce it. All it takes is to connect to the device, transfer two characteristics to WRITE_TYPE_NO_RESPONSE mode, request a change in the size of transmitted data (MTU), turn on notifications for one characteristics, and transfer a certain number to another characteristics.

Now the tracker is ready to receive and execute commands that do not contain a user ID, which means that anyone can send them. For example, it is possible to send an initiateSession command, and in response the device will send an unencrypted set of data, including the device coordinates. What’s more, if this command is continuously transmitted, the gadget will not send location data via the SIM card, since it will assume that such data has already been received “directly.” Thus, it is possible to “hide” the tracker from its owner.

There is one more problem: the tracker transmits data to the server without any authentication. This means that anyone can substitute it, altering the coordinates in the process.

The app transmits data received from the tracker via BLE

The Android app uses the HTTPS protocol (which is good), but does not verify the server certificate.

MITM attacks can intercept user data

Not only that, the smartphone app stores user data in unencrypted form in its own folder, exposing it to theft by a Trojan with superuser rights. However, authentication data is stored correctly.

Tracker coordinates from the app database

Note that the Android app writes data to logcat. As mentioned above, despite the fact that other app logs can read only some system utilities or apps with superuser rights, there is no need to write important data to the log.

The Android app can log user and pet data (activity, email address, name, owner’s phone number), as well as one of the used tokens

Registered CVE:
CVE-2018-8760
CVE-2018-8757
CVE-2018-8759
CVE-2018-9917

Conclusions

GPS trackers have long been applied successfully in many areas, but using them to track the location of pets is a step beyond their traditional scope of application for this, they need to be upgraded with new “user communication interfaces” and “trained” to work with cloud services, etc. If security is not properly addressed, user data becomes accessible to intruders, endangering both users and pets.

Research results: four trackers use Bluetooth LE technology to communicate with the owner’s smartphone, but only one does so correctly. The rest can receive and execute commands from anyone. Moreover, they can be disabled or hidden from the owner—all that’s required is proximity to the tracker.

Just one of the tested Android apps verifies the certificate of its server, without relying solely on the system. As a result, they are vulnerable to MITM attacks—intruders can intercept transmitted data by “persuading” victims to install their certificate.

There can never be too many IoT gadgets – that’s what people usually think when buying yet another connected device with advanced functionality. From our perspective, we also think there can’t be too many IoT investigations. So, we have continued our experiments into checking and uncovering how vulnerable they are, and followed up our research focusing on smart home devices.

Researchers have already been analyzing connected devices for many years, but concerns around cybersecurity in the IoT world are still there, putting users under significant risk. In our previous analysis, possible attack vectors affecting both a device and a network to which it’s connected have been discovered. This time, we’ve chosen a smart hub designed to control sensors and devices installed at home. It can be used for different purposes, such as energy and water management, monitoring and even security systems.

This tiny box receives information from all the devices connected to it, and if something happens or goes wrong, it immediately notifies its user via phone, SMS or email in accordance with its preferences. An interesting thing is that it is also possible to connect the hub to local emergency services, thus alerts will be sent to them accordingly. So, what if someone was able to interrupt this smart home’s system and gain control over home controllers? It could turn life into a nightmare not only for its user, but also for the emergency services. We decided to check a hypothesis and as a result discovered logical vulnerabilities providing cybercriminals with several attack vectors opportunities.

Physical access

First, we decided to check what could be available for exploitation by an attacker being outside of the network. We discovered that the hub’s firmware is available publicly and can be downloaded without any subscription from the vendor’s servers. Therefore, once downloading it, anyone can easily revise the files inside it and analyze them.

We found that the password from the root account in the shadow file is encrypted with the Data Encryption Standard (DES) algorithm. As practice shows, this cryptographic algorithm is not considered to be secure or highly resistant to hacking, and therefore it is possible for an attacker to successfully obtain the hash through brute-force and find out the ‘root’ password.

To access the hub with ‘root’ rights and therefore modify files or execute different commands, physical access is needed. However, we don’t neglect the hardware hacking of devices and not all of them survive afterwards.

We explored the device physically, but of course not everyone would be able to do this. However, our further analysis showed there are other options to gain remote access over it.

Remote access

For hub control, users can either use a special mobile application or a web-portal through which they can set up a personal configuration and check all the connected systems.

To implement it, the owner sends a command for synchronization with the hub. At that moment, all settings are packed in the config.jar file, which the hub then downloads and implements.

But as we can see, the config.jar file is sent through HTTP and the device’s serial number is used as the device identifier. So, hackers can send the same request with an arbitrary serial number, and download an archive.

Some might think that serial numbers are very unique, but developers prove otherwise: serial numbers are not very well protected and can be brute-forced with a byte selection approach. To check the serial number, remote attackers can send a specially crafted request, and depending on the server’s reply, will receive information if the device is already registered in the system.

Moreover, our initial research has shown that users, without even realizing it, put themselves at risk by publishing their tech reviews online or posting photos of a hub in social networks and openly presenting devices’ serial numbers. And the security consequences will not be long in coming.

While analyzing the config.jar file archive, we found that it contains login and password details – all the necessary data to access a user’s account through the web-interface. Although the password is encrypted in the archive, it can be broken by hash decryption with the help of publicly available tools and open-sourced password databases. Importantly, during the initial registration of a user account in the system, there are no password complexity requirements (length, special characters, etc.). This makes password extraction easier.

As a result, we gained access to a user’s smart home with all the settings and sensor information being available for any changes and manipulations. The IP address is also listed there.

It is also possible that there might be other personal sensitive information in the archive, given the fact that users often upload their phone numbers into the system to receive alerts and notifications.

Thus, the few steps involved with generating and sending the right requests to the server can provide remote attackers with the possibility of downloading data to access the user’s web interface account, which doesn’t have any additional security layers, such as 2FA (Two Factor Authentication). As a result, attackers can take control over someone’s home and turn off the lights or water, or, even worse, open the doors. So, one day, someone’s smart life could be turned into a complete nightmare. We reported all the information about the discovered vulnerabilities to the vendor, which are now being fixed.

But there is always light at the end of the tunnel…

In addition to smart “boxes”, we had something smaller in our pocket – a smart light bulb, which doesn’t have any critical use, neither for safety or security. However, it also surprised us with a few – but still worrying – security issues.

The smart bulb is connected to a Wi-Fi network and controlled over a mobile application. To set it up a user needs to first download the mobile application (iOS or Android), switch on the bulb, connect to the Wi-Fi access point created by the bulb and provide the bulb with the SSID and password from a local Wi-Fi network.

From the application, users can switch it ON and OFF, set timers and change different aspect of the light, including its density and color. Our goal was to find out if the device might help an attacker in any way to gain access to a local network, from which it would eventually be possible to conduct an attack.

After several attempts, we were lucky to discover a way to get to the device’s firmware through the mobile application. An interesting fact is that the bulb does not interact with the mobile application directly. Instead, both the bulb and the mobile application are connected to a cloud service and communication goes through it. This explains why while sniffing the local network traffic, almost no interaction between the two were found.

We discovered that the bulb requests a firmware update from the server and downloads it through an HTTP protocol that doesn’t secure the communication with servers. If an attacker is in the same network, a man-in-the-middle kind of attack will be an easy task.

The hardware reconnaissance with flash dumping led us not only to the firmware, but to user data as well. With a quick look at the information shared with the cloud, no sensitive information seems to have been uploaded from the device or the internal network. But we found all the credentials of the Wi-Fi networks to which the bulb had connected before, which are stored in the device’s flash forever with no encryption – even after a “hard” reset of the device this data was still available. Thus, reselling it on online market places is certainly not a good idea.

Get ready

Our latest research has once again confirmed that ‘smart home’ doesn’t mean ‘secure home’. Several logical vulnerabilities (combined with an unconsciously published serial number) can literally open doors to your home and welcome in cybercriminals. Besides this, remote access and control over your smart hub can lead to a wide range of sabotage activities, which could cost you through high electricity bills, a flood or, even more importantly, your mental health.

But even if your smart hub is secure, never forget that the devil is in the details: a tiny thing such as a light bulb could serve as an entry-point for hackers as well, providing them with access to a local network.

That’s why it’s highly important for users to follow these simple cyber hygiene rules:

• Always change the default password. Instead use a strict and complex one. Don’t forget to update it regularly.
• Don’t share serial numbers, IP addresses and other sensitive information regarding your smart devices on social networks
• Be aware and always check the latest information on discovered IoT vulnerabilities.

No less important is that vendors should improve and enhance their security approach to ensure their devices are adequately protected and, as a result, their users. In addition to a cybersecurity check, which is just as vital as testing other features before releasing a product, it is necessary to follow IoT cybersecurity standards. Kaspersky Lab has recently contributed to the ITU-T (International Telecommunication Union — Telecommunication sector) Recommendation, created to help maintain the proper protection of IoT systems, including smart cities, wearable and standalone medical devices and many others.