Recently, I took a look at a Huawei HG658 router for fun – this is a router common to multiple ISP’s across Australia, so a solid vulnerability in this would be significantly re-usable. The router I had in question was live and configured to TPG Internet, a “low-cost Internet” router, and I had physical access to the device, so hardware attacks were on the table.
I started my investigation by downloading a firmware image from our friends at iiNet, available here.
This is a JFFS2 image, which unpacks cleanly to a full filesystem. This is a typical MIPS-based firmware, which unpacks cleanly and emulates in a Debian MIPS Qemu. Upon a cursory inspection of the filesystem, the “telnetd” and “web” binaries stand out.
Initial reconnaissance indicates that port 23 runs a telnet server (as expected), port 80 and 443 run web servers, port 37215 runs something unidentified and port 37443 runs another web server, seemingly dedicated to serving images.
A quick Google search indicates the presence of several vulnerabilities (most notably, a local file disclosure from the port 37443 image web server) for this version of modem, but these appear to have been fixed in the version (re-) sold by TPG – so, down the rabbit hole we go.
A quick investigation of the telnetd binary indicates that it’s a wrapper for cli:
Continuing our investigation, we delve into the /var/cli binary. Quickly, we land at the function at 0x408224, which appears to handle authentication. A brief scroll through the code reveals something interesting:
Google indicates that this is a configuration setting which needs to be manually enabled in a configuration file to enable the Telnet interface. Some initial testing shows behaviour which matches the disassembly, so we download the configuration file from the router’s UI, decrypt it with https://hg658c.wordpress.com/2015/03/17/hg658c_configtool/, enable the magic parameter and reupload it.
While we’re there, a few interesting tidbits catch the eye. Firstly, what appears to be a TPG backdoor:
Secondly, we can see some backdoor accounts (I certainly didn’t create them):
Based on a bit of prior reading, I knew that the !!Huawei backdoor account password was “@HuaweiHgw”, which worked – however, this wasn’t the DES encryption as had been applied in previous versions of the firmware. A simple base64 -d | xxd doesn’t reveal anything I could immediately make sense of.
Going back to the ATP_CLI_AdaptAuthenticateCheck function, we can see that a new, shiny encrypted SHA256 function was in play:
By now, we could log in to the device itself using the !!Huawei account, and pull a fresh libcfmapi.so from the device (via ftpget: it turns out ftpput halts the device, as the name clearly indicates). Loading this into IDA, we can quickly review the ATP_SHA256_ENCRYPT function: it is immediately apparent that this function doesn’t actually encrypt anything, it simply performs a SHA256 hash:
However, we quickly notice other interesting functions within the file, such “ATP_CFM_ExtExportEncryptedCfgFile”, and “ATP_CFM_ExtDecodeParaValue”. We dive into the latter, as we are indeed after a single parameter (at this point: the password to the root account). The bulk of this function appears to be memory-admin related, with the actual decryption handled at sub_473C, a wrapper to a standard AES CBC decryption routine.
But alas, what do we see above it? Bingo: shiny new static keys –
Using these, we can quickly build a Python script, which grabs the encrypted password blob, and spits out a SHA256 hash of the root password, as well as the hash of the “!!Huawei” account, for confirmation. This is available here. I ran this through an initial wordlist and no dice, I’ll brute force this properly when I have time (or a beer for anyone who cracks it first).
Given the progress so far in working on this device, and the success in running it in an emulation setup (and thus, enabling the use of normal gdb), I intend to continue reversing the web server to identify additional vulnerabilities (I was somewhat peeved that the old ping command injection trick had been patched on this device – a shame).
I hope you enjoyed reading this 🙂