Reading time: 5 subtlety
Last updated on January 27, 2022
When evaluating the security of IoT devices from the point of view of validity, the goal is to achieve the highest level of privileges in the device. Most complex IoT devices run an operating system (OS) that manages the hardware and hosts system-level software. Typically, the operating system is Linux, whose top-level administrative user is called root. Thus, the attacker seeks root user access by certain means.
The process of gaining root user access is “root acquisition”. Once an attacker takes root in the device, all confidentiality, completeness and availability are lost. The way to get a root can vary from device to device. The following step-by-step example that explains how we attacked a thermostat illustrates one of many ways in which a series of design and security flaws can lead to root access and IoT device security breaches.
A hacker hardware access to IoT security
Our assessment of the thermostat began with its physical examination from the outside, then moved inward. We first examined the external appearance for all data exchange interfaces. When we did not find it, we removed the bag to reveal the internal electronics.
From there, we started researching all the chips on the circuit to determine what they do and what they can hold. We also tested connectors, test points and solder pads for electrical signals. Examining the chips and signals provides additional details about the operation of the device, especially if each of these signals is debugging interfaces.
One such debugging interface is called serial debugging, which during operation of the device, prints information about the device and the activation process (boot log). We found three points in the thermostat circuit that could have been serial bug debugging interfaces. We have connected a logical analyzer to these points to capture and interpret the electrical signals into human-readable text. Of the three interfaces tested, only one issued a boot log. While reading the boot log, we discovered the name and password of the thermostat’s WiFi access point (AP). The AP password has not been revealed in the product literature or on the stickers on the device. This secret was not meant to be published, but by checking the hardware, we were able to find it.
Moving from hardware to software
From the hardware, we moved to the software. We joined the device’s wireless AP and then performed a network scan for available services. We saw that the thermostat was hosting a web server and referred it to a web browser. The browser has loaded an administrative web portal with simple settings and functionality of network testing. From here, we started attacking the input fields in the management portal. The web server returned authentication errors for two of the input fields, but one other input field appeared to be receiving our malicious input.
While we were checking the web server, we still had the surgeon connected to the serial debugging interface and we saw error messages appear. The network test function on the site displayed error messages in the serial debugging interface when we put in a bad host name to connect to for network testing. What seemed to be happening was that the operating system command acted directly on our input provided, and its errors would appear in the serial debugging interface. Thus, we can use a web browser to build attacks and a serial debug interface to see if our attacks work.
From the serial debugging interface, we knew that the device runs on Linux. Linux has a special program called a shell that allows users to type commands to run the operating system. The shell assigns special meaning to characters like a semicolon, which you can use to put multiple commands in one line to run at once. We built a command injection test simply by setting the host name from the network test to be “; id; echo $ SHELL;”. A semicolon 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 “id” and “echo $ SHELL” commands will tell us which user is running the shell and the software shell used by the operating system. Upon injecting our commands in the host name field, we clicked “Run Test” and got the output of our two commands to appear in the serial debugging interface. We now had a successful command injection, and the command results tell us that we are using the requested root.
Complete damage to the device, no password required
We generated more Linux shell commands by injecting our commands in the host name field to explore the basic Linux system. We found root has no password, and the “dropbear” remote access shell was installed on the device. Dropbear is a remote access shell server. Anyone who has access to the device network can connect to the dropbear server and get shell access to the device to issue commands. Typically, the login process requires knowing a password or secret key. But the device does not have a password set to root, and dropbear allows login without a password if the appropriate option is selected. So we built an injection injection to activate dropbear to allow root entry without a password.
The advantage of accessing the device through a remote shell is that it frees us from being physically connected to the device for command output. In the past, we used a serial debugging interface to get results from our command injection. Now all we had to do was stay connected to the device’s WiFi AP and log into the dropbear remote control shell. We sent the dropbear remote shell command injection, then diverted our remote shell client program to the Dropbear server and successfully connected to the root shell thermostat.
At this point, we had complete control and in terms of IoT security, we thoroughly compromised on the device.
After death
As is often the case, the overall process of compromising the security of IoT devices stemmed from a series of vulnerabilities that, when connected together, created a viable path to exploitation:
- First, the thermostat had a hardware-active debugging interface that provided the AP password.
- Second, the device’s administrative portal was not password protected.
- Third, the portal did not validate input in the network test function and was therefore exposed to command injection.
- Fourth, the Linux system is set to run the network test command as root, which means that the injected commands will also run as root.
- Fifth, no password has been set for root, and in combination with dropbear that allows password-free login, root can log in without interruption.
Each of the five security breaches of IoT devices were a step in the development of a killing chain to attack and exploit the thermostat. Once we have the AP password, we can access the management portal. From the management portal we found a weakness in command injection. From injecting commands we learned about the system configuration. Out of knowledge of the system configuration, we made a remote shell injection order. From the government envelope, we got to the root on the device and took advantage of it.
Kill the killing chain
Protecting the thermostat from the dead chain is as simple as breaking one link in the chain. But a stronger solution addresses any problem found. From the beginning, hardware debugging interfaces should be disabled or contain minimal information that will not help validity. Passwords are required to protect administrative portals from access as desired. Rear-end portal software should verify all user input before using the operating system or other programs. Set programs to run with the minimum amount of permissions required so that if they are utilized, validity will not receive base level permissions by default. We were given access to the remote shell because Root did not have a password and Dropbear does not allow password logins. A strong and unique root password is the key to securing IoT devices.
What next?
there you are. Compromising on IoT cyber security stemmed from a series of steps that began with a hardware investigation and ended with an attempt at Internet-based attacks. The main solution is that IoT security challenges take a multi-layered approach and all aspects of the product must be taken into account. Another way is that even then it is a challenge to thwart determined and skilled hackers who have physical access to the sample of the specific IoT device they want to attack.
If you enjoy specific training on IoT device security, or would like to know how secure your IoT device is before deploying it, contact Pivot Point Security to contact an IoT security specialist.
