A bowl full of security problems: Examining the vulnerabilities of smart pet feeders

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