Tenda Malformed HTTP Request Header Processing Vulnerability
Author: Michelle Bonilla
Three months ago, I began my journey as a cybersecurity intern. For my first major project, my colleague and I set out to find a security flaw in a router. This was my first-time doing testing of this kind. I was curious and I did not know what to expect but was eager to learn. We went to our local Micro Center and searched through the selection of routers. While looking around we landed the Tenda N300 F3 wireless router and decided to test it since it was so affordable. Testing was a process that was tedious, challenging, and sometimes frustrating. However, I felt incredibly lucky to have been a part of this project and the experience I gained was priceless. For those of you who love a good spoiler click here.
Before I take you through my journey to this discovery, I want to talk a little about Tenda. According to their website, Tenda Technology was founded in 1999. They have two R&D centers located in China. They manufacture a variety of products such as switches, IP cameras, powerline adapters for internet data, etc. The N300 F3 wireless router was released in 2015 and the firmware version is V12.01.01.48. This is not the first time Tenda has had a vulnerability disclosed. Security analyst Sanja Sarda at Independent Security Evaluators (ISE) tested the AC15 AC1900 Smart Dual-band Gigabit Wi-Fi Router and found a total of five vulnerabilities.“These included insufficient request validation (CVE-2020–10986), insufficient data validation and sanitization (CVE-2020–10989), and a hardcoded telnet password (CVE-2020–10988). These vulnerabilities created a cross-site scripting (XSS) and cross-site request forgery risk, while two flaws (CVE-2020 10987 and (CVE-2020-TBA) opened the door to remote code execution and complete takeover” (Leyden 2020). ISE did notify Tenda about this issue in January however they have not responded. Additionally, Tenda has not patched these vulnerabilities leaving users unprotected.
Now that you have an idea of who Tenda is as vendor, let me walk you through the testing process. This part was fascinating to me but also made me want to throw my computer out the window a few times. This was indeed a challenge for an intern.
As with any security research project, reconnaissance is essential. Gathering information can provide clues and lead to identification of weak points. To begin, I performed a scan of the device using nmap. This tool is a free open source network scanner. It can be used to discover hosts and services on a computer. Once I identified the router as a host on the network, I ran a full port sweep which revealed that there were two open ports. These ports were TCP ports 80 and 1980.
Once the open ports were identified, I ran a deeper analysis of these ports using -O switch in nmap, which revealed that port 80 was running on version GoAhead WebServer and port 1980 was running on version Cisco Dp3828. However, we wanted to cross check this and see if we could uncover any other information.
We used Telnet in order to cross check nmap. We checked port 80 and Telnet identified the server as GoAhead-Webs which confirmed that the server was in fact GoAhead-Webs. GoAhead-Webs is a compact embedded HTTP webserver dating back to 1998. It is still very popular today, but vulnerabilities have been discovered. For instance, CVE 2019–5096 found that an exploitable code execution exists in the processing of multipart/form-data requests within the base GoAhead web server application. While this information did give us some insight, more research needed to be completed in order to find the vulnerability.
Next, we moved on to examining request headers using OWASP ZAP. We first wanted to understand how the login mechanisms worked. I examined the GET and POST headers and learned that once a user was logged in there was a cookie that stored the password encoded in base64. This cookie acts as a token that allows a user to perform any administrative tasks.
While logged in as administrator we downloaded the configuration file and fuzzed the cookie using a buffer overflow payload. What happened next was shocking. This allowed us to bypass authorization and the router’s configuration was returned in the response. This led us to believe that there was a buffer overflow vulnerability. Or at least we thought so…
By now I learned that the only way to confirm a theory was through testing and cross checking. In order to do this, we created a Python POC code with the same buffer overflow payload we tested in ZAP. We ran this code against a router, and it worked. Next, we tried taking the buffer overflow portion out and to our surprise the code still worked…
We then realized that the issue was never a buffer overflow vulnerability. It was instead an issue with how the GET request headers were being processed. While building the code we created a malformed GET request that we sent to the server. This malformed request allowed us to bypass authorization which then granted us access to the router’s configuration which contained its administrative password.
Let’s now take a closer look at the Python POC code. The code has a “-p” switch that can be passed as a command line argument. This switch executes the authorization bypass and allows us to obtain the password against the target router’s configuration file.
The code then calls a function that formulates a malformed GET request to the configuration file of the specified router. In this case the malformed GET request is GET /cgi-bin/DownloadCfg/RouterCfm.cfg? HTTP/1.1.
We then establish a socket connection to the target system. The hostname in this case is 192.168.0.1 on port 80. Here we sent the request through the socket connection
This request bypasses authorization and grants access to the router’s configuration. The base64-encoded password is pulled from the configuration file and decoded in plaintext.
Using the curl command line tool this code can be run and the issue can be reproduced. Typically, a HTTP header has different fields that has information such as acceptable media types and languages. Below, the GET request is simply GET /cgi-bin/DownloadCfg/RouterCfm.cfg HTTP/1.1. This request is malformed but is still being processed by the server, resulting in the authorization bypass, download of the config, and exposure of the password.
After extensive testing and research, we were able to identify that there was a Malformed HTTP Request Header Processing Vulnerability present. This vulnerability allows malformed request headers sent to the sever to bypass authorization. The server that is receiving the request is not properly processing the request as it should. It is every intern’s dream to be a part of a project where they are able to find a vulnerability of this kind. Initially I was intimidated and confused at times, but the end result was a gratifying moment. I wanted to note that other routers were also tested, and we found that this vulnerability is not limited to the N300 F3 model. Rebranded Tenda models are also at risk. We have contacted Tenda and informed them of this vulnerability. No response has been received as of yet.