Exploiting the backup and restore feature on the 4GEE Home Router
I wanted SSH access back that badly, I decided to enable it again, by force!
I’ve been posting about the 4GEE Home Router a lot lately. My main focus has been around regaining SSH access to the router which was once originally possible, but since disabled by EE/Alcatel, in newer firmware updates. My motivation for doing this, is mostly my own curiosity and it’s not always the case an ISP provided router has SSH access available. I’ve already covered this subject in a previous article where I also showed some of the hidden features this router has.
In order to regain SSH access, I looked at a few areas, which mostly led to dead ends, except one, the backup and restore feature. For reference purposes, this was all done with the firmware HH70_E1_02.00_24.
Exploiting the backup and restore feature
Most if not all routers come with some form of method to backup and restore configuration settings from a file. From a general security/exploitation vector point of view, this area often receives a lot of attention as security/protections can be poor. The Alcatel HH70 firmware (which the 4GEE Home Router is a variant of) seems to have little to no checks done in this area, which is why it’s been my main focus for the purpose of re-enabling SSH access. Here’s what I found.
When you backup this router’s configuration settings, a configure.bin is generated. Because this file is a binary, it will not be readable in most programs, but you can use something like binwalk to explore the contents. When you examine the configure.bin with binwalk, you’ll see something similar to this:
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
45 0x2D gzip compressed data, maximum compression, from Unix, last modified: 2020-05-22 13:43:32
19907 0x4DC3 gzip compressed data, maximum compression, from Unix, last modified: 2020-05-22 13:43:29The configure.bin contains two gzip archives at two offsets, there is no encryption, only compression, so this makes it easy to extract the contents with the -M -e flags, which yield the contents of a backup_dir folder. Crucially, within this backup_dir is another sysconfig.tar.gz which contains parts of the /etc folder path. In the backup is key config files within /etc/config. The one I was interested in that was present was /etc/config/dropbear . Under the hood this router runs a modified (very ancient) version of OpenWrt (14.07 Barrier Breaker).
On the filesystem of a 4GEE Home Router that has SSH turned off, this will be the contents of that file currently:
config dropbear
option PasswordAuth 'on'
option RootPasswordAuth 'on'
option Port '22'
option Interface 'br-lan'
option enable '0'
# option BannerFile '/etc/banner'The original mitigation was basically to disable the dropbear daemon, because of the hard coded root SSH login credentials being easily obtainable, so the enable option is set to 0. For SSH access to be available, this needs to be set to 1 with the dropbear service running.
Crafting a modified configure.bin for exploiting
Knowing what’s inside the contents of the configure.bin and it seemingly having no encryption/protection, I examined the file in a hex editor to look at the structure.
We can see the first bits of data is a file header ALCATEL BACKUP FILE HEAD, followed by the first gzip archive at 0x2D, which is called backup.tar.gz. At the other offset 0x4DC3 we see, another file header, with the second gzip archive mdm_configure.bin.
I then began to wonder, what if I replaced the contents of the first offset with my own backup.tar.gz? Thanks to binwalk, I know the exact structure and contents expected, so it would be quite trivial to extract it, modify the dropbear config (which is really all I’m interested in) and create a new tar archive with maximum compression like the original. Further more thanks to the documentation from James Hemmings, we know what happens to the this tar archive when it is present as this is visible in update.sh script in the firmware. The tar archive will be extracted to the router filesystem, giving me a potential way back into the router itself.
Well… Fortunately for me (and possibly unfortunately for Alcatel/EE) this is pretty much how I did it. By crafting a modified backup.tar.gz archive with the existing files within modified to my needs, I can hex edit my modified one over the original one in the configure.bin file as the payload to get config file changes applied to the filesystem!
I am only interested in having the dropbear config modified, so nearly all the original files in the backup have been left untouched but still present in my payload for safety. By erasing the existing data between 0x2D to 0x4DC2 (one byte before the second offset), this marks the “safe” area where I can put my payload into the configure.bin file.
BIG DISCLAIMER: The way I modified the configure.bin changes the second offset position, so the size of my payload compared to the original is not the same and adds more data. This means that the size of my configure.bin is several kilobytes larger in size. Normally with any file length checks, checksums or CRC, this would most likely fail. Good thing that there appears to be little to no checks around this area at all then!
The backup/restore functionality doesn’t seem to care or check the configure.bin in great detail, therefore I could get away with doing a very crude hex edit. If there were more checks in place, I’d potentially need to look at being more careful with sizes and possibly look at having to pad data.
Before uploading my modified configure.bin, I analysed it with binwalk and it still recognised the contents, with the exception that the first offset gzip archive is different (modified date) and the second offset is now at a different position, but I don’t really care about the second one, the config files within seems less important/critical for this purpose.
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
45 0x2D gzip compressed data, maximum compression, from Unix, last modified: 2020-05-22 14:00:26
20123 0x4E9B gzip compressed data, maximum compression, from Unix, last modified: 2020-05-22 13:43:29Likewise the modified configure.bin file was able to be extracted like the original and the contents seemed fine, not corrupted/damaged, so while the file itself is no longer the same as the original, it’s integrity was still in tact, enough to be extracted by tar on the command line successfully.
Uploading my payload
Based on everything looking as good as it can from my end. I risked it and uploaded my modified configure.bin file through the web interface because this seemed like the best chance I had. Admittedly, I really didn’t have much information on what checks (if any) were being done to the uploaded config file.
I figured if the file was going to be rejected, the web interface would error out immediately, if it was accepted, it could go one of three ways:
- The router would reboot and still work but reject the config
- The router would reboot and become soft bricked needing to be reset to factory settings (if the config files got screwed up).
- The router would reboot and SSH access will be enabled
The configure.bin uploaded was accepted and I was warned that the device would reboot, which is a common action when doing a config restore. I ran a continuous ping to monitor if my 4GEE Home Router was going to come back up or not after rebooting. After about a minute ICMP responses started happening, so that was a good sign (not dead, relief!). I then ran nmap to scan the open TCP ports:
root@linksys-wrt3200acm:~# nmap -sT 192.168.2.1
Starting Nmap 7.70 ( https://nmap.org ) at 2020-05-22 16:46 BST
Nmap scan report for OpenWrt.lan (192.168.2.1)
Host is up (0.0024s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open http(My 4GEE Home Router uses a different LAN IP/range from the default)
SSH was enabled again! What’s that password again? Oh yeah root:oelinux123. Also the admin account is admin:admin, even though the web interface password is different.
Now I have SSH access back, I can make it much more secure. I could start by using passwd to change admin and root accounts.
The original disclosure that led to the discovery of hard coded credentials in a binary (core_app), shows the modem side (192.168.225.1) of the 4GEE Home Router can be connected to via SSH with root:oelinux123, interestingly there are specific firewall rules blocking direct access to the modem through 192.168.225.1 in /etc/config/firewall .
root@4g-ee-router:~# strings /usr/bin/core_app | grep oelinux123
sshpass -p oelinux123 scp root@192.168.225.1:%s %s
sshpass -p oelinux123 scp %s root@192.168.225.1:%sThe most secure approach is enabling public key authentication with dropbear and disabling PasswordAuth entirely for the router itself, meaning the hard coded root credentials are less of a risk, although they will be forever baked in to the modem potentially, I don’t know the potential issues of modifying the password for the root user on the modem side. Because the OpenWrt filesystem is writable, we can configure this and such changes should be kept on reboots. Once public key authentication is working, you can go ahead and change the dropbear configuration file to this:
config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
option Interface 'br-lan'
option enable '1'
# option BannerFile '/etc/banner'Followed by reloading dropbear /etc/init.d/dropbear reload .
This will mitigate the security issue which got SSH disabled in the first place, but I get to keep SSH access and make it secure so it’s not just hanging on my LAN with itself exposed!
The security implications of the flaws in the backup/restore feature
So let’s talk security. I’m not a security researcher or pen tester, but like to dabble in that side, because it interests me. In my opinion, while the backup and restore feature can be exploited to overwrite existing config files and possibly inject user specific commands at startup or persistent custom code, there are several layers you need to go through to get to this point.
You would need:
- To be on the same physical network (LAN)
- To have access to the web interface and be able to authenticate to it
- To have enough knowledge to craft your own payload, which then you’d still need to have the level of access stated above to upload.
As far as I know the web interface is not vulnerable to CSRF/XSS, largely thanks to James Hemmings again, where he disclosed several possible CSRF vulnerabilities to EE for another Alcatel made product which were fixed and likely incorporated into firmware builds for the 4GEE Home Router, so bypassing the authentication part doesn’t seem likely.
There is a JSON-RPC API layer also which exposes backup/restore methods, but that also shares the same authentication mechanism with the web interface (needing a valid _TclRequestVerificationToken), so you would need to have a decent level of access already to abuse this for other purposes that aren’t necessarily for fun or experimenting.
The backup and restore functionality not performing file length checks, checksums or having a CRC built into the process is a potential problem for misuse though. Providing you have the ALCATEL BACKUP FILE HEAD at the beginning, it would seem the firmware is quite generous on what is accepted and then extracted to the filesystem on the router, there are ways this small window can be abused to essentially become a gaping hole, but it certainly isn’t the same as having hard coded root credentials baked into binaries. (naughty Alcatel).
My motivation was simply to have SSH access again so I could poke around and understand how this router worked more. Mission accomplished!
With my regained root level access I decided to poke around and document some of the inner working of this router/modem, I created a GitHub project with a wiki where I have documented key ares:
https://github.com/jamesmacwhite/hh70-ee
If EE happens to see this, please don’t be mad, I only wanted SSH access back, please don’t take it away :(. If you want, you can fix this issue and let me have a special firmware build with SSH enabled, that’s fair, right?! Hit me up for my IMEI, kthx.
