Critically Insecure Router

I wanted to create a hardware pentesting sample report so when clients ask for a sample report I’m not giving them a web app one and saying “It’s like this but different”. I knew a cheap router from china would likely be insecure and make for a good report, I didn’t expect just how bad it would be! I bought the following router:

A £6 router! how is that even possible! Anyway, lets get started:

Stage 1: Preparing for Testing

Before any testing began, the device was examined to confirm it was functioning properly. Network activity was monitored using packet sniffing tools to detect any automatic firmware downloads or suspicious traffic. No unauthorised downloads were detected, suggesting a reasonable initial defence against remote attacks.

Stage 2: Physical Examination

The device was opened to inspect its internal components. This revealed various chips and debug interfaces that were crucial for deeper analysis. However, the chips had no identifying markings, making it impossible to find datasheets at this stage. Additionally, there was no FCC ID, which further limited available information on the components.

Stage 3: Accessing the Debug Console

Attention was turned to the RS232 debug port (top right of previous image). By connecting to this port, access was gained to the device’s debug console. This provided valuable insights into its operations and capabilities, revealing potential areas for further testing.

Stage 4: Extracting and Modifying Firmware

Attempts to access the flash chip’s contents using an inline clip were unsuccessful. The chip was removed from the PCB, and a socket was installed to enable quick removal and replacement for debugging.

Stage 5: Iterative Testing Process

The testing process was not strictly linear, previous steps were revisited based on new findings. Each discovery influenced the next phase of testing, ensuring a thorough evaluation of the device’s security.

Stage 6: Modifying and Re-Flashing the Firmware

In one of the final steps, the extracted firmware and bootloader were modified before being re-flashed onto the chip. This confirmed that unauthorised firmware changes were possible, posing a serious security risk. This test was performed last due to the high chance of bricking the device, which could have prevented further testing.

Issues Identified

The most likely aspect to be looked at by an attacker is the web interface as this would typically be the place an attacker has easy access to. The first thing I did after logging in was set the password to a single letter, yup could still log in with that so there is clearly no password policy. I then set it to “test”:

Of course theres no brute-force protection. Even worse, I could just browse to /wizard.html and there was no session checking whatsoever! as long as you know the endpoint you can browse to it and change the routers settings unauthorized. The “logout” button simply redirects to “index.html” which contains the login form.

It is worth mentioning here that along with the terribly coded/modified files the developer intended you to use to configure the device, lots of old files (oldbakhome.htm, countDownPage_old.htm) and Realtek default debug files and scripts were left on the device and were accessible and usable. Some of these disclosed the development environment used and paths on the dev’s computers. The device logs all wireless access points in the vicinity and devices that have connected to it including the mac address and device name. It appears these logs have not been wiped before manufacture and include developer devices used when creating and testing this router:

If you did want to know the password (perhaps the admin is using it elsewhere on the network) then use the “backup settings” feature to read it in plaintext. As demonstrated below you can clearly see the admin username of “admin” and the password of “SuperSecretPassword”:

Speaking of hardcoded passwords they were everywhere. After pulling the unencrypted firmware from the flash chip, it was easy to find JSON files containing credentials, shadow files, private keys, smbpassword file, etc. the hardcoded web app login password and wireless password were on a sicker on the router’s case. Not that you needed a password for access.

The router had telnet enabled by default. When trying to login with an non-existing username it asked for a password, however when trying to log in as root:

That is root access without a password enabled by default!

I then tried to modify the firmware and flash it back onto the chip, suprisingly there was a signature checksum that was failing since the firmware had changed, so I attempted to change the bootloader. This was possible however I didnt have time to work out how to either “NOP-out” the checksum comparison or work out how to generate a new checksum and put that into the bootloader. By default reading the output from UART the device responds:

The text “Pwned by Ross Marks” was modified from the original text “Realtek RTL8197F” in the following UART output by modifying the bootloader and flashing it onto the chip:

Challenges in Reporting the Vulnerabilities

One of the difficulties I encountered was the inability to obtain any CVE’s for the security issues I discovered. Normally, CVEs are assigned to known manufacturers and vendors, providing a way to track and address vulnerabilities. However, in this case, I was unable to identify a manufacturer for the device, making it impossible to report these issues through official channels. Without a clear vendor, there is no established process to ensure these flaws are acknowledged or patched, leaving the device vulnerable to exploitation with no accountability.

Conclusion

The device is not suitable for use and presents a major security risk. The number and severity of the issues mean that it cannot be trusted to protect sensitive information or maintain secure operations. Any organization or individual using this device would be exposing themselves to significant dangers, including data theft, system compromise, or even full control of the device by an attacker. Without urgent fixes, using the device in any professional or critical setting would be highly irresponsible, as it could easily be exploited.

Sharing is caring!