The Trendnet TS-S402 is a discontinued network storage enclosure that was sold to individuals for personal data storage. Like every Internet-of-Things (IoT) device, it runs on software programmed and/or configured by the manufacturer before shipping it to the end-user, i.e. the firmware. Firmware versions 2.00.10 and below of this particular device have a serious vulnerability allowing remote root access. This target thus provides an excellent exercise for reverse engineering while providing an example of a vulnerability that is unfortunately way too common in IoT: backdoors by design. In this post, we will introduce Binwalk and provide the background necessary to do the same on a large variety of firmware for consumer-level devices, using the TS-S402 as a practical example.
Before reversing any device, it’s important to actually understand its functionalities, components and any other piece of information that may help along the analysis of its firmware. The web page of the product highlights the following features:
Why are these facts important? Not all of them will be useful, but some may provide you with an overall idea of what to expects once you start analyzing the firmware file. In many cases, especially with consumer-level devices, reversing firmware is fairly straightforward and common open-source tools will do the heavy lifting for you. But if you move on to industrial firmware, awareness of the device is important as you will be faced with unheard operating systems, libraries and unknown file formats. In this case, we can expect to see a Linux-based Operating System (OS) hosting an HTTP and FTP server, along with Samba compatibility. The manufacturer is even generous enough to provide the underlying microprocessor, which can be helpful when conducting even deeper analysis for vulnerabilities in the binaries.
The vulnerability we are looking for is present only in versions 2.00.10 and below of the firmware, which you can download from the repository of the company. Unzip the archive and you’ll to obtain the following files:
It’s always a good idea to read the release notes and README files. Doing so may save you time and headaches trying to figure things out. If you’re into bug hunting, the release notes can be useful to list the changes and patches included in this version, providing potential hints to patched vulnerabilities of previous versions.
The two “.bin” files contain the programs and OS of the device. In this case, based on the filename, the TS-S402_FW_2_00_10.bin is the main firmware file and thus, the focus of this post. The first step is always to check if we can determine the file type by using the file command. If we are lucky, it is a known file type and some application exists to extract the relevant files/information out of it.
root@ReSyst:/targets/trendnet/ts-s402# file TS-S402_FW_2_00_10.bin TS-S402_FW_2_00_10.bin: data
However, we are not so lucky. The file command returns “data”, which means it found the file to be binary data without any specific structure or format. So we will need to use a more powerful tool: binwalk. Binwalk is a very useful reverse engineering toolkit that can analyze and extract files from unknown binary files. Note that it can also return quite a few false positives. The only way to recognize them is with experience and trial-and-error. If not already done, install binwalk with apt using sudo apt-get install binwalk and run the following command:
binwalk -x lzma TS-S402_FW_2_00_10.bin
The command above asks binwalk to check out the TS-S402_FW_2_00_10.bin file and try to find interesting files or structures inside it. We use the “-x lzma” argument to eXclude any findings about LZMA-compressed data: these are false positives in this case. You will obtain the following result:
DECIMAL HEXADECIMAL DESCRIPTION ------------------------------------------------------------------------- 32 0x20 gzip compressed data, from Unix, last modified: 2009-04-21 04:22:15
In other words, there seems to be a 32-bytes header followed by a GZip-compressed file. At this point, we want to carve this gzip file out of the binary file for further investigation. You can use the dd command to do so, but binwalk provides the -e option to Extract files for you.
binwalk -ex lzma TS-S402_FW_2_00_10.bin
The carved files will be outputted to a directory labelled _TS-S402_FW_2_00_10.bin.extracted, in which you will find a single file called 20, which is the offset of the file in the larger firmware. Using the file command again, we now get a more interesting result:
root@ReSyst:/targets/trendnet/ts-s402/_TS-S402_FW_2_00_10.bin.extracted# file 20 20: POSIX tar archive (GNU)
This time, the file command clearly recognized a TAR archive, meaning we can simply untar the file with the command below:
tar -xvf 20
This archive contained even more files: a uImage and a filesystem:
The uImage is the boot loader of the firmware and you will often find this file or something similar in most Linux-based firmware. Analysis of the uImage will be left for another post. For now, we are interested in the file system contained in rootfs.armeb.squashfs, which as its name implies, is a SquashFS. To access the files it contains, we can normally use the unsquashfs tool, however in this case doing so won’t work
root@ReSyst:targets/trendnet/ts-s402/firmware# unsquashfs rootfs.armeb.squashfs Reading a different endian SQUASHFS filesystem on rootfs.armeb.squashfs Parallel unsquashfs: Using 1 processor lzma uncompress failed with error code 0 read_block: failed to read block @0x1737f8 read_directory_table: failed to read block FATAL ERROR:failed to read directory table
Depending on how the file system was created and the development software used, it may have incompatibilities with the way unsquashfs expect the file system to be structured. As a workaround, we will use Sasquatch, which is more flexible when it comes to extracting files from non-standard Squash file systems. Clone the project and build the code by following the instructions n the README.md file, or you can download a pre-compiled binary for Ubuntu and variants. Now let’s try again carving out the files but with Sasquatch this time by typing ./sasquatch rootfs.armeb.squashfs. After a while, Sasquatch will extract all files in the squashfs-root directory, at which point you can finally access the files hosted on the targeted device.
drwxrwx--- 1 root vboxsf 4096 Apr 20 2009 . drwxrwx--- 1 root vboxsf 0 Jan 21 11:34 .. drwxrwx--- 1 root vboxsf 0 Apr 20 2009 bin drwxrwx--- 1 root vboxsf 0 Apr 20 2009 config drwxrwx--- 1 root vboxsf 0 Apr 20 2009 dev drwxrwx--- 1 root vboxsf 4096 Apr 20 2009 etc drwxrwx--- 1 root vboxsf 0 Apr 20 2009 home drwxrwx--- 1 root vboxsf 0 Apr 20 2009 include drwxrwx--- 1 root vboxsf 4096 Apr 20 2009 lib drwxrwx--- 1 root vboxsf 0 Apr 20 2009 mnt drwxrwx--- 1 root vboxsf 0 Apr 20 2009 newroot drwxrwx--- 1 root vboxsf 0 Apr 20 2009 opt drwxrwx--- 1 root vboxsf 0 Apr 20 2009 proc drwxrwx--- 1 root vboxsf 0 Apr 20 2009 root drwxrwx--- 1 root vboxsf 0 Apr 20 2009 sbin drwxrwx--- 1 root vboxsf 0 Apr 20 2009 tmp drwxrwx--- 1 root vboxsf 0 Apr 20 2009 usr drwxrwx--- 1 root vboxsf 0 Apr 20 2009 var
There is a fairly obvious backdoor hidden in the file system. Go ahead and explore the files and configuration and see if you can find it. When you are ready read on.
Most commercial devices are accessible remotely via a web interface. The web server and its contents are therefore a good starting point to hunt down potential vulnerabilities. On the TS-S402, the web application is located in the /home/httpd directory. The partial listing of the contents of this directory is included below:
drwxrwx--- 1 root vboxsf 4096 Apr 20 2009 . drwxrwx--- 1 root vboxsf 0 Apr 20 2009 .. -rwxrwx--- 1 root vboxsf 1462 Apr 20 2009 arrow-down-title.gif -rwxrwx--- 1 root vboxsf 1499 Apr 20 2009 arrow-down-title-on.gif -rwxrwx--- 1 root vboxsf 1452 Apr 20 2009 arrow-up-title.gif -rwxrwx--- 1 root vboxsf 1441 Apr 20 2009 arrow-up-title-on.gif -rwxrwx--- 1 root vboxsf 784 Apr 20 2009 backdoor.shtml -rwxrwx--- 1 root vboxsf 489 Apr 20 2009 BTdata.shtml drwxrwx--- 1 root vboxsf 0 Apr 20 2009 cgi-bin -rwxrwx--- 1 root vboxsf 12831 Apr 20 2009 CheckFunc.js …
As you can see, one of the web page is named “backdoor.html”; quite an obvious indicator that something is wrong. If you look at the web page, you’ll notice that it seems to enable the telnetd daemon, thus allowing Telnet connections to the device. Unless specially configured to be blocked in the network firewall, this web page should be accessible to anyone on the network, potentially anyone if facing the Web. All that is missing right now is credentials to access the device. Let’s look at /etc/shadow to see if we can potentially figure out the default password for the root account:
root::10933:0:99999:7::: bin::10933:0:99999:7::: daemon::10933:0:99999:7::: adm::10933:0:99999:7::: lp::10933:0:99999:7::: sync::10933:0:99999:7::: shutdown::10933:0:99999:7::: halt::10933:0:99999:7::: uucp::10933:0:99999:7::: operator::10933:0:99999:7::: nobody::10933:0:99999:7::: default::10933:0:99999:7:::
Well, there isn’t any password setup for the root account. So in other words, anyone who can access the backdoor.html page on the device can enabled remote Telnet connections, and then login as root. While I haven’t tested it as I do not own this device. this vulnerability was previously confirmed and reported.
This post provided an example of reversing the firmware of a consumer-level IT appliance to locate vulnerabilities allowing remote access to the device. Such vulnerabilities may seem trivial and unimportant until a botnet such as the Mirai botnet comes along and use tens of thousands of these vulnerable devices – which are rarely updated – to DDoS websites across the web. Hence the need to understand the techniques and skills required to pwn these devices in order to defend them.
