In part 1 we used the TEW-654TR’s TFTP service to retrieve the administrative credentials to our target system.
But what if we didn’t have access to the TFTP service? Many embedded devices don’t have a TFTP service, or there may be a firewall between us and the target that blocks traffic to UDP port 69. In this case, we’ll have to take a closer look at the web application running on the target.
So far our tutorials have focused on extracting file systems, kernels and code from firmware images. Once we have a firmware image dissected into something we can work with, the next step is to analyze it for vulnerabilities.
Our target is going to be the Trendnet TEW-654TR. We’ll be examining many different security holes in this device, but for part 1 we will focus on gaining initial access given only a login page and nothing more. We will assume that we do not have physical access to the target device, nor to any other device for testing or analysis.
If you don’t already have them, you will need to install binwalk and the firmware mod kit.
Let’s get started!
SquashFS is a widely used file system in embedded Linux devices; in fact, it is probably one of the most commonly used file systems among Linux based consumer products.
While many devices use standard SquashFS file systems that can be extracted using the unsquashfs tools provided in the firmware mod kit, you will inevitably encounter some implementations that are…special.
Perhaps the vendor simply changed the SquashFS signature, or maybe they modified something in the de/compression code, but for one reason or another, none of the unsquashfs tools will work.
The D-Link DIR-320 is special.
Lately I’ve been working on taking apart some VxWorks firmware images. Unfortunately, I could find precious little information available on the subject, so today we’ll be extracting the VxWorks kernel and application code from the WRT54Gv8 firmware image and analyzing them in IDA Pro.
The WRT54G series infamously switched from Linux to VxWorks with the release of the WRT54Gv5. Because VxWorks is a proprietary RTOS, it is a less familiar environment than a Linux based system. Even once you identify the different sections of the firmware image, there usually isn’t a standard file system full of standard ELF executables that can be automatically analyzed by a disassembler.
The overall process for reversing this firmware is pretty straight forward:
- Identify and extract actual executable code from the firmware image
- Identify the loading address for the executable code
- Load the executable code into IDA Pro at the appropriate loading address
- Augment IDA’s auto analysis with manual/scripted analysis
Debugging with JTAG or observing debug messages over a serial port can probably be substituted for steps #1 and #2, but since I don’t have any VxWorks WRT54G routers, this will be a purely firmware based analysis.
Customizing firmware images can be a very useful skill, allowing you to add or unlock features, fix bugs, and patch vulnerabilities when vendors can’t (or won’t) do so in a timely manner.
A while ago I found that my Trendnet TEW-632BRP and TEW-652BRP routers had a TFTP service running on both the LAN and WAN interfaces that allowed anyone to download the device’s configuration file without authentication:
embedded@ubuntu:~/TEW632$ tftp 192.168.10.1
tftp> get /tmp/etc/nvram.conf
Received 19897 bytes in 0.0 seconds
embedded@ubuntu:~/TEW632$ head nvram.conf
After contacting the vendor they verified the vulnerability and issued a firmware update that disables TFTP access from the WAN. However, they insisted on leaving TFTP accessible from the LAN “for repair purposes”. I’d much rather have TFTP disabled completely, so in this tutorial we’ll be patching the Trendnet firmware in order to completely disable TFTP. The patching process for the TEW-632BRP is also pretty simple, so it makes for a good introduction to firmware patching too.
The ability to analyze a firmware image and extract data from it is extremely useful. It can allow you to analyze an embedded device for bugs, vulnerabilities, or GPL violations without ever having access to the device.
In this tutorial, we’ll be examining the firmware update file for the Linksys WAG120N with the intent of finding and extracting the kernel and file system from the firmware image. The firmware image used is for the WAG120N hardware version 1.0, firmware version 1.00.16 (ETSI) Annex B, released on 08/16/2010 and is currently available for download from the Linksys Web site.
When examining embedded devices, it is not uncommon to find that two or more of them share common code, and even common hardware. This probably comes as no surprise, as re-using code and hardware designs helps lower production costs. What might be a little more surprising is when you find two devices from two different vendors that share the same code or hardware.
It’s important to be able to identify devices that use the same code or design. If you find a bug or vulnerability in one device, it’s likely that it affects other devices as well. Likewise, if you are having trouble reversing or analyzing a particular device, work that others have done on similar products can help put you on the right track.