ISP Hardware Hacking: SAX1V1R
My ISP sends me hardware.
I like to keep these things in a box and pull them out once in a while when I get new skills or ideas and since this one has been in the write-up backlog for a while now I figured might as well finish it. In this post I will be covering some analysis that I did a couple years back on the SAX1V1R ISP provided router produced by SERCOMM.
This device is a pretty typical ISP router, it is designed to be connected to the modem so that a customer can get blazing fast wifi speeds on all of their mobile devices. Really nothing super fancy.
Though one of its unique 'features', and my biggest gripe about this device, is the lack of a LAN based configuration page...
The ISP forces you to use their mobile app to manage this device... How stupid is that?? Anyway, now that we're sufficiently annoyed we can start analyzing this hardware effectively.
FCCID.io OSINT
If you've read any of my other posts you'll know that I just love to take hardware apart, if I can do it non-destructively it's usually one of the first things I do during an engagement.
It's definitely not always fruitful so one of the things we can do prior to getting the screwdriver out is to check fccid.io for some internal pics. These can be valuable because often times you can spot the presence of debug ports and interesting chips without having to take the thing apart. You might also get an idea of how the device is assembled making the tear down a bit easier.
If we take the FCC ID (usually found on device labels) and throw that into fccid.io we get a nice list of test documents that are provided during the device certification process. These documents are super handy for a variety of reasons but we're mostly interested in the internal photos of the hardware itself.
FCCID: P27IP5446A
FCCID.io device internal photos
not-so-hidden headers
One thing that really sticks out when reviewing these docs would be the presence of debug headers. Highlighted in the red circle in the above photo we can see a black 4 pin header on the board located slightly above the hotdog stand cable.
If we were to take the device apart later and discover that this header is non-existent that would be a clear sign that the pins are for debugging the device. Most manufacturers will take a test device that is in development and send it off to get certified, later during production the headers will be taken off the BOM to save costs and reduce the attack surface.
Lucky for us headers are cheap and soldering is within our capabilities! I'll go ahead and solder some headers to the board and we can test them to see if they're still live or if the interface has been disabled.
identifying header voltages
Pardon the dust... Like I said, this has been sitting on a shelf waiting for a write up for a year or so now... Anyway... I've gone ahead and soldered some headers onto the board.
OKAY, before you start shaming me for my poor soldering, I have a single excuse, the pins are too thicc. But hey, they make a connection so MEEHHHH I don't care!
Before I go ahead and hook up my UART-to-usb adapter I want to identify any pins that are ground or voltage as to not fry any hardware, using a simple multi-meter we can determine if any pins are likely to let the magic smoke out, if you know what I mean.
Additionally you can check the silkscreen on the board, sometimes there are indicators of which pin is which but it's up to you if you want to put all of your trust in a silkscreen.
- ground pin
- with the device powered off, place your meter in continuity mode and touch one probe to a known ground such as the shielding of the ICs or a USB connection
- touch the other probe to each of the pins you're testing and the meter should squeal when you've met continuity with the ground plane, note these as ground pins.
- TX pin
- place your meter into low voltage mode and place one lead on an unknown pin. Place the second lead onto a known ground, turn the device on and watch the voltage on your meter
- if the voltage fluctuates rapidly between high and low and sits steady around 2 volts a while after boot then you have likely identified your TX pin
- RX pin
- perform the same steps as before for the TX pin however we're looking for a voltage that sits close to zero or close to 3.3v
- when the device is turning on it should print out a bunch of data so our RX pin should have no to very little fluctuation
- VCC pin
- This is the one you wanna watch out for, they'll usually sit at a solid 3.3v or 5v so make sure to identify any voltage pins before you plug in your hardware
There are some additional steps you can take to identify which pin is which such as continuity testing the pins directly to the IC, for more details on that you can check out this great reference:
Hardbreak wiki: identifying UART pins
In any case, I've identified the required pins and can now hook up the UART-to-usb adapter, I'll be using a Flipper Zero for this job. After I connected the pins to the specified connections on the flipper I then went into the settings and set the USB Channel to 1 and finally connected the flipper to my Linux host.
Access over UART
Once connected I can then turn on the router and check to see if any data crosses the wire:
Nice! Looks like we're on the right track because you can see the byte count
on the right hand side of the flipper display increase. Next, from my Linux
host I used minicom to connect to the Flipper tty port with the following
command: minicom -D /dev/ttyACM1 -b 115200
In the minicom window I can see a ton of debug text scroll by upon device boot up again confirming that we've got a live one.
!!! If you are getting a bunch of garbled output or no output at all, you may need to reverse your TX and RX pins or check the baudrate. Doing some research on the chipset you're testing will prove useful when you run into this problem!!!
Something you can do at this point is to copy the boot log out into a separate file so that you can analyze it later, this WILL be useful, trust me. In my case after the device boots we can press enter a couple of times and we'll be presented with a login screen.
Because it takes a few seconds I'll try a couple of easy to guess passwords such as admin, password, 12345 etc...
No luck! Ah well, no worries. I can always come back to this later and make some sort of brute force if we really need to but that's a lot of effort that may not be necessary.
When I went back to the boot log I noticed something interesting... it seems during boot we're prompted to enter a failsafe mode.
Things like this are always fun to explore because they may give you access that you didn't have prior and any amount of access is better than no access!
Press the [f] key and hit [enter] to enter failsafe mode Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
Obviously, I rebooted the device, mashed F and pressed Enter when prompted and WHAM, looks like we've got a failsafe shell now!
It seems this drops us into a busybox shell with limited access to system utilities and configurations. From here we can poke around at the filesystem and attempt to find a way to uncover or reset the root password.
First thought, lets just use passwd and see if we can set a new root password:
passwd: /etc/passwd: Read-only file system
WOMP WOMP! No worky...
It seems like the device filesystem is mostly read only, so no amount of setting the password is actually going to do anything good for us.
Eventually I discovered the underlying OS is actually OpenWRT, this is good for us since there's a ton of documentation online about OpenWRT setup. Following the docs related to failsafe mode it seems like we can run a simple mount_root command to get the filesystem mounted.
OpenWRT entering failsafe and factory reset
Okay, with that done, lets try our passwd command again:
passwd: password for root changed by root
Eyyyy! This seems good, after setting a new root password with passwd I then reset the device to get out of the recovery shell and let it boot normally.
Once at the usermode login I entered the username root and the password we just set (robots2023) aaaand...
Login incorrect
Okay, that's annoying... So at this point I'm left with nothing but to dive back into the recovery shell and start sleuthing around for some scripts and configurations that might be hampering my efforts.
Finding the juice
Initially I cat'd out the shadow file hoping to see a static hash in there that I can run in my cracking rig while I mess with other stuff, unfortunately just more evidence that the password is set at runtime by something...
There is however a static hash for the osync user... I'll go ahead and run that through some hashcat just because it's fun and it might be useful later.
Another great option now is to craft some find and grep commands to start digging through system files. Some useful directories to look at on a linux system would be /etc/, /opt/, /home/
Running the command below returns a nice list of files with text matching the regex pattern password|passwd
egrep -rni 'password|passwd' /etc/
If you look closely you can see there are a couple of init scripts that seem to be echoing a $sn variable into the passwd utility, I think this is what I'm running into when I set a password and it is suddenly no longer valid upon normal boot. I'll go ahead and cat that script out for analysis.
Analysis of setpwcmd
For the most part this is a pretty simple script that was found in the /etc/init.d/ making it an autorun script. I've gone ahead and highlighted some key portions of the set_pw_cmd shell script:
Some extra context on the individual sections:
- This snippet is responsible for setting the
$snvariable to the output of theftcmd get pw_csncommand, the result is a string matching the SN on the device's sticker - A little bit more complex but in essence it performs a couple of checks to ensure that the SN value pulled from firmware meets the criteria for using it as the root password:
- SN variable does NOT exist
- OR length of SN is not equal to 15 characters
- OR the first three characters are not
60Rif either of those criteria are met it will look for a bypass flag, if that doesn't exist it then proceeds to construct a serial number based off a static prefix concated with the MAC address and then sets the root password
- if neither of those conditions are met our SN is deemed 'OK' and is set as the root password
So it seems the 'happy path' through this code is by having a valid serial
number in firmware at which point it will directly write that as the root
password. Based on this it seems I should just be able to reboot the device
into usermode and then login with root:60RP21060070064...
Getting root
Wowee! So you're telling me I spent all of this time only to find out that I could have logged in if I had simply tried the serial number as a password? No worries! I'll add that to my list of quick checks next time I'm facing a root login :)
All in all this was a pretty fun first excursion into testing this hardware. Now that I have root access I can start to do some more stuff like investigating the ISP software that has been loaded onto the device along with pillaging any device certs and keys that can be used for further attacks!
I still have a few discoveries related to that which I will most likely write about so check back later if you're interested in what else I found!