CVE-2024-39359
A stack-based buffer overflow vulnerability exists in the wireless.cgi DeleteMac() 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:
00401d9c else if (strcmp(str1: webget_page, str2: "DeleteMac") == 0)
// [...]
00401fd0 if ($v0_77 != 0 || ($v0_77 == 0 && stream_5 == 0))
00401f6c nvram_ind_3 = nvram_ind
00401f70 DeleteMac(nvram_ind_3, inpb: contlen_p1malloc_1)
If we provide page=DeleteMac, we enter the DeleteMac function and our provided POST data is further parsed therein:
00409158 int32_t DeleteMac(int32_t arg1, char* inpb)
004091a4 int32_t str
004091a4 memset(str: &str, c: 0, n: 0xaa)
004091c0 char cmd_run[0x400]
004091c0 memset(str: &cmd_run, c: 0, n: 0x400)
004091f4 int32_t wlan_idx_1 = strdup(web_get("wlan_idx", inpb, 0))
0040922c int32_t delete_list_1 = strdup(web_get("delete_list", inpb, 0)) // [1]
00409248 char* $v0_2 = nvram_bufget(1, "SSID4")
// [...]
00409278 int32_t i = sx.d(*delete_list_1)
00409284 char* delete_list_2 = delete_list_1
00409280 if (i != 0)
00409288 int32_t num_ampers = 0
0040929c do
0040928c delete_list_2 = &delete_list_2[1]
00409290 int32_t checksum_idk = i ^ '&'
00409294 i = sx.d(*delete_list_2)
004092a0 num_ampers = num_ampers + (checksum_idk u< 1 ? 1 : 0)
0040929c while (i != 0) // [2]
// [...]
004092c0 if (num_ampers != 0)
004093b4 while (true)
004093b4 void rule_to_del
004093b4 get_nth_value(index: num_ampers, inp: delete_list_1, separator: '&', outbuf: &rule_to_del, outlen: 8) // [3]
004093d0 void rule_num
004093d0 sscanf(&rule_to_del, "%d", &rule_num) // [4]
00409400 int32_t acl3_1
00409400 __builtin_strncpy(dest: &acl3_1, src: "AccessControlName3", n: 0x13)
00409414 // It's grabbing from rtdev, not 2860...
00409414 char* AccessControlName3 = nvram_bufget(1, &acl3_1) // [4]
00409420 int32_t $v0_14
00409420 int32_t stream_6
00409420 int32_t stream_4
00409420 int32_t stream_5
00409420 if (AccessControlName3 == 0)
004099f0 stream_5 = access("/tmp/web_log", 0)
004099fc if (stream_5 != 0)
004098f4 return stream_5
00409a10 stream_5 = fopen(filename: "/dev/console", mode: &data_40d438)
00409a20 stream_4 = stream_5
00409a1c if (stream_5 == 0)
004098f4 return stream_5
00409a34 stream_6 = stream_5
00409a44 $v0_14 = 0x8cb
00409420 else
00409430 char tmp_0x530[0x500]
00409430 strcpy(dest: &tmp_0x530, src: AccessControlName3) // [5]
0040944c delete_nth_value(rules_to_del: &rule_num, max_num: 1, current_rules: &tmp_0x530, sep_char: ';') // [6]
At [1], we see the binary copy our delete_list POST parameter to the heap, and checks to see if it has any ‘&’ chars in the loop immediately below that [2]. Assuming that there are ampersands, the binary then grabs each value between the ampersands [3] and turns that value into an integer at [4]. That integer is then treated as an index of the nvram AccessControlName3 buffer at [4]. This buffer is copied to the stack at [5] and then eventually this index is used to delete a specific list item within at [6]. Since the strcpy at [5] has no length checking, if we can manage to arbitrarily control the AccessControlName3 nvram buffer, then we can gain code execution by overwriting the return address of this function. Thankfully for us, we can use the AddMac command to add such a buffer that is greater than 0x530 in size:
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)) // [7]
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
// [...]
00408c50 stream = fclose(stream)
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)
00408c88 do_system(&buf_0x800)
// [...]
00408cdc // snprintf(0x2a030, 0x20, "%s%1d", arg1, arg2)
00408cdc nvram_bufset(nvram_ind, racat("AccessControlName", 3), name_list_webget) // [8]
As shown above, we can provide a addMac POST parameter [7] to the AccessControlName3 nvram variable at [8]. Since the stack buffer size in AddMac is 0x800, we can safely provide more than 0x530 bytes to overflow the stack on a subsequent call to DeleteMac.
Thread 2.1 "wireless.cgi" hit Breakpoint 3, 0x00409430 in DeleteMac ()
(gdb) x/7s $v0
0x45b300: 'A' <repeats 200 times>...
0x45b3c8: 'A' <repeats 200 times>...
0x45b490: 'A' <repeats 200 times>...
0x45b558: 'A' <repeats 200 times>...
0x45b620: 'A' <repeats 200 times>...
0x45b6e8: 'A' <repeats 200 times>...
0x45b7b0: 'A' <repeats 32 times>, "\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\004p\377\177\004p\377\177\004p\377\177\004p\377\177\004p\377\177", 'B' <repeats 12 times>
(gdb) bt
#0 0x00409430 in DeleteMac ()
#1 0x00401f78 in main ()
(gdb) nexti
bt0x00409438 in DeleteMac ()
(gdb) bt
#0 0x00409438 in DeleteMac ()
#1 0x42424242 in ?? ()
Backtrace stopped: frame did not save the PC
(gdb) c
Continuing.
[Detaching after fork from child process 24489]
[Detaching after fork from child process 24495]
[Detaching after fork from child process 24499]
[Detaching after fork from child process 24502]
[Detaching after fork from child process 24504]
[Detaching after fork from child process 24506]
[Detaching after fork from child process 24508]
Thread 2.1 "wireless.cgi" received signal SIGBUS, Bus error.
0x42424242 in ?? ()
(gdb) info reg
zero at v0 v1 a0 a1 a2 a3
R0 00000000 00000000 7ff8fde0 00005288 00000000 7fff7004 00458050 00000000
t0 t1 t2 t3 t4 t5 t6 t7
R8 770eb2b4 770ea6e4 00000000 ffffffff 77252000 f0000000 00000001 004098cc
s0 s1 s2 s3 s4 s5 s6 s7
R16 7fff7004 7fff7004 7fff7004 7fff7004 7fff7004 7fff7004 7fff7004 42424242
t8 t9 k0 k1 gp sp s8 ra
R24 00000054 770ef288 00000010 00000000 77270010 7ff907f8 42424242 42424242
status lo hi badvaddr cause pc
0100fc13 00111044 00000030 42424242 50800010 42424242
fcsr fir hi1 lo1 hi2 lo2 hi3 lo3
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dspctl restart
00000000 00000000
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.