> Protecting the digital nomad
Part 1: Digital nomads, driven by the expanding Internet bandwidth and availability, are growing in numbers. There are open communities like the Subreddit /r/digitalnomad and others are commercial like the Digital Nomad Community. However, from the Cyber hygiene point of view, bouncing around like that can be about as safe as unprotected sex. In this post, I’d like to explore the security of one device that aims to protect the traveler’s meatspace to cyberspace bridge. The device is the HooToo Travel Mate 06 (TM-06) travel router – it is a cute little device but provides loads of security fun!
The community of digital nomads is growing in addition to an already large number of business/vacation travelers around the world. Apparently, the community is on its way to one billion in numbers. However, I’m more interested in the security side. Their security needs are quite demanding because they have to touch many networks/devices with questionable security hygiene. At Blackhat 2016, there was a talk on Internet safety in AirBnB’s and similar rentals. The speaker showed us how risky it can be to move between networks of differing standards. As this talk points out, there is a similar issue with public Café Wi-Fi’s. The wireless networks from one location to another vary greatly, mostly within the category of being vulnerable, exposing guests and hosts to malware. That piqued my interest and initiated this research.
Looking for a solution, I discovered the concept of a travel router. Basically, a MiFi but without the SIM card and some additional features. A search on amazon returned well over a thousand of results – ranging in fitness to the search criteria. Taking price and function into account, I zeroed in on the HooToo TM-06 (the device). Its functions include Wi-Fi extension, Wi-Fi to Ethernet bridging and Hot Spot creation. However, security is one of the selling points: “create your own secure Wi-Fi network,” they said. I took this to mean that I can create a network more secure than what I bridge to in a Café, AirBnB or a hotel. At the very least, I could have an additional layer of protection such as what I could get from a NAT or a good firewall. Naturally, I wanted to thoroughly check if this security claim was true.
There was some initial work done on HooToo devices, including the previous versions of the TM-06, by chorankates. Also, Smith published XSRF exploits which remain unpatched. However, I wanted to see if I could get more out of it.
While the device seems to be popular on the Amazon, I don’t really see them around much. So they are not mainstream popular, not like an iPhone, but there are still enough out there to make for a useful target and pose some real dangers. Unfortunately, being below the radar also means that the device has not received much scrutiny from the security community to ensure the devices are safe to use.
Let’s Get to Work!
The device is configurable via a web interface and it exposes a whole bunch of TCP ports to support its various features.
Figure 1: Login page
By default, the device doesn’t have a password set on the admin user in the web interface. The user is expected to change it upon initial setup. This is not bad in itself but the device should really require the user to set the password after initial login. The WebUI itself doesn’t provide a lot of rich features – it is a simple, to the point, UI. What you’ll find there are some basic Wi-Fi settings, MAC spoofing, access to media storage and network configurations. Obviously, an attacker getting access to such things would be bad, but I wouldn’t expect it to be too damaging.
Figure 2: Login page
Of course, all HTTP interactions are unsecured. There’s no way of configuring TLS for the administrator interface. As long as you configure WPA for your wireless network then that should be OK, right? I guess, it just depends on how much you trust the people you allow to connect to the device with you. Personally, I would’ve preferred to have some TLS, not like encryption takes so many resources to run for one user. This is a perfect case where I’d give away some performance for much more security.
Next, we connect to the device’s local Wi-Fi and do a full nmap scan:
Some interesting things there. I always enjoy seeing ‘weird’ looking ports that are open for business. Not quite sure what to do with them yet but I imagine they have something to do with the various services (such as samba and DLNA Services) that the device provides. I was, however, disappointed that there are no remote shell ports to be found, such as ssh or telnet. That is especially because telnet was discovered during analysis of older versions, by chorankates. I guess HooToo did some enhancements since then.
Next, I’d like to look at the firmware and see what kind of interesting things we could discover there. After a little bit of googling, I found that it’s possible to update the device with new firmware found on the HooToo support page. The update process is to upload the update file via the authenticated web interface. Finding an update file like this is exciting because it means we get to peek inside the code that is executing on our device.
I’m not quite sure why, but the update package included the same file thrice. Each with a different name:
Looking at the binary, we find that it is actually just a bash shell script:
The first thing that stands out is the fact that there is no cryptographic signature to be found. So there’s no way to verify authenticity. The only thing we get is a CRC checksum which is clearly not a security mechanism.
Next, we find this little section in the script:
The script executes a tail command on itself where it skips SKIP number of lines. SKIP is defined to be 263. The reference to firmware is encouraging and curious, so let’s run this command and see what happens.
Cool! That seems to have worked and given us a valid gzip file. This command extracted the binary content that was following the shell script which turned out to be the gzip file.
Uncompressing the gzip, we see that it is an ext2 filesystem. Now, I’m truly excited because we can mount something 🙂
We get lots more fun things to play with. That update.sh file and the firmware directory are the first targets – specifically, firmware looks most interesting. So, let’s keep unwrapping this package!
rootfs looks promising because it is a Squashfs filesystem, so this file probably lands up on the flash drive of the device. Looking at the kernel we can also get some information about when it was built and the kind of architecture we should expect. So, let’s mount the filesystem and peek inside.
There is nothing that is out of the ordinary. Looks like a small, possibly custom, distribution of Linux for a MIPS embedded system. On the support page, we see that the device’s chipset is MTK 7620. With this information we can find the datasheet and the CPU instruction set manual for the MIPS32 24K Processor. This will come handy in the future.
It only took about two days of john the ripper on a reasonably priced AWS instance. The password was discovered by brute force: 20080826. What’s sad is that we have no where to use this password. There’s no login shell and the root user does not work via the web interface. Also, I couldn’t authenticate by directly sending the root login request using burp – so, the username enforcement is happening on the device. This is a good sign, otherwise we’d have a nice back door that, likely, no one would check for.
For this write up, we’ll stop here with the firmware analysis. There’s certainly more to do. But for now, we have all the files that we need for further specialized branches of analysis.
Getting a Debugger
So far, we’ve discovered some useful things about the device: the firmware, some unfixed issues and its architecture. However, nothing terrible and, as I’ve eluded to earlier, we really want to get some execution on the device. Ideally, we want to crack in, but until then let’s see if we can use semi-normal methods.
Looking at our analysis so far, we notice that the firmware is not signed and it is a simple shell script. So, let’s build our own update! 🙂 Also, we notice that in the previous analysis, by chorankates, the earlier versions of the device had port 23 (telnet) open. So, I would guess that this functionality was disabled rather than removed.
A quick search reveals that telnet is, indeed, available and can be started via the opentelnet.sh script. What we’ll do is attempt to execute this command via our own firmware update package.
The update mechanism is accessible after the admin user has logged in on this URL: http://192.168.1.1/app/system/firmware.html.
My first attempt was to upload a basic shell script:
I wanted to return an error, so that the system would not decide to, irreversibly, change anything internal and possibly brick the device. Unfortunately, that did not work. Obviously, I got no explanation. Further analyzing the official update package, we notice that the update usually comes with a CRC checksum. There is a check in the official firmware update that looks like this:
It was a little confusing why the failure occurred even though the check looks to be self enforced. What I realized later, is that the device will actually perform it’s own CRC validation before letting the script execute. However, the process is the same.
Using my Mac Book Pro, I generated a check sum using the same command that was found in the official update. Notice that I’m using an older version of the firmware than the one I mentioned above. This is because at the time of this research version 2.000.030 was the latest. So far, such details are not relevant to the work in this writeup.
D’oh! It doesn’t match! The number in the firmware file is 3587589093. That’s weird! This was a real head scratcher for a while because I really wanted to be able to generate a CRC number that matches what the device expects. After a few hours of unproductive search, I decided to try it on my Ubuntu VM.
Worked! I still don’t know what the deal is – I’m sure there is a simple explanation. It looks like the cksum command on Linux uses a different algorithm compared to the one on OS X. Probably should have done this sooner given that the device runs a version of Linux. Lessons learned!
With this information, I constructed another shell script with a proper CRC checksum this time:
Those other lines are a copy/paste by product. Since the CRC was already generated, I didn’t want to take them out. Upon uploading this as a firmware update, the device gave me an error. However, doing a network scan, I saw that telnet was open! This means that the error was generated by the exit 1, rather than by incompatible firmware.
The custom update enabled us to login using the cracked root password:
We are in business! Getting a command shell on an embedded device is so exciting 🙂 But, let’s move on. The title of this section is ‘Getting a debugger’ and that is what I want. GDB comes to mind, however, I do not find it on the device. This means we will have to find a version that runs on MIPS. After some googling, I found that Rapid7 has actually published a version of the GDB server that runs on MIPS. Although, we have a terminal session on the device, there’s not really a good way of uploading files to it. However, it does automatically mount USB storage devices which is super convenient.
We attach to a process like so:
Then, we use gdb-multiarch to connect to the server. I haven’t been able to get that to work on OS X, so I used the easy way on Ubuntu:
Cool! We have a debugger.
Secure infrastructure is important. It is important even to a digital nomad, whether they are a permanent nomad or just a temporary one. Based on research by several security professionals, we’ve seen how hard it can be to get secure infrastructure on the go. HooToo tries to provide an additional layer of security via the Trip Mate travel router.
In this post, we have discovered the surface area that could potentially be used for attacks. We have also seen how a researcher could gain shell access to their device by uploading fake firmware updates. Using these methods, it becomes possible to obtain the binaries that execute on the device as well as set up a dynamic analysis environment.
Interested in more travel tips for Digital Nomads? Read this post from AlltheRooms: What Are Some Travel Tips for Digital Nomads?