Exploiting Embedded Systems – Part 1

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.

OK, we’ve found a target and we can see from the login page that it is a Trendnet TEW-654TR. It always helps to gather some information about your target, so let’s look at some of the features listed on Trendnet’s product page:

This script does appear to be run on startup. It creates some temporary directories then runs system_manager, tftpd, and loads a kernel module. The tftpd command is particularly interesting! Let’s take a quick look at the binary:

From the function names and strings, this appears to be a pretty straight forward tftp server. Let’s see if we can connect to the tftp server and download a file. We know from the rcS script above that the file /var/etc/udhcpd.conf gets created at boot, so we’ll request that file as a test:

Well it looks like the tftp service is running and accessible. Ideally what we'd like to find is where any sensitive information is stored on the file system so that we can download it through the tftp service.

From the comments in the rcS file, we also know that the system_manager binary is responsible for "load[ing] [the] configure file from Flash". If the system_manager saves the configuration file to a temporary file or to a location in ramdisk, we should be able to retrieve it.

The .db files are particularly suspect, as they each appear to have a default backup file. Almost all routers have the ability to restore their default configuration, so they have to store these default settings somewhere; if these .db files are in fact the router's configuration files then this would make sense.

These .db files could be just what we're looking for, but which one should we get? We probably don't want the default files, so that leaves rt.db, ap.db and apc.db. Recall that the device's product page mentioned that it can operate in three different modes: router, access point, and access point client. These files are probably the separate configurations for each mode.

Since the target appears to have remote administration enabled, it is probably not acting as an access point or a client device - a straight access point or client probably wouldn't have a concept of "WAN" vs "LAN" interfaces - so we'll try the rt.db (router) file:

22 Responses to Exploiting Embedded Systems – Part 1

not big news that if you run a ip scanner looking for opened ports 22 and 23 (ssh and telnel for those who dont know), 50% of the result will have the default login and password
admin admin
admin 1234
admin 123456
root ____
root admin
root 1234

or in some specific cases, if it says the brand, then google the default password and you’re in.

this kind of stuff makes you think they should change the definition of “security” in the dictionary

both the default user and password should calculable from the S/N on the router’s back, or be one time usable so the user is forced to change it.

Well, this wasn’t a default password. The database mentioned above contains the device’s current running configuration and was pulled directly from the device.

Default passwords can be a problem though. Verizon FIOS routers now use the router’s serial number as the administrator password (it used to be password or password1), but most just have some simple default login.

1.1.1.102 doesn’t appear to be in a traditional private address space, does that mean that the tftp daemon is able to accept external internet connections, if so that is quite frightening that they didn’t kill it after the boot process or at the very least restrict their build or configuration of tftpd to local network only as that is even more trivial then implementing the protocol itself.

The firmware mod kit is available from the google code page linked to in this post. There is no download though, you need to check it out from the subversion repository (follow the instructions on the FMK sites’s ‘Source’ tab).