Welcome to the blog about the ZBT WE1626 Wireless Router CVE Disclosures! In this blog, we will discuss the recent vulnerabilities that have been discovered in the ZBT WE1626 Wireless Router. Specifically, we will cover the three vulnerabilities that have been identified:
In this blog, we will provide an overview of each of these vulnerabilities, including their potential impact and the steps that can be taken to mitigate them. We will also provide recommendations for users of the ZBT WE1626 Wireless Router on how to protect themselves from these vulnerabilities.
Remote Code Execution, also known as Arbitrary Code Execution, is a concept that describes a form of cyberattack in which the attacker can solely command the operation of another person’s computing device or server.
The ProDefense team has identified an endpoint on the ZBT WE1626 router, which can be exploited by an unauthenticated attacker to execute a WGET command on the local system.
Upon accessing the device using default administrative credentials, the team observed that the web application features Network Diagnostics functionality. This allows users to submit commands such as Ping, traceroute, NSLookup, and WGET to the system, as illustrated in the accompanying screenshot:
The team captured the request when hitting the submit button and stripped out all of the authentication keys and tokens in the original request and resubmitted. The team found that this endpoint for operation test_wget did not require the user to be authenticated to the router.
Request
Response
As indicated in the aforementioned request, the web application operating on the ZBT WE1626 router permits unauthenticated users to submit requests to the web API.
Subsequently, the ProDefense team conducted a review of the source code of the ZBT WE1626 router by extracting data from the flash chip. During the source code review process, the team discovered that the router’s web application verifies authentication via the local file system.
The primary web application user is designated as “root,” and the password is validated by the “passchk” binary, as illustrated in the following code excerpt:
Taking this into consideration, the ProDefense team developed a payload to overwrite the /etc/shadow file on the router, enabling them to modify the administrator password for the web application. To accomplish this objective, the team established a temporary AWS EC2 instance and hosted the designated payload through a basic Python web server operating on port 80.
Payload
The payload above is a replacement file for the /etc/shadow directory, which will update the password for the root user to “password”.
Following this, the team issued a request utilizing the WGET operation to obtain our payload hosted at http://pwn.prodefense.io/payload, and subsequently directed the WGET output to the /etc/shadow file system.
Request
Response
As is evident from the aforementioned response, the team was able to successfully overwrite the /etc/shadow file, and subsequently gain access to the web application without issue.
Request
Response
Upon logging into the web application, the user is provided with an access_token, which is stored within the system.
During the team’s examination of the device’s source code, they encountered an .sh file being executed within the set_4g() function. However, it is important to note that this function verifies the validity of the access_token.
In order to obtain the unauthenticated remote code execution vulnerability, the team exploited the arbitrary file write vulnerability by overwriting the start_4g_entry.sh file with a reverse shell payload.
Payload
The designated payload, which is hosted at http://pwn.prodefense.io:81/payload, functions by executing a reverse shell back to port 80.
To overwrite the start_4g_entry.sh file with the reverse shell payload, the team dispatched the following request:
Request
Response
The final step towards acquiring a reverse shell is to activate the set_4g() function in order to initiate the reverse shell payload.
To achieve this, the team issued the following request:
Request
* Note: The access_token was obtained by logging into the web application
Response
Upon establishing a connection to port 80 via their EC2 instance, the team was able to acquire a reverse shell as the root user.
Devices often include interfaces that provide access to consoles or direct access to the device’s processor and memory. Because of the sensitive nature of these interfaces, manufacturers may implement protection schemes that only enable debug interfaces under certain circumstances. If an attacker can easily figure out the scheme or identify a way to bypass it entirely, they would have access to debugging functionality that can allow them to compromise the device.
An Insecure Permissions vulnerability in Shenzhen Zhibotong Electronics ZBT WE1626 Router v21.06.18 allows attackers to obtain sensitive information via SPI bus interface connected to the pinout of the flash memory of the device. In addition, no signature validation is performed on the device’s firmware, allowing an attacker to redeploy firmware with an included backdoor.
To exploit this vulnerability, an attacker would need to utilize a SPI bus interface device and connect it to the pinout of the NAND flash memory. Connect the proper pins of the SPI bus by identifying the VSS, GND, MISO, MOSI, CS, and CLK pins of the ZBT WE1626’s flash memory.
Observe the serial number of the Winbond flash memory that was found from the hardware teardown and reconnaissance.
In Linux, the flashrom command is a utility that allows users to read, write, and verify the firmware on various flash memory devices. flashrom was used to extract firmware from this device’s flash memory by reading the contents of the chip and writing them to a file. To use flashrom, one must first identify the flash memory chip on the device and determine its pinout. Then, with the proper wiring and configuration, flashrom can be run to read and extract the firmware from the chip.
The firmware was unencrypted and all the filesystem information was not be protected by a password or other security measures. This makes it possible for anyone with access to the firmware to view sensitive files, such as /etc/shadow and /etc/passwd, in plaintext. This is a significant security risk, as these files contain sensitive information such as user passwords and can be exploited by attackers to gain unauthorized access to the system.
It is highly recommended to use a router that is secure and follows best practices for firmware validation and encryption to ensure the protection of your network and data. Routers with vulnerabilities such as unencrypted firmware extraction and lack of firmware signing validation can be easily compromised by attackers, resulting in security breaches and potential data loss. Therefore, it is crucial to prioritize security when selecting a router for a home or business network.
Devices often include interfaces that provide access to consoles or direct access to the device’s processor and memory. Because of the sensitive nature of these interfaces, manufacturers may implement protection schemes that only enable debug interfaces under certain circumstances. If an attacker can easily figure out the scheme or identify a way to bypass it entirely, they would have access to debugging functionality that can allow them to compromise the device.
To exploit this vulnerability, an attacker would need to utilize a UART serial adapter to connect to the device’s UART ports (TX, RX, and GND) at a baud rate of 115200 bits per second using a command like screen.
Once connected, powering on the device, will provide a command line shell as the root user through the listening screen command. Observe the following device setup and output below.
To connect the FTDI Friend to the UART ports of the ZBT Router, start by identifying the TX (transmit) and RX (receive) pins on both devices. Then, connect the TX pin of the FTDI Friend to the RX pin of the ZBT Router, and the RX pin of the FTDI Friend to the TX pin of the ZBT Router. It is important to note that when connecting devices together over UART, the TX and RX bits may be inverted, meaning that the transmit pin on one device should be connected to the receive pin on the other device, and vice versa. This can vary depending on the specific devices being connected, so it is important to check the documentation and pinout diagrams before connecting them together.
The team found the device provided full access to the system and could perform any action, including executing code with elevated privileges. In this case, the uid and gid (user ID and group ID) were set to root, which is the superuser account in Linux-based operating systems. This allowed the user to execute code with full privileges and potentially access sensitive system files and data. Finding a device with root permissions and elevated privileges can indicate a serious security vulnerability, and it is important to take immediate action to mitigate the risk and prevent unauthorized access.
We are a team of pentesters, securing the connectivity of devices and the software that controls them.
