CVE-2021-43702: CVE-2021-43702 from Discovery to Patch | Kroll

While studying for my master’s degree in cyber security, I co-authored a paper regarding the rollout of IoT devices and the security considerations that businesses need to address to ensure these devices are secure. The paper underscored how a large majority of IoT devices used vulnerable components and did not follow basic secure programming principles.

As I was setting up my own new internal network in September 2021, I stumbled upon various logging functionalities within the custom deployment of DD-WRT that raised questions in my mind. DD-WRT, or in this case ASUSWRT, is a custom-developed Linux-based operating system for consumer router/modem products. Developed internally by ASUSTek, ASUSWRT builds on the standard DD-WRT distribution with a custom web interface and additional features, such as ASUSTek AiMesh networking products. The web front-end is programmed in ASP, which acts as a user interface for controlling various settings within the NVRAM of the device.

I had previously looked at router firmware but never found any vulnerabilities as such. Intrigued by the potential security-related issues that could occur if my router was hijacked, I set one of my Wi-Fi radios to a basic XSS payload to see if it had been sanitized…

“><script>alert(1)</script>

Nope, no popup…

I moved on, considering that there would be no way an XSS would be present within a software package that is so widely deployed across the world, until…

A few days later, my ISP was playing up, so I logged in to the router and navigated to the log section of the platform to see if there were any issues on my side with the router. I quickly clicked through the menus provided, one being “Wireless logs.” I suddenly had a JavaScript popup in my browser window: My original XSS had fired under the log page.

Win!

Why Does This Matter?

ASUS routers have a functionality named Remote Management that allows for users to connect back to their home routers over HTTP, over port 8443. This also allows users to attach devices, such as USB pen drives, to their router to effectively turn it into a router/network attached storage combo unit.

An attacker with pre-existing access to a router could use this vulnerability to maintain persistence to the router, even after a password reset/IP address change. An attacker could additionally leverage this exploit to change any setting on the router, including Wi-Fi passwords and DNS servers, and enabling telnet/SSH. Ultimately, this exploit allows for complete takeover of a compromised router when chained with basic Unix knowledge.

It would be trivial to create a Shodan search query to pull in all ASUS router products accessible from the internet (Figure 1) (Table 1). Although the user must set their own password from the default one provided by the manufacturer to first access the web admin interface, cybercriminals know all too well that users commonly reuse passwords.

Figure 1 – Exposed ASUS Routers Globally

Vulnerable Firmware/Device – 3.0.0.4.386.46061

All Zen WiFi lineup

RT-AC66U B1

All 802.11axl lineup

RT-AC66U+

All ROG Rapture lineup

RT-AC1300UHP/ G+

All TUF Gaming lineup

RT-AC1200

RT-AC5300

RT-AC1200G/HP/G+/ E/ GU

RT-AC3100

RT-AC58U

RT-AC88U

RT-AC56U/R/S

RT-AC3200

RT-AC55U

RT-AC2900

RT-AC55UHP

RT-AC2600

RT-AC53

RT-AC2400

RT-AC52U B1

RT-AC2200

RT-AC51U/ U+

RT-AC87U/R

RT-ACRH17

RT-AC86U

RT-ACRH13

RT-AC85U

RT-N66U/R/W/C1

RT-AC85P

RT-N18U

RT-AC65P

RT-N19

RT-AC57U

RT-N14UHP

RT-AC68U/R/P/W/UF

RT-N12E B1/C1

RT-AC65U

RT-N12HP B1

RT-AC1900

RT-N12VP B1

RT-AC1900P/U

RT-N12+ B1

RT-AC1750

RT-N12D1

RT-AC1750 B1

4G-AC53U

RT-AC66U/R/W

4G-AC68U

Table 1 – Vulnerable Firmware to Devices

Code Analysis

I subsequently dumped the firmware from a vulnerable version, accessed via the ASUSTek update page.

Upon downloading the file, you will be presented with a .trx file, which is effectively a zip containing the mount points for the operating system. The web front-end is stored within the /www folder, and in this case, the vulnerable code is located within the Main_WStatus_Content.asp file.

This file preforms a GET request to /wl_log.asp upon accessing the page. Within this request, the SSID of the router will also be returned, among data such as MAC addresses, access time for clients, and some other general debug information. The page then uses the following code to convert elements within the log, back to readable format, HTML encoding them in the process:

Function(resp){
Content = htmlEnDeCode.htmlEncode(resp);
Content = classObj.UnHexCode(content);
— Snip —

While this page attempts to decode the information provided by the GET request, in doing so, there is no filtering for malicious content, such as HTML tags. The script then continues and places the data within a <textarea> HTML element; in this case, the XSS payload is processed by the browser and the vulnerability has been exploited. The user’s browser will execute the payload and the attacker has control over the device.

Vulnerability Submission and Patch Released

I subsequently contacted ASUSTek on October 28, 2021, at 3:40 p.m. (UTC). The ASUS Security department (“ASUS security”) first requested that I update my firmware version to 386_45898 to verify that the vulnerability existed on the latest release of the firmware. After updating the software, I confirmed that the firmware was still vulnerable to the exploit.

ASUS security then requested a proof-of-concept script/video of the attack for their internal reference. After I provided a short 20-second clip of the vulnerability in action, ASUS security immediately accepted the submission.

Shortly after sending the proof-of-concept video, I received an email from ASUS security requesting that I install a new beta patch for the router product. After I personally confirmed that ASUS had patched the vulnerability in the beta branch of the firmware, ASUS requested my information so I could be acknowledged in the patch notes of the firmware (Figure 1). The beta firmware was subsequently published as the latest firmware update for the affected products.

Figure 2 – Firmware Patch Notes Acknowledgement

CVE Assignment

A CVE was requested for this issue on November 11, 2021, which MITRE subsequently issued on March 28, 2022, as CVE-2021-43702. As of this writing, MITRE has not published further details, but I’ll update this article when more information becomes available.