Talos Vulnerability Report

TALOS-2024-2023

Wavlink AC3000 firewall.cgi iptablesWebsFilterRun() command injection vulnerability

January 14, 2025
CVE Number

CVE-2024-39367

SUMMARY

An os command injection vulnerability exists in the firewall.cgi iptablesWebsFilterRun() functionality of Wavlink AC3000 M33A8.V5030.210505. A specially crafted HTTP request can lead to arbitrary code execution. An attacker can make an authenticated 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.1 - CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

CWE

CWE-77 - Improper Neutralization of Special Elements used in a Command (‘Command Injection’)

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.

Assuming that we’ve passed this check in the firewall.cgi binary, we then run into a set of functions that we can call based off of what we pass for the firewall= parameter in our HTTP POST request. Of the available commands, we focus on the following:

00401264         if (strcmp(web_get_firewall, "websURLFilter") == 0)   // [1]
00401ed4             char* cur_WebsURLFilters = nvram_bufget(flag: 0, valname: "websURLFilters")
00401eec             web_debug_header()
00401f08             int32_t addURL = web_get("addURLFilter", &inpbuf, 1) // [2]
00401f14             if (addURL != 0 && strchr(addURL, 0x3b) == 0)
00401f48                 if (cur_WebsURLFilters == 0 || (cur_WebsURLFilters != 0 && sx.d(*cur_WebsURLFilters) == 0))
00401f5c                     nvram_bufset(flag: 0, varname: "websURLFilters", varval: addURL)      // [3]
00401f74                     label_401f74:
00401f74                     nvram_commit(0)
00401f8c                     do_system("iptables -t filter -F web_filter")
00401f94                     iptablesWebsFilterRun()

Assuming that we pass firewall=websURLFilter [1], we enter this branch within firewall.cgi’s main() function, which writes our addURLFilter POST parameter [2] to the websURLFilters nvram item at [3]. Immediately after this nvram item will be put into use in the iptablesWebsFilterRun() function at [4]:

00408468  int32_t iptablesWebsFilterRun()

004084a4      char* websURLFilter = nvram_bufget(flag: 0, valname: "websURLFilters")    // [5]
004084c0      char* websHostFilters = nvram_bufget(flag: 0, valname: "websHostFilters")
004084dc      int32_t websFilterProxy = nvram_bufget(flag: 0, valname: "websFilterProxy")
004084f8      int32_t websFilterJava = nvram_bufget(flag: 0, valname: "websFilterJava")
00408514      int32_t websFilterActivex = nvram_bufget(flag: 0, valname: "websFilterActivex")
00408530      int32_t websFilterCookies = nvram_bufget(flag: 0, valname: "websFilterCookies")
00408564      if (websURLFilter != 0 && websHostFilters != 0 && websFilterProxy != 0 && websFilterJava != 0 && websFilterActivex != 0 && websFilterCookies != 0) // [6]
00408594          int32_t $s0_1 = strcmp(websFilterJava, "1") u< 1 ? 1 : 0
0040859c          if (strcmp(websFilterActivex, "1") == 0)
004085a4              $s0_1 = $s0_1 + 2
004085bc          if (strcmp(websFilterCookies, "1") == 0)
004085c4              $s0_1 = $s0_1 + 4
004085d0          int32_t $v0_3 = strcmp(websFilterProxy, "1")
004085dc          if ($v0_3 == 0)
004086a8              $s0_1 = $s0_1 + 8
004085e4          if ($v0_3 == 0 || ($v0_3 != 0 && $s0_1 != 0))
004086b8              do_system("iptables -A web_filter -p tcp -m tcp --dport 80   ...", $s0_1)
004086d4              do_system("iptables -A web_filter -p tcp -m tcp --dport 3128 ...", $s0_1)
004086f0              do_system("iptables -A web_filter -p tcp -m tcp --dport 8080 ...", $s0_1)
004085f4          int32_t x = 0
00408618          char url  
00408618          while (true)
00408618              int32_t $v0_4 = get_nth_value(index: x, inp: websURLFilter, separator: ';', outbuf: &url, outlen: 0x100) // [7]
00408628              x = x + 1
00408638              if ($v0_4 == 0xffffffff)
00408638                  break
00408648              if (sx.d(url) != 0)
0040865c                  void var_119
0040865c                  if (strncasecmp(&url, "http://", 7) == 0)
0040870c                      strcpy(&url, &var_119)
0040866c                  do_system("iptables -A web_filter -p tcp -m tcp -m webstr --url  %s -j REJECT --reject-with tcp-reset", &url) // [8]
// [...]

At [5], we can see the binary getting the websURLFilters data previously mentioned, along with a few other nvram items. Since the nvram_bufget function can never return null, we always enter the branch at [6] and eventually start parsing our nvram item at [7]. Each ‘;’ separated value is run within the do_system command at [8], and since the only real input constraint that we have is not a being able to pass semi-colons, we can still run arbitrary system commands extremely easily via subshells.

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

Credit

Discovered by Lilith >_> of Cisco Talos.