Talos Vulnerability Report

SUMMARY

A stack-based buffer overflow vulnerability exists in the wireless.cgi AddMac() functionality of Wavlink AC3000 M33A8.V5030.210505. A specially crafted HTTP request can lead to arbitrary command 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-121 - Stack-based Buffer Overflow

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 wireless.cgi binary, we then run into a set of functions that we can call based off of what we pass for the page= parameter in our HTTP POST request. Of the available commands, we focus on the following:

004010fc          nvram_ind = getNvramIndex(web_get("wlan_conf", contlen_p1malloc_1, 0))
    // [...]
00401d80                      else if (strcmp(str1: webget_page, str2: "AddMac") == 0)
    // [...]
00401fa4                          AddMac(nvram_ind: nvram_ind_1, inp: contlen_p1malloc_1)

If we provide page=AddMac, we enter the AddMac function and our provided POST data is further parsed therein:

00408a44  int32_t AddMac(char* nvram_ind, char* inp)

00408a88      char buf_0x800[0x800]
00408a88      memset(str: &buf_0x800, c: 0, n: 0x400)
00408abc      int32_t wlan_idx_webget = strdup(web_get("wlan_idx", inp, 0))
00408af4      int32_t addMac_webget = strdup(web_get("addMac", inp, 0))      // [1]
00408b2c      int32_t name_list_webget = strdup(web_get("name_list", inp, 0))
00408b48      char* $v0_3 = nvram_bufget(1, "SSID4")
00408b64      memset(str: &buf_0x800[0x400], c: 0, n: 0x800)
00408b7c      int32_t stream = access("/tmp/web_log", 0)
00408b88      int32_t var_c38
00408b88      char* var_c34
00408b88      int32_t addMac_webget_1
00408b88      int32_t name_list_webget_1
    // [...]
00408b90      if (addMac_webget != 0)
00408b98          stream = sx.d(*addMac_webget)
00408ba8          if (stream != 0 && name_list_webget != 0)
00408bb0              stream = sx.d(*name_list_webget)
00408bb8              if (stream != 0)
00408c70                  sprintf(&buf_0x800, "addmac %s", addMac_webget)  // [2]
00408c88                  do_system(&buf_0x800)               // [3]

At [1], we see the binary copy our arbitrary length addMac POST parameter to the heap, and at [2] this variable is then copied to the stack with an sprintf and then directly run with system at [3]. Since there’s no length checking whatsoever on this POST parameter, we can easily pass in a buffer greater than length 0xc20 and overwrite the return address of the function, resulting in code execution.

Crash Information

Thread 2.1 "wireless.cgi" hit Breakpoint 2, 0x00408c70 in AddMac ()
(gdb) x/10i $pc
=> 0x408c70 <AddMac+556>:       jalr    t9
   0x408c74 <AddMac+560>:       addiu   a0,sp,40
   0x408c78 <AddMac+564>:       lw      gp,32(sp)
   0x408c7c <AddMac+568>:       nop
   0x408c80 <AddMac+572>:       lw      t9,-32628(gp)
   0x408c84 <AddMac+576>:       nop
   0x408c88 <AddMac+580>:       jalr    t9
   0x408c8c <AddMac+584>:       addiu   a0,sp,40
   0x408c90 <AddMac+588>:       lw      gp,32(sp)
   0x408c94 <AddMac+592>:       addiu   a0,s2,-11240
(gdb) info reg a0 a1 a2
a0: 0x410000
a1: 0x40e800
a2: 0x6a7c90
(gdb) x/1s a1
^[[ANo symbol "a1" in current context.
(gdb) x/1s $a1
0x40e800:       "addmac %s"
(gdb) x/1s $a2
0x6a7c90:       'A' <repeats 200 times>...
(gdb) bt
#0  0x00408c70 in AddMac ()
#1  0x00401fac in main ()
(gdb) nexti
0x00408c78 in AddMac ()
(gdb) bt
#0  0x00408c78 in AddMac ()
#1  0x41414141 in ?? ()
Backtrace stopped: frame did not save the PC

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