General Hardware info

Opening the box reveals a small user manual, and a card with translated English on tech support instructions for the router. The router itself has the following characteristics:

• Brand: Ancatus
• Product Model: A6
• Power: 12V ⎓ 1.5A
• Login IP: 192.168.10.1
• UserName: user
• PassWord: admin
• SSID: Ancatus_XXXX_2.4G/5G
• FCC ID: 2AYF5-A6
• It also has a SN and MAC.

Making the router accessible on the network

I’m not a networking expert. I spent more time than I’d like to admit figuring out why I was running in to issues plugging WAN from this router in to a separate switch to get the router to show on my network. I could be wrong, but I think routing equipment doesn’t do too well when it is acting in Routing mode and running it’s own DHCP while an upstream is the authoritative routing hardware.

Leaving WAN unplugged and connecting to it wirelessly from a laptop allowed me to get to the admin panel. Logged in, and found no way to configure this router for Bridge mode.

Recently, I’ve been playing around with manipulating the HTML of webpages. This led me to explore the HTML of this admin panel. Doing so reveals plenty of web elements with the following attribute:
style=”display:none”

Effectively hiding it from the standard user. Removing this styling reveals the element in the webpage. This can be done for the router’s Bridge Setting sub-menu to give us access.

Before	After

Now we can navigate to this menu item, Enable Bridge mode, Save, and reboot the router. Plugging WAN in to my networked switch gets the AX1800 an IP Address from my network’s DHCP server. I can now switch to tinkering with it from my desktop.

Searching for an attack surface

Navigating to “APP > Usb” reveals mention of an FTP server on the router itself. Yes, the UI can be difficult to navigate due to the translation.

So let’s crack open WinSCP and poke around this FTP server!

In root	In the dev folder

Doesn’t look like we can do much from an FTP standpoint with what we have right now. We’ll need to figure something else out. Let’s go back to looking through the webpages for any clues. Painstakingly unblocking any hidden webpage elements didn’t seem to reveal anything useful. Looking at the request headers does actually reveal something noteworthy though. It’s using Boa 0.94.13. Maybe there’s a CVE we can leverage?

How about CVEs?

That leaves the following list: CVE-2022-45956, CVE-2022-44117, CVE-2021-33558, CVE-2018-21028, CVE-2018-21027, CVE-2017-9833, CVE-2016-9564, CVE-2009-4496, CVE-2007-4915, and CVE-2000-0920. Based on the version our router is running, we can remove CVE-2016-9564 and CVE-2000-0920. I wanted to avoid jumping down rabbit-holes and spending way too long exploring each vulnerability. I ended up vetting what to try based on the descriptions. This leaves me with the following CVE’s to try out:

• CVE-2007-4915
  While this vulnerability seems usable, I wasn’t sure which password would be changed. It could be the router admin panel password, or a/the local account on the router itself. The former is irrelevant since we can change the password via the UI for the Admin panel user. The latter seems irrelevant since we can’t really connect to the OS of the router, so we have no surface outside of the Admin panel and the FTP server.
• CVE-2009-4496
  https://www.ush.it/team/ush/hack_httpd_escape/adv.txt
  As far as I can tell, this instance is not vulnerable. I don’t think I’d get a 404 if this worked.
  
• CVE-2017-9833
  https://pastebin.com/raw/rt7LJvyF
  This is (was at the time) disputed, and the primary argument stated the exploit was specific to whichever system integrator utilized a specific end-point, /cgi-bin/wapopen. This, wapopen.asp, and wapopen.cgi does not exist, therefore, this instance is not vulnerable.
  

Without uncovering a zero-day, I’m not sure the web server is a vulnerable attack surface. Back to the drawing board!

Enabling Telnet?

Some time ago, I thought I would want to install OpenWrt to get away from the horrible interface. That brought me to this thread:
https://forum.openwrt.org/t/adding-openwrt-support-for-ancatus-a6-wifi-6-ax1800-ax3/104649
At that time, I had seen a hidden link that was uncovered by anon69880279. This yielded something interesting, but I had no clue what to do with it years ago when I initially looked in to setting up OpenWrt:

This option was initially unchecked, so I enabled it, and went about my day.

My recent venture in to home-servering had me learn a bit about SSH, and noticed that PuTTY also had an option for Telnet. Let’s just plug this in and hope for the best!

Now this looks like something we can work with! However, I don’t have any credentials. I tried the admin panel credentials, and even the SSH credentials, neither of which gave me access. Going back to that article, I tried the credentials that I could skim from the few posts in the thread, but nothing.

