In the spring, we decided to have a look at the state of security in routers for home users. In this series of blogposts we will detail the findings we made when zooming in on the YouSee/TDC HomeBox. The issues we found were communicated to YouSee/TDC, who quickly started a process with the supplier of the device to patch the firmware. All affected devices should be patched at the time of writing.
Most private Internet subscriptions include a CPE (Customer-Premises Equipment) device, located at the user's home and acting as the gateway between the home network and the Internet. Usually, such devices come with additional functionality, like DHCP and WiFi, allowing them to function as the primary router in a household. The YouSee/TDC HomeBox is one such device. It is one of their primary CPE's for xDSL and fiber subscriptions, and as such, a very common sight in Danish homes. This makes it an interesting target for attackers.
The HomeBox is a customized version of the Sagemcom [email protected] 5345 router. A bit of googling revealed that this box is also supplied by other ISPs across the world. As it is not entirely clear how much Sagemcom customizes these devices for their ISP customers, I cannot verify whether the found vulnerabilities exist on other devices beside the HomeBox. The vulnerabilities might also exist in other Sagemcom products if they share the same code base.
As the firmware for the device is not available online (aside from some open source components), in this first post about the HomeBox, I will go through the steps I took to extract the firmware from the device itself.
Since one of the easiest options for extracting firmware is utilizing built-in serial ports if present, this was my first attack vector. A nice guide to this process can be found here.
The following image shows the layout of the opened HomeBox:
Using a multimeter to test some of the interesting candidates for a serial port, I found a very likely option:
On my multimeter, the suspected TX port gave steady high voltage readings, instead of the expected average reading. Adding an oscilloscope showed a square wave form, and I assumed that it was the port I was looking for. I had to desolder the port first, before I could then solder on a header on which to attach my wires. The ground hole gave me some problems, and I used a clip to attach ground to another grounded component on the board. The image below shows the USB-to-UART cable plugged in to the board.
Having this set up, I tested a few UART combinations, and the port proved to be using the very common settings of 8 data bits, no parity bits, 1 stop bit and a baud rate of 115200. Rebooting the device showed readable terminal output, and I could monitor the boot process.
At the final step in the boot process, a Linux kernel was loaded and I was presented with a login prompt.
I had no luck when trying to log in with the router's Admin user and the provided password (or some other common passwords),
so I had no way to access the running Linux system. Instead, I chose to utilize the option during boot to stop the process in the
U-boot environment. U-boot is a widely used open source bootloader which also provides a command line interface.
Using the command
mtdparts, I got an overview of how the flash memory is partitioned.
The partAll partition looked like the one I wanted to access. U-boot has a command called
md for viewing memory.
However, to be able to read the data, I needed to copy it from the flash memory to RAM. This was done with the
nand read command:
I could then read arbitrary bytes from the copy in memory:
The full partition was about 128 megabytes in size. I had to be patient to dump it as hex-encoded bytes through the 115200 bit serial connection. Every byte took around three bytes to transfer, as it was displayed as hex with every line containing address info and spaces. The entire transfer took around 17 hours. As errors were sometimes introduced in this process, I used the following command to find any faulty lines and fixed them up by manually dumping the missing data and pasting it in.
awk 'length!=66' hexdump.log
Now I had to revert the hex-representation to its proper representation again. This could be done in various ways. I chose to use this script with some minor modifications.
After this, the raw data partition was available. Using binwalk gave the following output:
Binwalk showed that I was probably dealing with UBI formatted volumes - but is not helpful in extracting the volumes. Instead, I used these scripts to extract the volumes:
Using binwalk on the resulting files gives me this output on the “operational” volume:
The squashfs filesystem looked promising, and I used binwalk to carve and mount it:
We now had access to the filesystem on the Homebox. In the following posts, I will go through the bugs we found with this access.