CVE-2024-36493
A stack-based buffer overflow vulnerability exists in the wireless.cgi set_wifi_basic() 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:
00401b8c int32_t webget_page = web_get("page", contlen_p1malloc_1, 0)
00401bb4 if (strcmp(str1: webget_page, str2: "basic") == 0)
00401bbc set_wifi_basic(contlen_p1malloc_1)
If we provide page=basic, we enter the set_wifi_basic function and our provided POST data is further parsed therein:
00403514 int32_t set_wifi_basic(int32_t arg1)
00403578 int32_t $v0_1 = strdup(web_get("hiddenSSID24g", arg1, 0))
004035b0 int32_t $v0_3 = strdup(web_get("hiddenSSID5g", arg1, 0))
004035e8 int32_t $v0_5 = strdup(web_get("hiddenSSID5g_2", arg1, 0))
00403620 int32_t $v0_7 = strdup(web_get("WiFiOff2G", arg1, 0))
00403658 int32_t $v0_9 = strdup(web_get("WiFiOff5G", arg1, 0))
00403690 int32_t $v0_11 = strdup(web_get("WiFiOff5G_2", arg1, 0))
004036c8 int32_t vulnerable = strdup(web_get("SSID2G", arg1, 0)) // [1]
00403700 int32_t $v0_14 = strdup(web_get("SSID5G", arg1, 0))
00403738 int32_t $v0_16 = strdup(web_get("SSID5G_2", arg1, 0))
00403770 int32_t $v0_18 = strdup(web_get("AuthMethod2g", arg1, 0))
004037a8 int32_t $v0_20 = strdup(web_get("AuthMethod5g", arg1, 0))
004037e0 int32_t $v0_22 = strdup(web_get("AuthMethod5g_2", arg1, 0))
00403818 int32_t $v0_24 = strdup(web_get("EncrypType2g", arg1, 0))
00403850 int32_t $v0_26 = strdup(web_get("EncrypType5g", arg1, 0))
00403888 int32_t $v0_28 = strdup(web_get("EncrypType5g_2", arg1, 0))
004038c0 int32_t $v0_30 = strdup(web_get("WPAPSK1_2G", arg1, 0))
004038f8 int32_t $v0_32 = strdup(web_get("WPAPSK1_5G", arg1, 0))
00403930 int32_t $v0_34 = strdup(web_get("WPAPSK1_5G_2", arg1, 0))
00403a18 void var_98
00403a18 sprintf(&var_98, "%s_Touch", vulnerable) // [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 0x98 and overwrite the return address of the function, resulting in code execution.
Thread 2.1 "wireless.cgi" received signal SIGSEGV, Segmentation fault.
0x44444444 in ?? ()
(gdb) bt #0 0x44444444 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info proc map
process 12608
Mapped address spaces:
Start Addr End Addr Size Offset Perms objfile
0x400000 0x410000 0x10000 0x0 r-xp /etc_ro/lighttpd/www/cgi-bin/wireless.cgi
0x410000 0x41a000 0xa000 0x10000 rw-p /etc_ro/lighttpd/www/cgi-bin/wireless.cgi
0x48d000 0x4a1000 0x14000 0x0 rw-p [heap]
0x76e23000 0x76eb8000 0x95000 0x0 r-xp /lib/libuClibc-0.9.33.2.so
0x76eb8000 0x76ec7000 0xf000 0x0 ---p
0x76ec7000 0x76ec8000 0x1000 0x94000 r--p /lib/libuClibc-0.9.33.2.so
0x76ec8000 0x76ec9000 0x1000 0x95000 rw-p /lib/libuClibc-0.9.33.2.so
0x76ec9000 0x76ece000 0x5000 0x0 rw-p
0x76ece000 0x76edd000 0xf000 0x0 r-xp /lib/libwebutil.so
0x76edd000 0x76eec000 0xf000 0x0 ---p
0x76eec000 0x76ef6000 0xa000 0xe000 rw-p /lib/libwebutil.so
0x76ef6000 0x77036000 0x140000 0x0 rw-p
0x77036000 0x7703c000 0x6000 0x0 r-xp /lib/ld-uClibc-0.9.33.2.so
0x7704b000 0x7704c000 0x1000 0x5000 r--p /lib/ld-uClibc-0.9.33.2.so
0x7704c000 0x7704d000 0x1000 0x6000 rw-p /lib/ld-uClibc-0.9.33.2.so
0x7704d000 0x7704e000 0x1000 0x0 rw-p
0x7fec1000 0x7fee2000 0x21000 0x0 rwxp [stack]
0x7fff7000 0x7fff8000 0x1000 0x0 r-xp [vdso]
(gdb) info reg
zero at v0 v1 a0 a1 a2 a3
R0 00000000 00000000 7fee0fd4 00005288 00000000 0048d0c0 0048d158 7fff7004
t0 t1 t2 t3 t4 t5 t6 t7
R8 76ecf2b4 76ece6e4 00000000 ffffffff 77036000 f0000000 00000001 0040305c
s0 s1 s2 s3 s4 s5 s6 s7
R16 7fff7004 7fff7004 7fff7004 7fff7004 7fff7004 44444444 44444444 44444444
t8 t9 k0 k1 gp sp s8 ra
R24 00000054 76ed3288 00000010 00000000 77054010 7fee1058 44444444 44444444
status lo hi badvaddr cause pc
0100fc13 00111044 00000030 44444444 50800008 44444444
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.