Talos Vulnerability Report

TALOS-2024-2025

Wavlink AC3000 adm.cgi rep_as_bridge() buffer overflow vulnerability

January 14, 2025
CVE Number

CVE-2024-37184

SUMMARY

A buffer overflow vulnerability exists in the adm.cgi rep_as_bridge() functionality of Wavlink AC3000 M33A8.V5030.210505. A specially crafted HTTP request can lead to stack-based buffer overflow. 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-120 - Buffer Copy without Checking Size of Input (‘Classic 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 adm.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:

004018a0                          else if (strcmp(webget_page, "wzdrepeater") == 0)
00401c9c                              set_wzdrepeater(contlen_buf)

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

0040ed2c  int32_t set_wzdrepeater(int32_t arg1)
0040ed7c      int32_t $v0_1 = strdup(web_get("rep_type", arg1, 0))
0040eda4      if (access("/tmp/web_log", 0) == 0)
0040ee68          int32_t $v0_8 = fopen("/dev/console", &data_415758)
0040ee74          if ($v0_8 != 0)
0040eea4              fprintf($v0_8, "%s:%s:%d:rep_type = %s \n\n", "adm.c", "set_wzdrepeater", 0xc12, $v0_1, 0x439d20)
0040eebc              fclose($v0_8)
0040edb8      int32_t $v0_3 = nvram_bufget(0, "ModelType")
0040eddc      nvram_bufset(0, "IEEE80211H", "1")
0040ee00      if (strcmp($v0_1, "1") == 0)
0040eee8          return rep_as_bridge(arg1) __tailcall
0040ee1c      if (strcmp($v0_3, "Mesh") == 0)
0040ee54          return rep_as_routerMesh(arg1) __tailcall
0040ee38      return rep_as_router(arg1) __tailcall

This function only serves to check our provided rep_type POST parameter [1] and redirect code flow to one of three subfunctions. Assuming that the rep_type is “1” , then we enter the rep_as_bridge function:

0040d130  int32_t rep_as_bridge(int32_t arg1)
// [...]
0040d178      int32_t $v0 = nvram_bufget(0, "Model")
0040d194      int32_t is_TouchLinkEn = nvram_bufget(0, "TouchLinkEn")
// [...]

41 @ 0040d504  int32_t sprintf_vuln = strdup(web_get("wl_rep_ssid2g", arg1, 0)) // [2]
// [...]

0040da24                  if (strcmp(is_TouchLinkEn, "1") == 0)
0040e200                      void var_a0
0040e200                      sprintf(&var_a0, "%s_Touch", sprintf_vuln) // [3]
0040e21c                      nvram_bufset(2, "SSID3", &var_a0)

At [2], the binary copies our wl_rep_ssid2g POST parameter to the heap and then copies our input buffer to the stack at [3]. Since there’s no length checking on our input buffer, we can easily provide a buffer longer than 0xa0 bytes, which will overwrite the return address of this function and quickly result in arbitrary code execution.

Crash Information

Thread 2.1 "adm.cgi" hit Breakpoint 2, 0x00400d54 in main ()
(gdb) b *0x40dd9c
Breakpoint 3 at 0x40dd9c
(gdb) c
Continuing.
[Detaching after fork from child process 9526]

Thread 2.1 "adm.cgi" hit Breakpoint 4, 0x0040e200 in rep_as_bridge ()
(gdb) x/1s $a2
0x575138:       "\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177
\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177\bp\377\177", 'A' <repeats 16 times>
(gdb) c
Continuing.
[Detaching after fork from child process 930]


Thread 2.1 "adm.cgi" hit Breakpoint 3, 0x0040dd9c in rep_as_bridge ()
(gdb) bt
#0  0x0040dd9c in rep_as_bridge ()
#1  0x41414141 in ?? ()
Backtrace stopped: frame did not save the PC
(gdb) info reg
          zero       at       v0       v1       a0       a1       a2       a3
 R0   00000000 00000000 00000000 ffffffff 00000003 7fb87ea4 00000000 00000000
            t0       t1       t2       t3       t4       t5       t6       t7
 R8   00000000 00000000 00000000 00000000 00000001 00000000 00000000 00000001
            s0       s1       s2       s3       s4       s5       s6       s7
 R16  7fff7008 7fff7008 7fff7008 7fff7008 7fff7008 7fff7008 41414141 41414141
            t8       t9       k0       k1       gp       sp       s8       ra
 R24  00000000 77385450 00000010 00000000 77422490 7fb87f48 41414141 41414141
        status       lo       hi badvaddr    cause       pc
      0100fc13 00000400 00000000 7fb87e70 50800024 0040dd9c
          fcsr      fir      hi1      lo1      hi2      lo2      hi3      lo3
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        dspctl  restart
      00000000 00000000
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.