Following the path of least resistance,
let's see if we actually need to obtain the firmware for the TP link router.
For this demo,
we'll use the FT232 USB to TTL serial adapter to connect the
rooter serial interface to our lab environment.
When communicating over UART,
what we need to ensure the transmit pin on one device is connected
to the receiver pin on the other and vice versa.
For this demo, we don't need to connect VCC.
I'll be working in a Kali Linux environment for most of these labs,
but for the most part,
the tools and techniques work in other Linux environments and Windows.
We begin by launching PuTTY and specifying the connection parameters.
The USB device is connected to dev/ttyUSB0 and the connection speed
for the TP link UART interface is 115,200 KBps.
Next, we specify a log file to record the details of our session.
Now that we have a terminal waiting to receive data,
we can power on the router,
and we see that the U‑Boot bootloader begins the boot process immediately.
There is lots of useful information contained in these boot messages
that we can go back and review in the log file later,
particularly information about memory layout and the
location of file systems in memory and so on.
Eventually, the boot sequence completes and we drop into our command line.
I'll first quickly kill a process that I know is going to
generate lots of annoying debug messages.
Now, let's take a look around.
It looks like a fairly standard Linux file system.
There is quite a limited command set,
but we do have busybox which may offer us more options.
We have some additional commands such as TFTP,
which could come in handy, but it's not a full BusyBox install.
We also have a few more options if we have super user privileges.
Let's take a look in etc.
That password file looks interesting.
Let's take a look.
We have a user called admin and we have the password hash.
We'll look at that in a bit more detail later.
In the library folder,
we have a number of shared object files which allow programs to access common
functions from one shared place in a computer system memory rather than
implementing their own versions of the functions.
These could be interesting to look at later to see if
they have any known vulnerabilities.
Let's see what processes are running.
A couple of things to note are the dropbear SSH server
running on port 22 and the HTTP daemon,
so we have a running web server on the device too.
Running netstat, we can identify any network connections.
These could be worth exploring in more detail,
particularly UDP Port 21 for FTP and 23 for Telnet.
We saw from the password file that we had a couple of users,
but who were we logged in as?
Let's try whoami.
That command is not available.
Let's see what information we can find out about the device with uname.
Well, we're starting to see the limitations of the command set available to us.
Okay, let's think again.
We know we have a BusyBox install of TFTP.
Perhaps we could use that to pull in a more complete set of BusyBox tools.
Using mount, we can see that the only writeable file system we can access is var.
That's okay, but it means that if we transfer our BusyBox toolset in here,
we'll lose it when the device reboots.
Let's change into the var directory and run TFTP,
specifying ‑g for get, ‑r for remote,
the name of the BusyBox file we want to transfer,
and the IP address of the TFTP server.
Once that's downloaded, we make the file executable using chmode.
Running our new BusyBox install,
we see that we have a much bigger set of commands to work with.
Trying to run whoami again with our new BusyBox install,
we can see that we're logged in as user admin.
Trying uname again,
we see that the routers hostname is TL‑WR841N and that it's running
version 2.6.36 of the Linux kernel on a mips architecture.
This version of Linux was released in October 2010 so it's
pretty old, and there are a lot of known vulnerabilities
that might be worth exploring.