Talos Vulnerability Report

SUMMARY

A cross-site scripting (xss) vulnerability exists in the login.cgi set_lang_CountryCode() functionality of Wavlink AC3000 M33A8.V5030.210505. A specially crafted HTTP request can lead to a disclosure of sensitive information. An attacker can make an unauthenticated HTTP request to trigger this vulnerability.

CONFIRMED VULNERABLE VERSIONS

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Wavlink AC3000 M33A8.V5030.210505

PRODUCT URLS

Wavlink AC3000 - https://www.wavlink.com/en_us/product/WL-WN533A8.html

CVSSv3 SCORE

9.6 - CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

CWE

CWE-80 - Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

DETAILS

The Wavlink AC3000 wireless router is predominately one of the most popular gigabit routers in the US, in part due to both its potential wireless and wired speed capabilities and extremely low price point (costing at the time of this writing ~$60 USD). Among the configuration options, it’s also able to act as a standalone wireless gateway, a basic network router, or a wireless repeater.

When interacting with and configuring the Wavlink AC3000 wifi router, as is typical of most wifi routers, an administrator logs in via some web portal and configures appropriate options via the HTTP interface. In the case of this particular router, and in another somewhat common execution pattern, these HTML pages can invoke .cgi binaries due to how the lighttpd server is configured. Since all of these .shtml and .cgi files are located in the web root, anyone with network access to the device doesn’t actually need to log in to the device to interact with these .cgi files, and it usually is the responsibility of the .cgi binary to check if the authentication is completed successfully. On this device, one will see a check_valid_user() function in each individual .cgi binary which will check the session cookie of the HTTP request to see if it’s coming from a validly logged in user.

When dealing with the login.cgi binary however, this login check does not exist, since the login.cgi is normally in charge of doing authentication, as such all login.cgi vulnerabilities are unauthenticated. Regardless of this, the basic code flow is the same, and our HTTP Post page parameter determines the code flow within our .cgi binary:

004010d0              int32_t contlen_int = strtol(getenv("CONTENT_LENGTH"), 0, 0xa)
004010e4              if (contlen_int - 1 u>= 0x1f3)
004014cc                  sprintf(&var_418, "http://%s/login.shtml?login=0", nvram_bufget(0, "lan_ipaddr"))
004014e4                  web_redirect_wholepage(&var_418)
// [...]
004018ac     else if (strcmp(page_decoded, "test") == 0)
00401948        Goto_chidx(inpbuf: malloc_contlen)

If we provide page=test, we apparently enter the set_lang_CountryCode function and our provided POST data is further parsed therein. Worth noting that there is a length check for the login.cgi binary, and our the length of our POST data must be less than 0x1f3. Continuing into set_lang_CountryCode:

00401c00  int32_t set_lang_CountryCode(char* inp, uint32_t inplen)
00401c54      int32_t lang_val_dup = strdup(web_get("langue", inp, 0))     // [1]
00401c8c      int32_t country_get_dup = strdup(web_get("country", inp, 0))
// [...]
00401ccc      nvram_bufset(flag: 0, nvram_var_name: "Language", nvram_var_value: lang_val_dup) // [2]

Quickly we can see the only relevant detail - our langue POST parameter is read into the heap at [1] and then written into the Language nvram item at [2]. If we look to see where this might be useful, we can see clearly the following:

$ grep -r "web 2860 nvram Language"
etc_ro/lighttpd/www/login1.shtml:var Language = "<!--#exec cmd="web 2860 nvram Language"-->";
etc_ro/lighttpd/www/live_getsettings.shtml:var Lang="<!--#exec cmd="web 2860 nvram Language"-->";
etc_ro/lighttpd/www/login2.shtml:var Language = "<!--#exec cmd="web 2860 nvram Language"-->";
etc_ro/lighttpd/www/login.shtml:var Language = "<!--#exec cmd="web 2860 nvram Language"-->";

As such, our input langue parameter is directly turned into html output, allowing us to arbitrarily inject persistent XSS into any of the above web pages. This could allow us to deny login services or gain session cookies for administrative users, resulting in either a denial of service or information disclosure.

TIMELINE

2024-07-25 - Initial Vendor Contact
2024-07-29 - Requesting reply from vendor
2024-07-30 - Vendor confirms receipt
2024-07-30 - Vendor Disclosure
2024-07-30 - Vendor confirms receipt
2024-09-02 - Status update request sent
2024-10-15 - Status update request. Upcoming expiration date announced.
2024-10-22 - Vendor replies product has been discontinued, but patches are being worked on
2024-11-04 - Status update request for patch release dates
2024-11-12 TALOS advisory release date announced
2025-01-14 - Public Release