How I Got root on a Thermostat

Last Updated on March 16, 2023

When evaluating IoT device security from an attacker’s perspective, the goal is to obtain the highest level of permissions on the device. Most complex IoT devices run an operating system (OS) that manages the hardware and hosts system level software. Typically, the OS is Linux, whose highest-level administrative user is called root. Thus, the attacker is after root user access by some means.

A hardware hacker’s approach to IoT security

Our assessment of the thermostat began with physically inspecting it from the outside, then moving inside. First we examined the exterior for any data exchange interfaces. Finding none, we removed the case to expose the interior electronics.

From there, we started by researching all the chips on the circuit board to determine what they do and what they could contain. We also probed connectors, test points, and solder pads for electrical signals. Examining the chips and signals gives more detail into the device’s operation, particularly if any of these signals are debug interfaces.

One such debug interface is called serial debug, which, during the device power up, prints out information about the device and power-up process (boot log). We found three points on the thermostat circuit board that could have been serial debug interfaces. We connected a logic analyzer to these points to capture and interpret the electrical signals into human-readable text. Of the three interfaces probed, only one was outputting a boot log. While reading the boot log, we discovered the thermostat’s WiFi access point (AP) name and password. The AP password was not disclosed in any product literature or stickers on the device. This secret was not meant to be made public, but by examining the hardware, we could find it.

Pivoting from hardware to software

From the hardware, we pivoted to software. We joined the device’s wireless AP and then performed a network scan for available services. We saw the thermostat was hosting a webserver and pointed a web browser at it. The browser loaded an administrative web portal with simple settings and network test functionality. From here, we started attacking the input fields on the admin portal. The web server returned validation errors for two of the input fields, but one other input field seemed to be accepting our malicious input.

While we were testing the webserver, we still had our analyzer connected to the serial debug interface and saw error messages show up. The network test function on the website was showing error messages on the serial debug interface when we inserted a bad hostname to connect to for the network test. What appeared to be happening was that an OS command was directly acting on our supplied input, and its errors would show up in the serial debug interface. Thus, we could use a web browser to construct attacks and the serial debug interface to see if our attacks were working.

From the serial debug interface, we knew the device was running Linux. Linux has a special program called a shell that lets users type in commands for the OS to execute. The shell assigns special meaning to characters like the semicolon, which you can use to put multiple commands on one line to run at once. We constructed a simple command injection test by setting the hostname from the network test to be “;id;echo $SHELL;”.  The semicolons separated the legitimate shell command into two parts, and let us insert our own shell commands “id” and “echo $SHELL” between the two halves of the original command. The commands “id” and “echo $SHELL” would tell us what user is running in the shell and software shell the OS is using. With our command injection in the hostname field, we clicked “run test” and got the output of our two commands to show up in the serial debug interface. We now had a successful command injection, and the command results tell us we are the sought-after root user.

Total device compromise, no password required

We issued more Linux shell commands via our command injection in the hostname field to explore the underlying Linux system. We discovered root had no password, and the remote access shell “dropbear” was installed on the device. Dropbear is a remote access shell server. Anyone with device network access can connect to the dropbear server and have shell access to the device to issue commands. Usually, the login process requires knowing a password or secret key. But the device did not have a password set for root, and dropbear allows login without a password if the corresponding option is selected. So, we constructed a command injection to run dropbear to enable root login without a password.

The benefit of accessing the device via remote shell is that it frees us from being physically tied to the device for command output. Previously, we used the serial debug interface to get results from our command injection. Now all we had to do was stay connected to the device’s WiFi AP and login to the dropbear remote shell. We sent the dropbear remote shell command injection, then pointed our remote shell client program at the dropbear server and successfully connected to the thermostat with a root shell.

At that point, we had complete control and, from an IoT security standpoint, we had thoroughly compromised the device.

Post mortem

As is often the case, the overall process to compromise IoT device security resulted from a series of vulnerabilities that, when strung together, created a viable path to exploitation:

1. First, the thermostat had an active hardware debug interface, giving away the AP password.
2. Second, the device’s administrative portal was not password protected.
3. Third, the portal did not validate input on the network test function and thus was vulnerable to command injection.
4. Fourth, the Linux system was configured to run the network test command as root, which meant injected commands would also run as root.
5. Fifth, there was no password set for root, and coupled with dropbear allowing passwordless login, root can log in unhindered.

Each of these five IoT device security vulnerabilities was a step in developing a kill chain to attack and exploit the thermostat. Once we had the AP password, we could access the admin portal. From the admin portal, we found a command injection weakness. From command injection, we learned about system configuration. From system configuration knowledge, we made a remote shell injection command. From the remote shell, we got root on the device and exploited it.

Killing the kill chain

Protecting the thermostat from the kill chain is as simple as breaking one link in the chain. But a more robust solution addresses each issue found. From the beginning, hardware debug interfaces need to be disabled or contain minimal information that would not help an attacker. Passwords are required to protect administrative portals from being accessed at will. The backend portal software should validate all user input before the OS or other programs use it. Configure programs to run with the minimal amount of privilege necessary, so if they are exploited an attacker would not be granted root level privilege by default. We got remote shell access because root had no password and dropbear allows for no password logins. A strong, unique root password is key to IoT device security.

What’s Next?

There you have it. Compromising IoT cybersecurity resulted from a series of steps that started with investigating hardware and ended with trying web-based attacks. The major takeaway is that IoT security challenges take a multi-layered approach and all aspects of a product need to be considered. Another takeaway is that even then it’s a challenge to thwart determined, skilled hackers who have physical access to an example of the specific IoT device they want to attack.

If you’d benefit from specific guidance on IoT device security, or want to know how secure an IoT device is before you deploy it, contact Pivot Point Security to connect with an IoT security expert.