Tenda W15Ev2 AC1200 未授权RCE等多个漏洞（CVE-2022-40843 CVE-2022-40845 CVE-2022-40847 CVE-2022-41396 CVE-2022-41395 CVE-2022-42053 CVE-2022-42058 CVE-2022-42060 CVE-2022-40844 CVE-2022-40846）

# Vulnerabilities in Tenda's W15Ev2 AC1200 Router Reverse engineering Tenda's W15Ev2 AC1200 SOHO router discovering 10 0-days (10 CVEs) #### [Olivier Laflamme](/author/olivier/) Oct 19, 2022 • 33 min read Lately, after work, I've really enjoyed hacking and reverse engineering funky IoT devices. In early May of 2022, I went on a little Amazon/AliExpress shopping spree and bought ~15 cheap IoT devices. Among them was this compact SOHO router by [Tenda](https://www.tendacn.com/).  Shenzhen Tenda Technology Co., Ltd. hereafter referred to as Tenda is one of the leading suppliers of networking devices and equipment. Tenda has committed to delivering easy-to-install and affordable networking solutions, offering innovative, cutting-edge products to realize people's intelligent life. They are a Chinese company based in Shenzhen, China with R&D centers, in Shenzhen and Chengdu. Reportedly with over ~1000 employees they're fairly well established in the industry and offer a wide variety of products. The company's official website is [www.tendacn.com](https://www.tendacn.com/). The router I purchased was the AC1200 SOHO router model _W15Ev2_ with the [firmware V15.11.0.10(1576)](https://www.tendacn.com/download/detail-3762.html). The chip model for the device is `qca9531` (qca9531_wifi) by Qualcomm which is a 2.4 GHz System-on-a-Chip (SoC) that leverages a MIPS 24Kc processor. Performing a `GET` request on `/goform/version` or `/common/macro_config.js` identifies the firmware version. Out-of-the-box mine was `CONFIG_FIRWARE_VERION: "V15.11.0.10(1576)"` which was released **≤ **`2019-12-17`  Going to Tenda's firmware [downloads](https://www.tenda.com.cn/product/download/W15E.html) page confirms we're on their latest Chinese deployment. Due to the seeming lack of interest, I will only be testing the `V15.11.0.10(1576)` firmware.  * * * Multiple attempts were made through numerous communication channels to contact this vendor, but all failed. I try my best to act in a transparent, responsible, and consistent manner, with the goal of building a safer online space. In order to achieve this, I adhere to a 90-day time frame from the initial contact to public disclosure. If you have any ethical dilemmas or moral qualms as a result of this publication, I urge you to read the section entitled "Thoughts On Responsible Disclosure" situated towards the end of the blog to better understand the events, my perspective, and reasons for disclosure. ### Disclosure Timeline **July 18, 2022** : Vulnerability discovered and first reported **August 6, 2022** : Second attempt to make contact, further informing the vendor of the severity of the vulnerability **August 13, 2022** : WeChat & QQ attempt to contact the vendor **September 2, 2022** : A Third attempt to contact the vendor **September 13, 2022** : File for CVE assignment through Mitre.org **September 19, 2022** : File for additional CVE assignment through Mitre.org **September 26, 2022** : File for additional CVE assignment through Mitre.org **September 26, 2022** : Forth attempt to contact vendor, informing them of assigned 5 CVEs **October 3, 2022** : Fifth attempt to make contact, further informing vendors of the severity & number of vulnerabilities **October 10, 2022** : Sixth attempt to contact the vendor **October 17, 2022** : Final contact attempted & warning of public disclosure & confirming 10 CVEs had been assigned to their product **October 19, 2022** : Public disclosure * * * ### Vulnerabilities List A total of 11 vulnerabilities were identified in Tenda's AC1200 W15Ev2 router and IoT cloud gateway peripheral: ​ 1. Improper Authorization (CVE-2022-40843) 2. Password Disclosure (CVE-2022-40845) 3. Improper Access Control 4. OS Command Injection #1 (CVE-2022-40847) 5. OS Command Injection #2 (CVE-2022-41396) 6. OS Command Injection #3 (CVE-2022-41395) 7. OS Command Injection #4 (CVE-2022-42053) 8. Stack-based Buffer Overflow #1 (CVE-2022-42058) 9. Stack-based Buffer Overflow #2 (CVE-2022-42060) 10. Stored XSS in Website Filtering (CVE-2022-40844) 11. Stored XSS in Online Device Names (CVE-2022-40846) * * * ## **Web Application** ### Improper Authorization The Tenda AC1200 V-W15Ev2 router is affected by improper authorization/improper session management. The software does not perform or incorrectly perform an authorization check when a user attempts to access a resource or perform an action. This allows the router's login page to be bypassed. The improper validation of user sessions/authorization can lead to unauthenticated attackers having the ability to read the router's `syslog.log` file, which contains the MD5 password of the Administrator's user account. This vulnerability exists within the local web and hosted remote management console. The vulnerability affects version V15.11.0.10(1576). ### Vulnerability Details ​ CVE ID: CVE-2022-40843 Access Vector: Remote/Local Security Risk: Critical Vulnerability: CWE-287 / CWE-285 / CWE-228 CVSS Base Score: 9.9 CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:L This vulnerability is present locally out-of-the-box without any user/administrator configuration and remotely once an administrator user has enabled the "Remote Web Management" configuration as seen below.  Enabling this setting would allow the router's owner to manage the device from anywhere in the world via the provided public URL. Enabling this configuration creates a [ngrok](https://github.com/inconshreveable/ngrok) tunnel to a predefined `could.tendacn.net` subdomain. ​ ngrokc -Ser host:cloud.tendacn.net,port:4443 -AddTun type:http,lhost:192.168.0.1,lport:80,subdomain:6nyz4sf4 -Inf vlan2  Once enable the router can be accessed through the public web as seen below.  If you're wondering how many of these devices are configured like this, the answer is, thankfully not many. With some inefficient Google dorking `"*.cloud.tendacn.net:8080"` I was able to find `~18` devices configured with the cloud gateway. There is no way of ethically knowing what these devices are. > _DISCLAIMER_ > > If you go hunting for these hosts with any malice and start testing what you > see below, I'd consider your activities as active intrusion. Leveraging > vulnerabilities against hosts you do not own is NOT something I endorse & is > unethical. > Subsequently, all traffic that passed through 6nyz4sf4.cloud.tendacn.net > did not target anything other than my own device. I was not directly > attacking or affecting the availability & integrity of the public/reserved > gateway. > *.cloud.tendacn.net is only a public-facing tunnel to the router I own. > Traffic passing through this public-facing proxy is simply passed as regular > traffic/requests. Additionally, I never attempted or performed any > reconnaissance or automated tests against cloud.tendacn.net. The vulnerability in & of itself stems from a complete lack of proper session token generation & the presence of authentication levels that should be expected from a cookie. The following images will help demonstrate this. After logging into the device, the user is provided with the following cookies. ​ Cookie: bLanguage=cn; _:USERNAME:_=admin; W15Ev2_user=admin However, both the `bLanguage=cn;` and the `_:USERNAME _:_ =admin;` cookies are not required. Additionally `W15Ev2_user=` can simply be left blank.  As seen below you do need the `W15Ev2_user=` cookie or else you'll be redirected to the login as seen below, which is quite interesting.  This obviously isn't good. As seen in 2 images above, I was able to fetch the `/syslog.log` which should only be viewed/accessible once authenticated.  This endpoint can leak the admin login event containing the base64 password of the administrator user. This can easily be leveraged to gain access to the device. As seen below we have the ability to perform this both locally or remotely via our assigned Remote Web Management endpoint. To demo, we'll perform a GET request on `/goform/downloadSyslog/syslog.log` with the cookie set to `W15Ev2_user=`.  Scrolling down (this is a big response) we'll see any failed/successful login attempts. Successful attempts will contain the base64 encoded admin password.  The curl of exactly the same request is seen below. Some people don't seem to always trust Burp Suite/might think my target is pointed at my localhost. (Not that it would invalidate the vulnerability)  If you take the time to decompile the `httpd` binary the culprit is the `authSecurityHandler` function that I won't be going into here & will leave as an exercise to the reader. You might be thinking _"yeah, but who cares"_? __ With access to the router, you're able to perform internal network scans, obtain the wifi's PSK, set up your own port forwarding, etc,. Other attacks can be chained with this "improper session management" to perform command injections and obtain a shell on the device. Although unlikely, it would suck to see a small-medium-sized company use one of these devices as a random & cheap AP/Switch for a small cluster of employees, thinking it was inherently safe. * * * ### Password Exposure The Tenda AC1200 V-W15Ev2 router is affected by a password exposure vulnerability. When combined with the improper authorization/improper session management vulnerability, an attacker with access to the router may be able to expose sensitive information which they're not explicitly authorized to have. This is performed via a direct request to `/cgi-bin/DownloadCfg/RouterCfm.cfg` without authorization. This vulnerability exists within the local web interface and the hosted remote web management console. An attacker would be able to retrieve a subset of passwords via this technique. The vulnerability affects version V15.11.0.10(1576). ### Vulnerability Details ​ CVE ID: CVE-2022-40845 Access Vector: Remote/Local Security Risk: High Vulnerability: CWE-200 CVSS Base Score: 8.8 CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H Like the previous vulnerability, this can be performed both locally or remotely through the `cloud.tendacn.net` proxy tunnel. Generally, downloading backups could only be performed once authenticated.  However, there isn't a need to have the device initiated to perform this. At its core, a backup file containing hashes of users' passwords, PSK's, etc. can easily be downloaded. This is generally considered bad hygiene/practice. Realistically, the impact on organizations depends on many factors that are unique to each organization. You can decide this for yourself when presented with the information a little further down. I was a little confused at first, I didn't think this router had a CGI interface. Taking a step back, I dug up this endpoint when scouring through the firmware dump. It's a weird subset that is mainly defined to make executables on the server respond to web requests.  For all three requests seen in the images below this is more-or-less the action's performed in the backend.  Here is the attack being performed locally with Burp Suite.  Remotely with Burp Suite.  Remotely with the curl command.  The crucial information obtained is listed below. ​ sys.rzadmin.username= rzadmin sys.rzadmin.password= cnphZG1pbg== (rzadmin) sys.rzadmin.password.decoded= r***n wlan0.0_bss_wpapsk_key= this_is_my_super_secret_ssid_password sys.admin.username= admin sys.admin.password.decoded= t***d sys.admin.password= = base64 PSK usb.share.gst0.user= guest usb.share.gst0.pwd= guest sys.guest.password.decoded= g***t sys.guest.password= Z3Vlc3Q= (guest) * * * ### Improper Access Control The Tenda AC1200 V-W15Ev2 router is affected by improper access control. An attacker can start telnet without authorization by performing a `GET` request to the `/goform/telnet` endpoint, spawning the `telnetd` service on the device. This service is password protected; however, the default account credentials were identified as `root:Fireitup` which can be used to successfully login. The vulnerability affects version V15.11.0.10(1576). ### Vulnerability Details ​ CVE ID: N/A (Already assigned to CVE-2018-5770) Access Vector: Remote/Local Security Risk: High Vulnerability: CWE-287 / CWE-284 CVSS Base Score: 8.4 CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H There's not much to explain here. As seen below the device doesn't ship with telnet natively being spawned nor is it defined in `init.d`.  A simple `POST` request to `/goform/telnet` will start telnet as seen in the requests below.  Interestingly, this can be performed through the ngrok tunnel. However, I've deemed that this endpoint is out of scope as I'm not 100% confident this relays back to my device due to the unfamiliar motd.  As seen below telnet is now up and accessible.  I did some digging to identify the telnet password. The earliest mention I could find dates back to 2017 from [this](https://www.linksysinfo.org/index.php?threads/tenda-ac15-ac1900-tomato- firmware-support.71709/page-7) forum by user Chaos99. This was for the AC15 and we've got an AC1200.  This doesn't seem to matter. As seen below, Chaos99 was right; the password is still `Fireitup`.  I did some digging to identify anything else that can be invoked via `/goform/*` but there doesn't appear to be anything of value.  * * * ### **OS Command Injection #1** The Tenda AC1200 V-W15Ev2 router is affected by an OS Command Injection vulnerability that allows an authenticated attacker to run arbitrary commands on the affected system as the application user. This vulnerability exists within the ping function `formSetFixTools`. This is the result of improper input validation passed through the `hostName` parameter. This vulnerability exists within the local web interface and the hosted remote web management console. The vulnerability affects version V15.11.0.10(1576). ### Vulnerability Details ​ CVE ID: CVE-2022-40847 Access Vector: Remote/Local Security Risk: High Vulnerability: CWE-78 CVSS Base Score: 7.8 CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H This command injection vulnerability was discovered through the serial logging. These logs were viewable by simply connecting to the router's UART interface.  If you're wondering why the serial interface is sending out all of our logs and actions, I'm not 100% sure. I'm assuming it's so that application-specific errors can be sent to the log using some API methods. Without this serial logging, I'm not sure I would've discovered this command injection vulnerability. I somewhat got lucky and have a methodology that leads to these discoveries. I initially fizzed the `hostName` parameter with Burp Suite intruder using a mix of custom and common command injections mainly found in this [GitHub](https://github.com/omurugur/OS_Command_Payload_List/blob/master/OS- Command-Fuzzing.txt) repository. It just so happened that I was paying attention to my serial connection terminal at the right time.  As seen below, the `hostName` parameter of the `setFixTools` is responsible for performing ping diagnostics and is vulnerable to OS command injection. The following payload was injected into the vulnerable `hostName` parameter `$(`cat /etc/passwd`)`. Once the request was sent, the contents of the `/etc/passwd` file was returned via the serial console.  Digging deeper was quite amusing. The `$PATH` variable was blank but ~10% of native UNIX commands still appeared to be working.  I sent the two following `POST` requests to fix this issue. ​ $(`PATH=/sbin:/bin:/usr/sbin:/usr/bin/`) $(`export PATH`) As seen below we now have proper path variables.  How will we get a shell? If we look at all the commands at our disposal, we don't have `nc`, `netcat` and `wget` is in fact a broken binary in the system. Additionally, this is not a standard shell `enable` and `compgen -b` which always exist aren't there (if you know, you know). We have `/bin/busybox` and by listing its capabilities, we discover that we have `telnetd`!  We can leverage our command injection to start `telnetd` with the `-l` flag pointing at `/bin/sh` to obtain a root shell without needing the telnet username and password. Our attack path consists of the following 5 steps: ​ Step #1 - identify telnet pid - we can't use `|` or `&&` or `;` Payload 1: 'ps >/tmp/a' Step #2 - move it to webroot so we can get it Payload 2: 'cp /tmp/a /var/webroot' Step #3 - kill telnetd if its alive Payload 3: 'kill -9 PID' Step #4 - copy sh executable in pwd Payload 4: 'cp /bin/sh .' Step #5 - restart telnetd binded on sh Payload 5: 'telnetd -l sh' First, we'll pipe the contents of the systems processes into a file in `/tmp`.  We'll then move our process listing into the webroot so we grab and analyze its contents.  Go to `192.168.0.1/a` to retrieve the file.  Telnet is currently running with a PID of 3718. However, this telnet is no good because we need to know the credentials for it. So we'll kill this process.  We'll then move the `sh` binary to our current working directory.  Lastly, we'll invoke `telnetd` with the `-l` flag set to execute `/bin/sh` at the login/connection attempt.  Now we should just be able to telnet without requiring a password.  Tada. * * * ### **OS Command Injection #2** The Tenda AC1200 V-W15Ev2 router is affected by an OS Command Injection vulnerability that allows authenticated attackers to run arbitrary commands on the affected system as the application's user. This vulnerability exists within the IPsec router configuration, specifically via the `/goform/module` function `setIPsecTunnelList`. This vulnerability in part requires the router's VPN server to be enabled (which it is by default but can be disabled). At its core, the `httpd` binary contains the vulnerability and can occur when a malicious `formSetIpSecTunnel` parameter gets processed. During this process, inner process communication is established through the `netctrl` binary. This vulnerability is the result of improper input validation passed through the `IPsecLocalNet` or `IPsecRemoteNet` parameter. This vulnerability exists within the local web interface and the hosted remote web management console. The vulnerability affects version V15.11.0.10(1576). ### Vulnerability Details ​ CVE ID: CVE-2022-41396 Access Vector: Remote/Local Security Risk: High Vulnerability: CWE-78 CVSS Base Score: 7.8 CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H In the `formSetIpSecTunnel` function, both the `IPsecLocalNet` and `IPsecRemoteNet` parameters are passed directly to the application, which can be manipulated by the user. The _Local_ (`IPsecLocalNet`) and _Remote_ (`IPsecRemoteNet`) network parameters can be maliciously injected into. To understand what's going on, we need to reverse the application a little. This vulnerability occurs in the `setIpSecTunnel` function. Below, we enter the function `getIpSecTunnelSettings` and the rabbit hole begins.  The parameters that receive our JSON user input are in the function `getIpSecTunnelSettings`.  In the `setIpSecTunnelSettings` function, the input has not been checked. And then a call to the function `prod_cfm_set_init_val` is made to store this input.  These are the function parameters passed through the `POST` command. But what's actually happening in `setIpSecTunnelSetting`? It isn't immediately apparent, but at the end of this decompilation there's a pretty significant block of code related to, and required for inter-process communication. This all happens in another binary that handles the passed input, leveraging the contents through other functions that write this new data and changes to the flash. Therefore, to see how we can inject, we need to look at that binary. After a little digging, it was discovered that the vulnerability would be triggered in `netctrl`. If we want our `IPsecLocalNet` or `IPsecRemoteNet` input to be extracted, we have to have one of the following protocols initiated.  I've had success with triggering this command injection by setting the `vpnServerType` to `l2tp`. However, this VPN stuff is all initiated by default and should just work out of the box with PPTP.  When you successfully write to the flash and `racoonmtc` gets initiated with the valid injection contents, then you know you've performed this successfully. Over the serial log, this looks like the following.  Inside the `netctrl` binary, looking at the `vpn_ipsec_ini` function, the initial input will be extracted and injected into `%s`, which is how we will achieve our code execution. We can further use command separators to escape the `iptabes` command.  Let's visualize this by moving to a GUI. The front-end vulnerable input is tagged as "Remote Internet" and "Local Internet" which maps to `IPsecLocalNet` and `IPsecRemoteNet` respectively.  To test that we have command injection let's enter a random string and see `/bin/sh` attempt to execute it.  As we can from the serial log, "badcommand" is not a valid binary.  If you mess up you'll have varying verbose output. Here are a few examples you can use to better craft a more sophisticated payload.  Let's try starting telnet using this command injection.  Viewing the serial log for this request shouldn't contain `/bin/sh` errors. As seen above and below, `telnetd` has been successfully started.  Tada.  * * * ### **OS Command Injection #3** The Tenda AC1200 V-W15Ev2 router is affected by an OS Command Injection vulnerability that allows authenticated attackers to run arbitrary commands on the affected system as the application's user. This vulnerability exists within the DMZ router configuration, specifically via the `/goform/module` function `setDMZ`. The vulnerability was identified in the `netctrl` binary tracing preprocessing calls from the `httpd` binary. This vulnerability is the result of improper input validation passed through the `dmzHost` parameter. This vulnerability exists within the local web interface and the hosted remote web management console. The vulnerability affects version V15.11.0.10(1576). ### Vulnerability Details ​ CVE ID: CVE-2022-41395 Access Vector: Remote/Adjacent Security Risk: High Vulnerability: CWE-78 CVSS Base Score: 7.8 CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H Continuing the investigation into `netctrl`, the culprit for the injection above, I ended up finding more injections. In the `formSetDMZ` function, `dmzHost` can be directly passed by the attacker. If we can control the `dmzHost` input, presumably we can attack the system. Looking into the `httpd` binary seen below, the JSON-provided input doesn't get checked or sanitized. After that, it calls the function `prod_cfm_set_value` to store this input. So the parameter `dmzIp` is what we're looking to inject into it.  The `netctrl` binary `advance_set_dmz_cfg` function's input will grab the provided input passed to it by `httpd`.  Eventually, in the `advance_set_dmz_cfg` function, this unchecked input could be leveraged to perform command injection when passed through `%s`. Looking at this in Burp Suite, we'll modify our injectable `dmzHost` parameter. We're testing with fake binary to see what gets acted on it/the errors we receive.  The `POST` request above will ultimately write these new configs to flash. Below you'll also see `/bin/sh` try and run the `boschko_is_hacking` binary, and fail because doesn't exist.  This is great information, we more or less know we should be able to spawn `telnetd`. As seen below telnet wasn't running a few seconds prior and then was. Disregard the date I'm too lazy to go change it.  * * * ### **OS Command Injection #4** The Tenda AC1200 V-W15Ev2 router is affected by an OS Command Injection vulnerability that allows authenticated attackers to run arbitrary commands on the affected system as the application's user. This vulnerability exists within the Port Mapping router configuration, specifically via the `/goform/module` function `setPortMapping`. The vulnerability was identified in the `netctrl` binary tracing preprocessing calls from the `httpd` binary. This vulnerability is the result of improper input validation passed through the `portMappingServer` parameter. This vulnerability exists within the local web interface and the hosted remote web management console. The vulnerability affects version V15.11.0.10(1576). ### Vulnerability Details ​ CVE ID: CVE-2022-42053 Access Vector: Remote/Local Security Risk: High Vulnerability: CWE-78 CVSS Base Score: 7.8 CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H At this point, you get the idea. I just kept looking at the `netctrl` binary and stumbled onto the `advance_set_port_map_cfg` function which looks a lot like our previous command injections.  The port mapping front-end looks like this, it's nothing crazy, so let's have a look at this request in Burp Suite.  We're going to skip reversing the preprocessing from `httpd` to figure out which parameters are getting passed. We can use our better judgment to make an educated guess that the `portMappingServer` might be injectable.  In the image above we're starting the `telnetd`, which was previously not running seconds before. Looking at the serial log, we're presented with familiar error messages.  Fun little fact. If we didn't own the hardware and were emulating `httpd` off of qemu it would be tedious work to find the proper web request and would require properly reversing the `httpd` binary. However, I actually found [this](https://www.zybuluo.com/moshangxc/note/825998) enterprise documentation which perhaps unintentionally leaks the router functions?  Regardless, this is nice to have. * * * ### **Stack Buffer Overflow #1 ** The Tenda AC1200 V-W15Ev2 router is affected by a stack-based buffer overflow vulnerability that allows an unauthenticated attacker to run arbitrary commands on the affected system or cause a denial of service. This vulnerability exists within the "Remote WEB Management" router application, specifically via the `/goform/module` function `setRemoteWebManage`. The vulnerability was identified in the `netctrl` binary tracing preprocessing calls from the `httpd` binary via the vulnerable `remoteIP` parameter. This vulnerability is the result of mismanaged memory allocation. This vulnerability exists within the local web interface and the hosted remote web management console. The vulnerability affects version V15.11.0.10(1576). ### Vulnerability Details ​ CVE ID: CVE-2022-42058 Access Vector: Remote/Local Security Risk: Medium Vulnerability: CWE-121 CVSS Base Score: 5.3 CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H The entire remote web management gateway piqued my interest early on. I decided to dig into it thinking that I might find a command injection vulnerability.  Going back to the `httpd` binary, running through `main_init` we discover `FUN_0043c7b4`, a function containing which contains the `formSetRemoteWebManage` which sounds like it might relate to "Remote Web Management", our target.  As seen below, in the `formSetSafeWanWebMan` function there exists the `remoteIp` parameter which is passing whatever is supplied. At first, I thought that this was a good start, if we can control the `remoteIp` value there's a potential to obtain command injection.  As you can see above, the input isn't getting checked. After which a call to the function `SetValue` stores the input into `wans.wanwebip`. Let's figure out how this is all handled in the `netctrl` binary. After a bit of digging, I discovered that the `advance_get_wan_access_cfg` function is where the input will be extracted.  After this, the `advance_set_wan_access_cfg` will use the input to write the contents of the `POST` request to the flash. As you can see below the input from `remoteIp` should be passed into `%s` copying our command to the stack buffer.  So if we attempted to run `telnetd` we'd run the following `POST` request.  Looking at the serial logs, it doesn't quite work. After a lot of failed attempts, I came to the conclusion that there is no real way of escaping the `[ ]` brackets no matter what type of delimiters you use.  At this point, I quickly glanced at the `advance_set_wan_access_cfg` function and noticed that the stack buffer was only `256 bytes`. If you go back up to the previous screenshot you'll notice that the function doesn't check the value of `iVar2` and simply calls it, which copies the POST parameter `remoteIp` to stack buffer `acStack520`.  We should be able to crash this. I ended up overwriting the buffer with `~2000` characters the image below is `629` characters and intended to be more legible to the reader.  This causes a crash as seen below, the banner `****** WeLoveLinux ******` is displayed every time the device boots up, and crashed immediately after.  I've decided to remove my Golang and Python POCs. This is purely a DoS and my aim isn't to enable and commoditize DoS attacks. The router crashes and cannot provide services correctly and persistently. The real question is how realistic obtaining a stable root shell through a carefully constructed payload would be. Let's find out. I'll be giving this a go from my QEMU + GDB debugging environment using the firmware I dumped from the SPI chip on the board.  As you can see above, we have a little problem with `cfms_mib_proc_handle`. When running the program directly, it will output WeLoveLinux, and then it will crash/not initiate. I'm guessing that it has entered a state of suspended animation. I'll use IDA for this next part because if I have to patch it I don't know how to do it with Ghidra. After a bit of digging to find the position where the string is used and set a breakpoint, then stepping through until something weird happens. I'm speculating that the culprit is this function, which is connected to a service that should return 1 under normal circumstances.  When we use the environment simulated by QEMU, it will return 0 if it cannot connect to the relevant service. We need to patch manually. I did this in IDA using the [keypatch](https://github.com/keystone-engine/keypatch) plugin to patch the return value to 1.  However, even with this patch set, it's not working. I'm almost 100% sure it should. Regardless, although upsetting, I decided not to peruse this any further. * * * ### **Stack Buffer Overflow #2** The Tenda AC1200 V-W15Ev2 router is affected by a stack-based buffer overflow vulnerability that allows an unauthenticated attacker to run arbitrary commands on the affected system or cause a denial of service. This vulnerability exists within the Internet Settings, Interface Types application. It's leveraged via the `/goform/module` function `setNetwork`. This vulnerability is the result of mismanaged memory allocation. The vulnerable parameters are `wanUser` and `wanPwd`. This vulnerability exists within the local web interface and the hosted remote web management console. The vulnerability affects version V15.11.0.10(1576). ### Vulnerability Details ​ CVE ID: CVE-2022-42060 Access Vector: Remote/Local Security Risk: Medium Vulnerability: CWE-121 CVSS Base Score: 5.3 CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H I'd like to start by saying that this overflow was quite tricky to understand given that I'm doing this statically. It would be much easier to debug this dynamically in my QEMU + GDB lab. As seen in the previous overflow, I wasn't "properly" patching `ConnectCfm`, so I'm stuck with this suboptimal method. This stack buffer overflow is part of the Broadband Dialup configuration, which is part of the WAN device configuration. Point-to-Point Protocol over Ethernet (PPPoE) is a type of broadband connection and therefore is referenced as such. Initially, I thought the overflow stemmed from the screenshot below. From the `setWanPppoe` function, where the application reads user input into `uVar1` and `uVar2` without doing any proper length checks.  This turned out not to be the root cause. looking at the above, a crash could happen when it takes the address of `local24` and stores our user-provided JSON string into it, overflowing the `local_20`, `local_1c`, `local_18`, etc. I presume that `iVar5-9` are all status code checks. However, if `prod_cfm_set_val` returns `0` on success, this check seems to be irrelevant. I later came. to the conclusion that this wasn't the case, and that something else was responsible for the behavior observed further down. Going along with this initial presumption, all of this information is called upon when the configs are pushed to flash, which is performed as a result of the following `POST` request with the below UI as input.  I decided to flood the `wanPwd` parameter `Broadband Password` with a bunch of `AAAA` characters. Which caused a crash.  So, the device crashed and rebooted not long after. What could be happening here? There are at least two ways the overflow could occur. It could occur if the password ever gets decoded. It could also happen if the program reads the user input into a variable without proper length checks, and writes it into memory. Again, without the ability to attach GDB to the `httpd` process, it's really hard to reverse. I'd also like to mention that there are confusing behaviors in the `add_pppoe_config` function that occurs as part of `formGetNetwork` that may have obstructed my understanding of the entire BOF chain. My final verdict is as follows, and it will make more sense when watching the POC video. The overflow process is: `user input` => `setWanPppoe` => `getPPPoEConnectStatus` => `crash` A boiled-down explanation of what happens is: 1. JSON user-provided inputs get passed into the WAN config `setWanPppoe` a function that reads user input into `uVar1` and `uVar2` without doing any proper length checks. 2. At some point `getPPPoEConnectStatus` accepts input from **** (presumably from `setWanPppoe` via `prod_cfm_set_val`) which reads the unchecked user input during which it calls `FUN_00447674` (renamed `CredentialCompareFunction`) that stores the user-provided input with `sprintf` to the char buffer. 3. A check on the validity of the credentials is performed at which point the overflow happens.  It actually takes a dword parameter WanID (which is a value wanNum=3) and stores it into `acStack264` (renamed UserPasswordString) this WanID stems from another function, `FUN_00447828` which is also invoked by the main credential check of the `getPPPoEConnectStatus` control flow specific to dialup initiation/integrity checks from a generated `/etc/ppp/wan%d_ppoe_auth_code`file at startup.  Here's a video POC where you can see this in action. This BOF acts as a DOS and completely debilitates the router once the function is processed ~10 seconds after boot/login. I won't be including a Golang or Python POC. This is purely a DoS and my aim isn't to enable and commoditize DoS attacks. Just like in the video, as soon as the device is logged in, it crashes and reboots in a perpetual never-ending cycle.  What made reversing this so much harder was not having a way of knowing what library functions were actually being imported. As you can imagine, this makes reversing all the more confusing.  The blog is getting ridiculously long, so I will stop digging for these. If you follow `prod_cfm_set_val` you're bound to find another ~10 buffer overflows. It's honestly a clown fiesta. * * * ## **Stored Cross-Site Scripting** The Tenda AC1200 V-W15Ev2 router does not perform proper validation on user- supplied input and is vulnerable to cross-site scripting attacks via the homepage's connected application hostname field. If a proper authorization mechanism was implemented, this vulnerability could be leveraged to perform actions on behalf of another user or the administrator. This vulnerability exists within the local web interface and the hosted remote web management console. The vulnerability affects version V15.11.0.10(1576). ### Vulnerability Details ​ CVE ID: CVE-2022-40846 Access Vector: Network Security Risk: Medium Vulnerability: CWE-79 CVSS Base Score: 6.5 CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N On the homepage, an administrator will have the ability to see the top 5 devices that consume the most network resources. They'll also have the ability to rename these hosts. I attempted the following payload, which failed. ​ <script>alert(1)</script> However, if you look at the page's source, it would be reasonable to assume that you could trigger a valid XSS by prepending `">` to your payload.  Since I'm testing in Firefox ill be using `marquee` tags, my payload can be seen below. ​ "><marquee onstart=alert(document.cookie)> In the page source the `title` string is now "handled" properly and closed leaving our malicious javascript outside of the element.  Here's a little Burp Suite visual differentiating the two requests.  The QOS's requests will trigger every ~15 seconds. This is to obtain more accurate statistics of the hosts such as upload/download rates. This will call upon the hostname perpetually prompting the XSS triggering.  As seen below the XSS successfully triggers returning of the session cookies.  * * * ## **Stored Cross-Site Scripting** The Tenda AC1200 V-W15Ev2 router does not perform proper validation on user- supplied input and is vulnerable to cross-site scripting attacks through the web filtering group body. If the proper authorization was implemented, this vulnerability could be leveraged to perform actions on behalf of another user or the administrator. This vulnerability exists within the local web interface and the hosted remote web management console. The vulnerability affects version V15.11.0.10(1576). ### Vulnerability Details ​ CVE ID: CVE-2022-40844 Access Vector: Network Security Risk: Medium Vulnerability: CWE-79 CVSS Base Score: 6.5 CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N There's another stored XSS in the Website filtering functionality. Navigating to the panel of "Website Filtering" you'll see the following.  Clicking on the "URL management" panel will pop-up the following window.  Anything injected within the URL body will reflect once its associated group name is clicked in the panel before. Pretty much any javascript here will work. When I test in Firefox I personally prefer using Firefox-specific payloads such as `<marquee onstart=alert(1)>` for testing. Since I don't blog a lot, I'll share my favorite payload which leverages the movie/video content tags which are never really filtered. Some of my goto payloads can be seen below and all work within this application. ​ <video controls oncanplay="alert(document.cookie)"><source src="http://mirrors.standaloneinstaller.com/video-sample/lion-sample.mp4"></video> <img src="test" OnError=prompt(document.cookie)> <img src=x onerror=&#x61;&#x6C;&#x65;&#x72;&#x74;&#x28;&#x64;&#x6f;&#x63;&#x75;&#x6d;&#x65;&#x6e;&#x74;&#46;&#x63;&#x6f;&#x6f;&#x6b;&#x69;&#x65;&#x29;> Once the popup is saved, one way to trigger it is to single-click the element as seen below or set it to an IP group config.  * * * ## When Will it be Enough? If I had to make an educated guess, I'd say there are roughly another ~10-15 CVEs laying around in the application. I won't personally be perusing them. Why? 1. I'd like to spend my time reversing something a little more entertaining. 2. Due to not having been able to establish a channel of communication with the vendor, I don't see the value in further research & potential additional impact on end-users given the nature of my disclosure. If you want to land some easy CVEs give this application a look. There are roughly another 5 command injections at large (mainly in the hotel mode, the guest SSID initiation). There are also a lot of bad `memset` that I presume can lead to overflows and crashes. I'm not sure how realistic obtaining a stable root shell through a carefully constructed payload would be. As a freebie, I'm 99% sure there is a buffer overflow in `GetWanAddress` via the `wanDns1` and `wanDns2` parameters that copy the user-provided input to the stack using `sprintf` where `%s` can't limit copy length, so it's possible to make the stack overflow there as well. * * * ## Thoughts on Responsible Disclosure I genuinely try my hardest to adhere to clear and transparent ethical principles in responsible vulnerability disclosure (RVD). In every case, I place top priority on the safety and security of end-users. I've written a handful of blogs that will never see the light of day because of vendor negligence, which would cause serious real-life end-user impact. My blog is not intended to be malicious and isn't set out to damage brands or their reputations. I genuinely make these to educate, inform, and attempt to make the internet a safer place. As mentioned above, I try my best to act in a transparent, responsible, and consistent manner. In order to achieve this, I adhere to 90 days from the initial contact disclosure deadline. This can be shortened if the vendor remediates the vulnerability sooner, and lengthened if the vendor requires additional time to patch the vulnerability. * I will make at minimum 5 attempts to establish confidential and detailed communication with the vendor. This includes but is not limited to the vendor's "contact us" email address, key employee LinkedIn, Twitter, company telephone, etc,. I also make an effort to provide the vendor with multiple channels of communication (WeChat, LinkedIn, Email, Telegram, WhatsApp, and Telephone) for their overall convenience. * Once in contact with the vendor's security team or designated company contact, I provide the details of the vulnerabilities. During the first contact, I also discuss my intentions to work along sides them / and help them with remediation & retesting until the vulnerability is patched. Lastly, I discuss my intentions for public disclosure. * Once everything has been agreed upon, a secure communications channel will be established. Over this channel, all details and materials needed to reproduce the vulnerability are provided. * I try my best to provide reasonable assistance to the vendor to ensure the understanding of the significance of the discovered vulnerability. * Once a patch has been released, I'll retest the patch out of good faith. * * * With regard to this blog, there were two decisions I could take. Either disclose or don't. "Who cares, just post it," you may be thinking. I do. And my ethical dilemma was as follows: _Option A_ : I don't disclose. As a consequence, there isn't a chance for the vendor or affected customers to be made aware of the underlying bugs. Furthermore, an unethical individual may find the issue first and exploit it, potentially compromising dozens of utilities. _Option B:_ I publicly disclose the vulnerability, exposing the flaws in the product, and this blog-generated visibility prompts the vendor to take action (hopefully). As a consequence, low-life humans try and leverage these vulnerabilities against (in this case) a very small potential list of affected customers. Additionally, this blog could also rush affected customers to take their vulnerable systems down. _Underlying issue_ : The vendor has no control over the remote devices, other than publishing firmware updates and alerting customers the vendor can't do much. As mentioned multiple times, the goal/aim of my research has always been to make the internet a safer place. In this case, after evaluating the vendor's behavior or lack thereof, achieving my goal would require the vendor to change their current workflow & work towards establishing fluid channels of communication with researchers. This may require the publication of blogs such as these. Having weighed the pros and cons, I've decided to publicly disclose. Hopefully, this will help the vendor go through the change it needs to better handle researchers and disclosure. * * * It should be _blatantly_ obvious that any past, present, or future employer cannot be held responsible for any personal research and disclosure conducted by me under my own name. I find it unfortunate that a small majority of people remain hyper-sensitive to vulnerabilities and public disclosure. Therefore, I feel the need to add this disclaimer. I know my heart is in the right place, and that blogs far more damning than this go up all the time, without the author being judged and shamed. **_DISCLAIMER_** Any misuse derived from the information contained within this blog will be the exclusive responsibility of the person who carries it out. The owner of the blog, all present, past, and future employers, ghost.io, and any of its associates will not be liable for any consequences or damages resulting from reckless and malicious use. The vendor is solely responsible for its security errors, and any damage that may be caused to the user's computer systems (hardware and software), or to the files & documents stored on them, as a consequence. Shenzhen Tenda Technology Co., Ltd., failed to establish a clear channel of communication despite my thorough and consistent attempts. They were given ample opportunity to respond to my contact attempts. Responsible disclosure allows vendors between 60 and 120 business days to patch a vulnerability. 90 days have passed since my initial contact attempts. * * * ## **Summary:** I hope you liked the blog post. I apologize for getting political toward the end. Follow me on [twitter](https://twitter.com/olivier_boschko) I sometimes post interesting stuff there too. Personally, I'd strongly recommend going on Amazon, Alibaba, or Aliexpress & buying a bunch of odd IoT devices & tearing them down. You never know what you will find :) If you have any ethical dilemmas, hold anything against me, or disapprove of the contents of this blog, send me a DM, I'd love to see it from your perspective. Every day is a school day. **Thank you for reading!**