Reverse Engineering Router Firmware

Reverse engineering, also called back engineering, is the process by which a man-made object is deconstructed to reveal its designs, architecture, or to extract knowledge from the object; similar to scientific research, the only difference being that scientific research is about a natural phenomenon

Welcome back to LSB fellow hackers, thank you for your visit. As the title to this blog post suggests, today we will reverse engineer Trendnet TS-S402 firmware.

We will demonstrate, with the help of some tools, how we could possibly get remote access to a router that is running this type of firmware. If your own router is running this version of firmware, we highly recommend you upgrade to the latest release.

So let’s get started. Firstly we will need to download the firmware image to our hard drive so that we can unpack it. So go to http://downloads.trendnet.com/TS-S402/firmware/ and download the 2.00.10 version, this is the one we will be analyzing.

Once you have downloaded the zip file to your computer you will need to open up a command shell and navigate to the folder where it was downloaded to.

Next we just need to unzip the file and see what it gives us.

unzip FW_TS-S402\(2.00.10\).zip

Perfect!! Now we can see that there are two binary files, a README.txt and a release text document.

At this point we would strongly recommend you read the text files, this will give you a better understanding of how this firmware works. The more information you can extract from these the better chance of us finding a vulnerability.

The next step for us is to find out what format the binary files are in. Most firmwares are basically compressed file systems. To reverse them we will first need to find out the compression algorithm and the file system it is using.

What we usually do here is to use the file command of the LinuxOS.

file REMOTE_PACKAGE_2_20.bin

All it gives us is that it is a data file. That is not very useful, let’s try the same command for the second binary.

It’s the same, so Linux does not recognize the format of the 2 files. So we will need to use something more advanced to figure out how these files are formatted.

This is where Binwalk might come in handy. Binwalk is a firmware analysis tool that you will use a lot if you are reverse engineering regularly. You can download it from here.

The installation instructions are available on the website so we will not go into that in this post. But if you are using Ubuntu or some variant, this will install it for you from the command line.

sudo apt-get binwalk

Now let’s run Binwalk against our binaries.

binwalk TS-S402_FW_2_00_10.bin

So once you hit enter after the command above, what Binwalk is going to do is analyze the file and print on screen everything that it found.

This looks very messy and most of the information is not anything that we can use. The most interesting thing that Binwalk found is the first file.

This is a gzip compressed file from Unix, this might be a Linux operating system that runs on top of the firmware because it takes up quite a chunk of the file. So let’s focus on that.

Firstly let’s clean up the output and get rid of any of the information we don’t want.

binwalk -x lzma TS-S402_FW_2_00_10.bin

This will clear (-x means exclude) all results with the String lzma in it.

So now we will go a bit deeper and inspect the gzip file, to see if we can extract anything from it. Binwalk takes a -e argument that means Extract, so let’s try that.

binwalk -ex lzma TS-S402_FW_2_00_10.bin

This command will extract all the internal files of the binary file that does not contain lzma data. So let’s see the results of the command.

Cool, we have extracted a folder on the bottom line in blue. So let’s enter the folder.

cd _TS-S402_FW_2_00_10.bin.extracted

ls

So there is just one file in there and it is called 20. So let’s see what kind of data is in the file, we will use the file command again.

file 20

Interesting, it gives us a tarball, this is another compressed file. Just for tidyness let’s rename the file something more appropriate and then untar the file to see what is inside of it.

mv 20 20.tar

tar -xvf 20.tar

ls

This is what Reverse Engineering is all about guys, being curious and digging down into files and see what treasures we find.

So the results of us untarring the 20 file gives us two more files, rootfs.armeb.squashfs and uImage respectively. Let’s confirm what type of files these are with the file command again.

file rootfs.armeb.squashfs

file uImage

This is very interesting, this file is a u-boot Legacy Linux image, this is more than likely  the partition that contains the kernel of the operating system on the device, while the rootfs file system contains the partition along with the files.

So let’s focus on the rootfs file and we can see that it is a squash file system. So what we need to do to be able to access the files of the bootfs file is to mount the file system locally. So let’s make a new directory to do that and then mount it in our new directory.

mkdir sqsh

sudo mount rootfs.armeb.squashfs ./sqsh/ -t squash fs -o loop

Let’s see the results from running that command.

We got an error, don’t worry, this happens quite often, we can’t expect to run all commands first time successfully.

So what happened? Apparently we used the wrong file system in the command, so it’s saying it’s not a squash file system. Many manufacturers use customized squash file systems to compress their data, so maybe that is why it is not reading it properly.

So now we will use a tool called Sasquatch, which comes in very handy for these customized file systems. You can download and install it from here.

So let’s use sasquatch on the file system.

./sasquatch rootfs.armeb.squashfs 

ls

Boom, once we run the command we get  rootfs directory.

So let’s navigate into that directory.

We have full access to the file system, so we can change basically anything we want here. So we are basically done with the Reverse Engineering but we want to have a look around and see if we can find something useful.

We noticed in the home/httpd directory the following files. It looks like it’s the webserver for the firmware.

If you notice in this directory of files there is one that stands out because it has a very odd name. Have you spotted it?

Yup. one of the files is named backdoor.shtml.

If you find something like this it is always worth having a look to see what it is. So let’s open it up in a text editor.

sudo nano backdoor.shtml

So we can see that it is indeed a HTML file, so let’s see what is interesting in here. One thing did stand out.

Could this be for a remote Telnet connection, let’s look a little deeper. Let’s open backdoor.shtml in our browser.

firefox backdoor.shtml

So this is a basic web page that resides on the web server and is called backdoor.shtml, getting more interesting by the second!!

$199 ENROLLS YOU INTO THE CONTAINERS FOR DEVELOPERS AND QUALITY ASSURANCE COURSE (LFS254)!

Now let’s see how we could leverage this to gain access to this system. If the telnet daemon starts this might mean we can log in as one of the users. We only know one user that is always there and that would be the root user.

So let’s go check it’s password to see if it’s set by default. We can find out in the /etc/passwd/shadow file.

cat squashfs-root/etc/passwd/shadow

Would you look at that!! According to the shadow file the root user has no password assigned to it. We can log in without a password.

We only have the firmware and not the device to do this, but in theory we could find a device on the internet running the same firmware and login via Telnet with no password.

Thank you so much for getting to the end, this post took us a long time to perform and write. Please, like, comment and don’t forget to subscribe for more shenanigans.

QuBits 2019-10-03