This blog highlights bugs and observations found in the WiFi-extender Askey AP4000W during an Improsec “Nerd Day”. Found bugs are reported to the vendor according to our Responsible Disclosure Policy, but this time in close collaboration with TDC.
Timeline:
The vulnerability and observations of firmware “AP4100W_TDC_V1.01.003” were disclosed to Askey on 17th of September 2019. No response received.
The vulnerability and observations were disclosed to TDC on 27th of September 2019, as we knew they had customers running the product. TDC agreed to contact hardware vendor on behalf of Improsec, collaborate on getting it fixed, and getting customers updated.
During December 2019 TDC tested a new firmware from Askey for these devices.
Askey closed the insecure FTP-server 17th of December 2019, but we found it to be online again by 2nd of January 2020.
TDC confirms that a new firmware has successfully been deployed to all available devices on 28th of January 2020.
Insecure firmware FTP-server confirmed to have been secured on the 3rd of February 2020.
CVE registered:
CVE: CVE-2020-8614
Path to discovery
Connecting to and scanning the device with NMAP showed the following open ports.
When doing an NMAP service scan, the service running on port 54188 crashed and a reboot was required to bring it back up. A telnet daemon was also seen on port 23, however, no valid passwords were found for the typical users(root/admin/busybox) in the documentation.
Viewing the circuit board showed no visible UART or JTAG interfaces, but reading the model number for each integrated circuit showed that it contained a Winbond 25Q128FV EEPROM 16mb memory chip with SOP8 pinout.
Remote Code Execution by reverse engineering an Askey Wifi-Extender
By doing a direct EEPROM reading from the Winbond 25Q128FV using a CH341A USB-programmer with a SOIC SOP8 clamp, it was possible to extract raw data from the read-only memory.
A typical Busybox filesystem was extracted from the the raw data dump by doing multiple runs of Binwalk.
Insecure firmware server
In the ”/web” directory the web-based administration interface was located in the binary file “status.cgi”. Looking at the decompiled functions in Ghidra showed, that the application used ”wget” to fetch a new firmware from a FTP-server hosted by Askey. The credentials “Askeyfota” with the password “d400fota” were used. The new firmware would be saved to “/tmp/” which according to the ”/etc/fstab” file, would be RAM-mounted as R/W during boot.
Unfortunately, our analysis also showed, that the provided FTP-credentials had Read and Write rights to most directories on the manufactures FTP-server. This would allow an attacker to add, delete or modify firmware images for multiple different devices, amongst others, the Askey AP4000W (TDC branded). An attacker could i.e. implant a backdoor into the firmware, as there was no firmware signature validation in the update mechanism.
The mysterious ”bd_svr” service
Looking for the unknown service running on port 54188 the start-up script rcS at ”/etc_ro/” was enumerated. In it, an application called “bd_svr” was found.
Decompiling the “bd_svr” application in Ghidra showed that the main function called ”tcp_svr_create_socket” with the parameter 0xd3ac which was 54188 as a decimal value. This parameter was used to define the receiving TCP socket port 54188.
After creating the socket, the program enters the ”tcp_svr_select_n_handle” function which runs a ”while” loop waiting for client connections.
A quick look through the different functions in the program showed, that it possibly worked as a “backdoor” (bd_svr?) into the device. Functions with names like ”cmd_read”, “cmd_send”, “cmd_write” and ”send_file” indicated this. The program had the calls to system functions like ”lseek”, ”write”, ”lstat”, ”open”, “opendir” and “readdir” which were all functions to interact with the filesystem.
Writing to the remote file system
Looking at the ”cmd_n_data_send”, ”cmd_write”, ”cmd_send” and ”cmd_read” functions showed, that by sending a crafted message containing a “magic-signature” allowed any unauthenticated user to write files to the filesystem.
The crafted message required the following data fields and structure in order to be valid.
The following python script reads a user-defined local file and writes it to a path on the remote device. Note that most of the filesystem is read-only. Existing files in R/W mounted directories will be overwritten.
Below example overwrites ”/etc/passwd” with a version where both users have the DES-encrypted password set to “improsec”.
With a known username and password, connecting via telnet was now possible.
Remote code executing without telnet
Looking through binaries in the extracted filesystem showed an application called “cmd_agent”.
Reversing the application showed that it simply created an empty FIFO-file called ”cmd_agent” in ”/tmp/”. The file was constantly read for content, which was executed as console commands.
Rewriting our above script to ease the execution of commands on the device.
We already know that wget exists on the device. So using wget to send the first line of ”/etc/passwd” as a path will confirm that we have remote code execution.
The first line of ”/etc/passwd” containing the DES encrypted password for the root user.
Other research
Following the reverse engineering of the device, CVE-2014-0659 came to my attention. The backdoor described by elvanderb shares a lot of the same concepts as the one found in the Askey device. However, the “magic” signature, command type, functionalities, and service name differs.