A way in is found!

I don’t really have any tools or know-how for working with firmware and what I’m assuming are binary files, but I decided to download the firmware that was posted by Annick and see if I can get anything from it. The bootloader file is opened in Notepad++, and quickly realize that outside of the few strings sprinkled throughout, I was right about not having the right tools or know-how for this. I go back to the unzipped firmware I downloaded, and crack open the only none-binary file ./romfile.cfg.

Would you look at that, we get some passwords from this file. So I try the Telnet Entry username and password (remember earlier we enabled something to do with Telnet from that hidden menu?), and we end up with this:

We’re in!! I have no experience with telnet and the use-case, but this absolutely has to be something! Some cursory research shows that it is possible to initiate some file transfer via netcat, or even TFTP. I’m not sure I’d like to dive in to setting up an ftp server at this time, and it looks like netcat would work on one file at a time, and that would probably be considered torture.

Playing around with mount binds

On my home-server, I’ve set up a few mount binds for my docker containers. We also have an FTP Maybe we can set something up that way we’re not at the mercy of this minimal shell?

It appears netcat is not available, TFTP is, but more importantly, we might just be able to mount bind folders. We’ll need to find out what directory the working FTP server starts in.

In retrospect, there’s likely some kind of config file that would tell me exactly where this magical FTP process starts in, and if this is the case, you the reader are probably shaking your head at me right now. I wanted to just kill some time, so I created a dummy file with WinSCP, and just spent about 2 hours just manually traversing the filesystem with our good friends cd and ls. I eventually got a bit tired of just exploring this filesystem, and started to just check the primary culprits, and found it.

While writing this, I decided to check for a config for the ftp sever that would’ve made it much easier to locate, so I navigated to /etc/, ls -l | grep "ftp" reveals a bftpd.conf, with a couple of lines for ROOTDIR="/" and AUTO_CHDIR="/var/mnt". At least I had fun stumbling through this filesystem.

Leveraging the FTP server with mount binds

At this point, we can theoretically mount bind a directory and make it available via the running FTP server. All there is to do now is give it a shot! Let’s try mounting /boaroot/ to /tmp/mnt/dev/boaroot/:

I only know how to mount bind in Ubuntu Server 22.04, so I stumbled a bit getting it right here, but it’s there! And the best part (at least for me) is that I can now copy files out using WinSCP. Now I wonder if we can mount / as the target… But I’ve seen some talk about recursive mount binds, or something to that effect, and I think that there’s a chance it can cause some issues.

Mount binds don’t seem to persist across reboots, so maybe I’ll be okay to mount bind the root directory, and copy out all that I can from there? Second to worst case scenario is I have to reboot the router and hold down the reset button to get it back to factory settings and start over with what I know. Worst case scenario is something gets corrupted beyond repair and I end up with a ~3 pound paper weight of mediocre networking equipment.

Success!? I was able to copy out that boaroot directory I mounted earlier, I wonder if I’ll have luck doing a clean sweep of everything. I’ll be sure to not copy anything from /tmp/mnt/dev/root_dir/tmp/mnt/dev/root_dir/ as something tells me that could be dangerous.

Finding the most suitable method for extraction

Check-in while in the middle of poking around with WinSCP: It looks like trying to access /dev/root_dir/var/ results in no directory, which makes sense because it looks like var and etc are link-directories (if that’s a thing). /dev/root_dir/tmp/ is empty when opened in WinSCP, which kind of makes sense since that’s where the mount bind I’m using exists in, but I’ll keep moving forward.

Check-in #2: That romfile.cfg that got me access to Telnet contained reference to usernames and passwords, specifically Entry1 which looked like the matching credentials for the admin panel. Knowing that I had changed it from the default user:admin using the admin panel, I looked for whatever corresponding file would contain these same configurations. In the initial mount bind of boaroot, there was one file that didn’t copy over, and that was /boaroot/html/config.cfg.

Looks like I can now confirm this is in some way an active file. I don’t like the idea of a password stored in plain text, but I paid $70 back in April 2022. I don’t think it’d be fair for me to expect 100% rationality, see my previous comment about the UI/UX of the admin panel. To test this, I modified this password, and wrote it back to it’s actual home of /tmp/var/romfile.cfg. This actually did not yield a change in the login password as expected, so it seems like this file is not authoritative. Before I end up breaking something, I’ll just copy what I can out from the router using mount binds and WinSCP.

To be continued…

I’m certainly not done tinkering with this, but I wanted to put some information out there. Just in case there’s someone looking for information on this. This is very much a work in progress.