FiberHome AN5506-02-F router hack

I recently had to work with a home fiber router that was supplied by the ISP,  the FiberHome AN5506-02-F.

Compared to the previous internet access solution, which was based on a cable modem and required the user to use their own router, the new solution has both advantages and disadvantages. The advantages would be: integrated WiFi, security and firewall. The disadvantages: only one LAN port available (@100Mbps), only 2.4GHz (@150Mbps), outdated software, locked-down interface, no easy way to expose a second router.

The unit is very similar to the AN5506-04 model ( http://flytec.com.py/download/files/AN5506-04F-manual.pdf ), except it has only 2 UTP ports, only 1 phone port and no CATV interface.

Exposing the inner router

To get around the issue of the (old) router not being accessible from outside, the solution is to add that router into the DMZ setting. This is needed for things like web hosting, ftp server, some chat clients, torrents, etc.

You can log in with your supplied standard username and password, no need for admin rights for this. The usual link is http://192.168.1.1 . Write down your old router's MAC address, either from the 'Status -> LAN -> DHCP Clients List' or from its label.

Add the MAC address to the static leases list, just to be sure that the old router will always get the same IP. Might not be needed, but in case something happens you want to be sure that you don't expose the wrong host to the Internet.



Add the IP address from above to the DMZ zone.



Every time your IP will be accessed, the ports exposed to the outside will be the ones on your old router. Assuming the old one is more secure than the new router, this will also improve security.

There are also other ways to do this, but this one is the easiest. Not a hack, just poorly documented functionality.

Studying the firmware

The router home page uses a framed design, with the left frame (./left.asp) consisting on some hardcoded data and JS includes and the right frame being the active UI.



The hardcoded data is a crude state machine to select a different skin or menu structure based on the ISP values.
"checkResult" is the result of the login, with all values except 1,3,4,6,11 being accepted. So you can set it to 0 or 2 to signal the JS that the user is logged in. The check is only done in one place, utils.js, so you can set a breakpoint at the method entry point and override the value:



Each time the script pauses at that line, you can set the checkResult value to a valid one and press continue - most the pages will happily load. You can automate this process with a Tampermonkey script, which could override the security function with a dummy one:

web_access_check = function(i){}

We can already see two critical security problems: only client-side security and unique checkpoint.

Looking further into the request and responses (XHR) I could see that for this version of router/ISP an XML resource is being loaded:

Looks like the menu and submenu layout, this could have been deduced as well by looking at the JS code.
Changing 1.xml to 2.xml yields an advanced menu:

Tracing back how this XML is loaded, leads us back to another semi-hardcoded page:

Long story short, setting a breakpoint just before Frame.show() and setting curUserType to "2" will load the admin version of the UI.



The exposed menu items are not interesting for a normal user (they don't add features or increase speed or anything else) and can brick the router if modified.

I haven't played much more with this, but I suspect the unit might be susceptible to some basic attacks: directory traversal, RCE, privileges elevation, ...

There are some other topic that are left as an exercise for the reader: switching to different skins and languages, dumping the file system, finding out the admin username/password combo.