Talos Vulnerability Report

SUMMARY

A stack-based buffer overflow vulnerability exists in the wireless.cgi set_wifi_basic_mesh() 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:

00401c14                      if (strcmp(str1: webget_page, str2: "basicMesh") == 0)
004021b4                          set_wifi_basic_mesh(contlen_p1malloc_1)

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

00402ba4  int32_t set_wifi_basic_mesh(int32_t arg1)
00402c0c      int32_t SSID2G_1 = strdup(web_get("SSID2G", arg1, 0))   // [1]
00402c44      int32_t SSID5G_D_1 = strdup(web_get("SSID5G_D", arg1, 0))
00402c7c      int32_t SSID5G_T_1 = strdup(web_get("SSID5G_T", arg1, 0))
00402cb4      int32_t AuthMethod25_1 = strdup(web_get("AuthMethod25", arg1, 0))
00402ce8      int32_t EncrypType_1 = strdup(web_get("EncrypType", arg1, 0))
00402d1c      int32_t WPAPSK1_1 = strdup(web_get("WPAPSK1", arg1, 0))
00402d38      char* str1 = nvram_bufget(0, "TouchLinkEn")
00402d54      char* str1_1 = nvram_bufget(0, "ModelType")
00402d7c      int32_t SSID5G_D_2
00402d7c      int32_t SSID5G_T_2
// [...]
00402de8      void var_78  
00402de8      sprintf(&var_78, "%s_Touch", SSID2G_1) // [2]

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

Crash Information

Thread 2.1 "wireless.cgi" hit Breakpoint 4, 0x00403c48 in set_wifi_basic ()
(gdb) info reg
          zero       at       v0       v1       a0       a1       a2       a3
 R0   00000000 00000000 7ff19cbc 00005288 00000000 008240d0 008240e0 008240f0
            t0       t1       t2       t3       t4       t5       t6       t7
 R8   76e8f2b4 76e8e6e4 00000000 ffffffff 76ff6000 f0000000 00000001 00403c24
            s0       s1       s2       s3       s4       s5       s6       s7
 R16  00410000 44444444 44444444 44444444 44444444 44444444 44444444 44444444
            t8       t9       k0       k1       gp       sp       s8       ra
 R24  00000054 76e93288 00000000 00000000 77014010 7ff19c78 44444444 44444444
        status       lo       hi badvaddr    cause       pc
      0100fc13 00111044 00000030 00419e50 50800024 00403c48
          fcsr      fir      hi1      lo1      hi2      lo2      hi3      lo3
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        dspctl  restart
      00000000 00000000
(gdb) c
Continuing.

Thread 2.1 "wireless.cgi" received signal SIGSEGV, Segmentation fault.
0x44444444 in ?? ()

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