IoT systems, in general, are rarely designed with security in mind whilst they are getting more and more attention from regulatory bodies requiring security to be implemented in such devices. To assess if the industry is getting ready for the upcoming required increase of security level, we also evaluate smart devices’ readiness for ETSI EN 303 645 V2.1.1 requirements.
Available information and interfaces
We usually start a lightweight security assessment by information gathering. This is done using public documentation as well as by extracting firmware and reverse engineering the device and firmware. The publicly available documentation, such as user manuals for the device and datasheets for components as well as FCC documentation, gave us an idea of how the device looked internally. We also downloaded the update images that we found online. Since the update images we found were encrypted, the next step in the information gathering stage is usually extraction of the firmware. Before extracting the firmware by de-soldering the flash chip, we usually go over standard interfaces to see if they are properly closed and/or secured or if there is an easier way to interact with the device.
First, we connected the device to a monitoring box to perform network scanning, packet-sniffing, and MITM attacks. The first good security decision we noticed by scanning WAN ports was that all of them were closed. IoT devices are primarily compromised from exposure to unnecessary services over the Internet.
LAN interface had a few ports opened as the device needs to be configured. The web interface of the TOE is active on both HTTP and HTTPS ports, however, it mostly defaults to HTTP. Note that it is quite difficult to securely implement HTTPS on IoT devices, as the developer needs to allow either the use of a self-signed certificate or a CA-signed certificate. This introduces another asset that the device needs to protect properly.
For an authenticated user of this device, we identified a command injection vulnerability in the hostname field under the Settings -> Network section of the web interface. We then intercepted the HNAP1 request through Chrome’s developer tools and replayed the request using curl with a malicious payload. The payload was placed in the DeviceName field within the HNAP1 request. The hostname field was passed to the llnmrd (llnmr daemon) and was executed as a part of a command, leading to code execution (as root) on the device. We were able to leverage wget and python installed on the system to upgrade to a stable shell.
Using the root shell, we can see that most services on the device run as root. This means that any vulnerability present in any of the roots could lead to the highest privileged access to the device and the secrets it protects.
This illustrates the importance of protecting even authenticated LAN interfaces in order to prevent information gathering and vulnerability finding. As we see, an encrypted update image is usually not enough.
Looking into the device
Without update images in plaintext or an easily found vulnerability through the Ethernet interface, an attacker would go further with reviewing other exposed interfaces such as USB or simply opening one of the devices looking for debug ports. The most interesting aspect of opening a device are debug ports used by developers to install and configure the device.
UART port is easily identified by the distinctive 4 pin header at J4. After connecting to the UART port with a USB to Serial adapter, we were able to identify that the TOE uses a modified U-Boot image as the bootloader. The U-Boot prompt provided additional information on the TOE, including firmware layout and kernel boot parameters.
We were able to halt the boot process and modify the device’s U-Boot environment parameters to boot into Linux’s single-user mode, resulting in root shell access to the device.
However, the filesystem loaded after the initial boot is a read-only filesystem. We remounted the filesystem by using the preinit-aldk script that was called by the preinit binary. We also created a python script to download binaries from the filesystem through the UART port to a host computer. This allowed us to reverse engineer various binaries and configuration parameters. A GPL package was also available from the OEM that was helpful in the reverse engineering efforts.
An important security issue of embedded devices that we see repeatedly is the old versions of the library as well as the Linux kernel version (3.10.104 from 2016). The old software contains vulnerabilities and kernel vulnerabilities that could lead to privilege escalation if not patched separately.
We also obtained several files from the filesystem using the single-user mode. One of the files obtained this way was the ramdisk_copy/etc/passwd file, which appears to be mapped to the /etc/passwd file via a symbolic link when the device boots normally. The /etc/passwd file contains two users, one of which was the root user. The passwd file contains salted MD5crypt hashes. We attempted to crack the password hashes using both dictionary and bruteforce attempts.
Additionally, we also tried to create custom dictionaries based on the filesystem using the bulk_extractor forensic tool. The root password appears to be the same across devices. With the lightweight analysis and limited time, we were unable to crack the passwords. However, an attacker with sufficient resources can potentially crack this password and have local root access to other devices as the password is the same.
The passwd file obtained through the single-user mode also showed a second user: 9ti2ce8fxfa452mb. A user with a randomly generated name and root privileges is a concerning finding because it is unclear how this account can be used, especially as it can control the device.
The firmware contains various binaries that appear to be from McAfee and is in use for McAfee Secure Home Platform functionality. As we explored different attack paths, we did not have sufficient time to dive deeper into the security-oriented functionalities.
Some of the firmware binaries are from another connected device manufacturer, Arcadyan Technology Corporation. The most interesting scripts within this binary were related to the Trusted Platform Module (TPM) utils (arc_tpm_utils). The TPM is used to authenticate and decrypt update binaries. The arc_tpm_utils binary is called by the arc_check_fw script and outputs public certificates and passwords stored within the TPM. We didn’t find any authentication between the firmware and the TPM, but we could extract the update encryption password via the command injection vulnerability. This means that encrypted images from the Internet can be decrypted now.
Conclusion and future work
This blog post showed the process of a lightweight analysis of an IoT device, as a result of which we found several issues. We did not have sufficient time to go deeper on some topics that attracted our attention, leaving this blog with a little bit of anticipation.
Still, our limited findings show that getting root access on such a device is not difficult, but it might be challenging for a remote attacker to access the router over the WAN interface. It might be that the vendor made such security design decisions due to the assumed attacker model of a remote attacker. While this approach makes a lot of sense with the MIRAI botnet in mind, it does not fully satisfy the upcoming regulations on the EU level with security requirements for consumer devices.
Some of the security requirements listed ETSI EN 303 645 that this device does not comply with include:
- Secure storage of sensitive data
- Hardware protection of device access
- SW privilege level reduced to necessary instead of highs root access.
For more information on the ETSI EN 303 645 and the status of embedded devices in the market, check out our whitepaper State of security for smart home devices.
As part of Riscure’s responsible disclosure policy, Riscure researchers team has reached out to the device manufacturer (using firstname.lastname@example.org contact address) with an indication that several improvement points were identified in the DIR2680 device as part of Riscure’s internal research activities. However, no response to the shared information has been received from the vendor company.
If you have any questions, feel free to contact us at email@example.com.