Introduction

FireEye’s Mandiant Red Team recently discovered vulnerabilities present on the Logitech Harmony Hub Internet of Things (IoT) device that could potentially be exploited, resulting in root access to the device via SSH. The Harmony Hub is a home control system designed to connect to and control a variety of devices in the user’s home. Exploitation of these vulnerabilities from the local network could allow an attacker to control the devices linked to the Hub as well as use the Hub as an execution space to attack other devices on the local network. As the Harmony Hub device list includes support for devices such as smart locks, smart thermostats as well as other smart home devices, these vulnerabilities present a very high risk to the users.

FireEye disclosed these vulnerabilities to Logitech in January 2018. Logitech was receptive and has coordinated with FireEye to release this blog post in conjunction with a firmware update (4.15.96) to address these findings.

The Red Team discovered the following vulnerabilities:

• Improper certificate validation
• Insecure update process
• Developer debugging symbols left in the production firmware image
• Blank root user password

The Red Team used a combination of the vulnerabilities to gain administrative access to the Harmony Hub. This blog post outlines the discovery and analysis process, and demonstrates the necessity of rigorous security testing of consumer devices – particularly as the public places an increasing amount of trust in devices that are not just connected to home networks, but also give access to many details about the daily lives of their users.

Device Analysis

Device Preparation

Publicly available research indicated the presence of a universal asynchronous receiver/transmitter (UART) interface on some of the test points on the Harmony Hub. We soldered jumper wires to the test pads, which allowed us to connect to the Harmony Hub using a TTL to USB serial cable. Initial analysis of the boot process showed that the Harmony Hub booted via U-Boot 1.1.4 and ran a Linux kernel (Figure 1).

After this point in the boot process, the console stopped returning output because the kernel was not configured with any console interfaces. We reconfigured the kernel boot parameters in U-Boot to inspect the full boot process, but no useful information was recovered. Furthermore, because the UART interface was configured to only transmit, no further interaction could be performed with the Harmony Hub on this interface. Therefore, we shifted our focus to gaining a better understanding of the Linux operating system and associated software running on the Harmony Hub.

Firmware Recovery and Extraction

The Harmony Hub is designed to pair with a companion Android or iOS application over Bluetooth for its initial configuration. We created a wireless network with hostapd and installed a Burp Suite Pro CA certificate on a test Android device to intercept traffic sent by the Harmony mobile application to the Internet and to the Harmony Hub. Once initial pairing is complete, the Harmony application searches for Harmony Hubs on the local network and communicates with the Harmony Hub over an HTTP-based API.

Once connected, the Harmony application sends two different requests to Harmony Hub’s API, which cause the Harmony Hub to check for updates (Figure 2).

The Harmony Hub sends its current firmware version to a Logitech server to determine if an update is available (Figure 3). If an update is available, the Logitech server sends a response containing a URL for the new firmware version (Figure 4). Despite using a self-signed certificate to intercept the HTTPS traffic sent by the Harmony Hub, we were able to observe this process – demonstrating that the Harmony Hub ignores invalid SSL certificates.

We retrieved this firmware and examined the file. After extracting a few layers of archives, the firmware can be found in the harmony-image.squashfs file. This filesystem image is a SquashFS filesystem compressed with lzma, a common format for embedded devices. However, vendors often use old versions of squashfstools that are incompatible with more recent squashfstools builds. We used the unsqashfs_all.sh script included in firmware-mod-kit to automate the process of finding the correct version of unsquashfs to extract the filesystem image (Figure 5).

With the filesystem contents extracted, we investigated some of the configuration details of the Harmony Hub’s operating system. Inspection revealed that various debug details were available in the production image, such as kernel modules that were not stripped (Figure 6).

Investigation of /etc/passwd showed that the root user had no password configured (Figure 7). Therefore, if we can enable the dropbear SSH server, we can gain root access to the Harmony Hub through SSH without a password.

We observed that an instance of a dropbear SSH server will be enabled during initialization if the file /etc/tdeenable is present in the filesystem (Figure 8).

Hijacking Update Process

During the initialization process, the Harmony Hub queries the GetJson2Uris endpoint on the Logitech API to obtain a list of URLs to use for various processes (Figure 9), such as the URL to use when checking for updated firmware or a URL to obtain information about updates’ additional software packages.

We intercepted and modified the JSON object in the response from the server to point the GetUpdates member to our own IP address, as shown in Figure 10.

Similar to the firmware update process, the Harmony Hub sends a POST request to the endpoint specified by GetUpdates containing the current versions of its internal software packages. The request shown in Figure 11 contains a sample request for the HEOS package.

If the sysBuild parameter in the POST request body does not match the current version known by the server, the server responds with an initial response containing information about the new package version. For an undetermined reason, the Harmony Hub ignores this initial response and sends a second request. The second response contains multiple URLs pointing to the updated package, as shown in Figure 12.

We downloaded and inspected the .pkg files listed in the response object, which are actually just ZIP archives. The archives contain a simple file hierarchy, as shown in Figure 13.

The manifest.json file contains information used to instruct the Harmony Hub’s update process on how to handle the archive’s contents (Figure 14).

The Harmony Hub’s update process executes the script provided by the installer parameter of the manifest if it is present within the archive. We modified this script, as shown in Figure 15, to create the /etc/tdeenable file, which causes the boot process to enable the SSH interface as previously described.

We created a new malicious archive with the appropriate .pkg extension, which was hosted on a local web server. The next time the Harmony Hub checked for updates against the URL supplied in the modified GetJson2URIs response, we sent a modified response to point to this update. The Harmony Hub retrieved our malicious update package, and after rebooting the Harmony Hub, the SSH interface was enabled. This allowed us to access the device with the username root and a blank password, as shown in Figure 16.

Conclusion

As technology becomes further embedded into our daily lives, the trust we place in various devices unknowingly increases exponentially. Due to the fact that the Harmony Hub, like many IoT devcies, uses a common processor architecture, malicious tools could easily be added to a compromised Harmony Hub, increasing the overall impact of a targeted attack. However, Logitech worked with our team to quickly address the vulnerabilities with their current firmware, 4.15.96. Developers of the devices we place our trust should be vigilant when removing potential attack vectors that could expose end users to security risks. We also want to share Logitech’s statement on the research and work by the Red Team:

"At Logitech, we take our customers’ security and privacy very seriously. In late January 2018, security research firm FireEye pointed out vulnerabilities that could impact Logitech Harmony Hub-based products*.

If a malicious hacker had already gained access to a Hub-users network, these vulnerabilities could be exploited. We appreciate the work that professional security research firms like FireEye provide when identifying these types of vulnerabilities on IoT devices.

As soon as FireEye shared their research findings with us, we reviewed internally and immediately started to develop firmware to address it. As of April 10, we have released firmware that addresses all of the vulnerabilities that were identified. For any customers who haven’t yet updated to firmware version 4.15.96, we recommend you check the MyHarmony software and sync your Hub-based remote and receive it. Complete directions on updating your firmware can be found here.

*Hub-based products include: Harmony Elite, Harmony Home Hub, Harmony Ultimate Hub, harmony Hub, Harmony Home Control, Harmony Pro, Harmony Smart Control, Harmony Companion, Harmony Smart Keyboard, Harmony Ultimate and Ultimate Home."