Hacking a Netis WF-2404 Router with a Flipper Zero (cont.)

Day 3: A Quick, Unauthenticated Password Reset Attack

I was thinking about the flash command and I figured while I was working on a way to pull the entire firmware, it might be fun to play around with the flash set command (which was conveniently excluded from the help menu). After all, if I can set parameters that will be directly ingested by the firmware logic, then it is probably where I would test any sort of exploit payload.

The attack would go as follows:

1. Gain physical access to router

2. Connect UART probes

3. Set desired parameters

4. Reboot device

The first thing to check is whether or not this operation is blocked in some way. During the Day 2 investigation, I dumped what appeared to be the default user credentials. This was confirmed by some searching around. But I figured I should verify it myself, so I powered the router on and connected to the “netis” network. Then I navigated to 192.168.1.1, and was prompted with an HTTP Basic Authentication form.

I entered guest/guest, and sure eough, I was logged in.

As a quick, simple first attempt, I decided to reset the credentials for the admin server to test/test. I also changed the default credential parameters to keep the new credentials in place even if the router is reset to its default settings via the admin portal.

# flash all |grep guest
DEF_USER_NAME="guest"
DEF_USER_PASSWORD="guest"
USER_NAME="guest"
USER_PASSWORD="guest"
# flash set USER_NAME test
# flash set USER_PASSWORD test
# flash set DEF_USER_NAME test
# flash set DEF_USER_PASSWORD test
# flash all |grep test
DEF_USER_NAME="test"
DEF_USER_PASSWORD="test"
USER_NAME="test"
USER_PASSWORD="test"
# 

I rebooted the router and reconnected to the “netis” network. My serial console was also still connected so I first checked to make sure nothing was reset.

[...]
/proc/sys/net/ipv4/netfiter/ip_conntrack_tcp_timeout_close_wait: cannot create
253
254
cdrom_wizard start
255
Running ...
266
270
# flash all |grep test
DEF_USER_NAME="test"
DEF_USER_PASSWORD="test"
USER_NAME="test"
USER_PASSWORD="test"
# 

I navigated to 192.168.1.1, and entered the new credentials.

And we are back in with our new username/password combo!

So what are the main risks that contribute to this attack’s exploitability?

1. UART shell runs with root privileges without prompting for any authentication. And even the default credentials that exist for the root user are both trivially crackable and publicly verifiable.

2. The hidden, yet incredibly powerful flash command gives us direct access to sensitive parameters with generic names that are persistent after reboot.

You could argue that another risk is the lack of any physical security hardening measures (unless you count frustratingly tiny test points). But this is a personal-use router, so it feels like a bit of a stretch.

Other than that, I am not sure what else they can do. After all, storing the password as a hash instead of cleartext would make it more difficult to guess the current password, but an attacker could simply hash their desired password and replace it. Hardware security modules are not new by any means, but I also would not expect a 10 dollar router from 2010 to have one on the board.

Either way, we now have an easy avenue for payload testing. Let’s see what else we can find.