CVE-2024-39774
A buffer overflow vulnerability exists in the adm.cgi set_sys_adm() 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.
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-120 - Buffer Copy without Checking Size of Input (‘Classic 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 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:
00401830 if (strcmp(webget_page, "sysAdm") == 0)
00401d00 set_sys_adm(contlen_buf)
If we provide page=sysAdm
, we enter the set_sys_adm
function and our provided POST data is further parsed therein:
int32_t set_sys_adm(int32_t arg1)
0040211c int32_t remote_addr = 0
00402124 remote_addr.b = 0x30
00402128 int32_t s
00402128 __builtin_memset(s: &s, c: 0, n: 0x1c)
00402140 char var_118
00402140 memset(&var_118, 0, 0x80)
00402158 var_118 = 0x30
00402174 strcpy(&remote_addr, getenv("REMOTE_ADDR"))
00402190 int32_t nvram_login = nvram_bufget(0, "Login")
004021ac int32_t $v0_1 = nvram_bufget(0, "Password")
004021e4 int32_t origin_pwd = strdup(web_get("origin_pwd", arg1, 0))
0040221c int32_t web_new_pwd = strdup(web_get("new_pwd", arg1, 0)) //[1]
0040222c int32_t $v0_9
0040222c int32_t $a0_5
0040222c char const* const $a1_5
0040222c int32_t $s2_1
0040222c if (sx.d(*origin_pwd) == 0)
004022dc if (access("/tmp/web_log", 0) == 0)
// [...]
0040222c else if (sx.d(*web_new_pwd) != 0)
00402260 if (strcmp($v0_1, origin_pwd) == 0)
004023bc putchar(0x31)
004023dc // echo -n %s:%s > /tmp/tmpchpw && /usr/sbin/chpasswd <
004023dc // /tmp/tmpchpw && rm -fr /tmp/tmpchpw
004023dc sprintf(&var_118, "echo -n %s:%s > /tmp/tmpchpw && /usr/sbin/chpasswd…", nvram_login, web_new_pwd) // [2]
004023f4 system(&var_118)
00402410 nvram_bufset(0, "Password", web_new_pwd)
00402428 nvram_commit(0)
00402448 int32_t var_98
00402448 sprintf(&var_98, "echo "%s:%s" > /etc/lighttpd.user", nvram_login, web_new_pwd) // [3]
At [1], the binary copies our new_pwd
POST parameter into the heap and then at [2] and [3], uses sprintf
to copy this buffer onto the stack at two different offsets. Since there’s no length checks anywhere before, we can easily have an input buffer greater than 0x118 bytes, which will overwrite the return address of the function and quickly result in code execution.
Thread 2.1 "adm.cgi" hit Catchpoint 1 (exec'd /etc_ro/lighttpd/www/cgi-bin/adm.cgi), 0x770a4b10 in _start () from /rootfs_mount/lib/ld-uClibc.so.0
Breakpoint 3 at 0x400d54 (2 locations)
Thread 2.1 "adm.cgi" hit Breakpoint 3, 0x00400d54 in main ()
(gdb) b *0x4023dc
Breakpoint 4 at 0x4023dc
(gdb) c
Continuing.
Thread 2.1 "adm.cgi" hit Breakpoint 2, 0x00400e00 in main ()
Thread 2.1 "adm.cgi" hit Breakpoint 4, 0x004023dc in set_sys_adm ()
(gdb) x/1s $a2
0xaba0d8: "admin2860"
(gdb) x/1s $a3
0xab6160: 'A' <repeats 200 times>...
(gdb) bt
#0 0x004023dc in set_sys_adm ()
#1 0x004023c4 in set_sys_adm ()
Backtrace stopped: frame did not save the PC
(gdb) nexti
0x004023e4 in set_sys_adm ()
(gdb) bt
#0 0x004023e4 in set_sys_adm ()
#1 0x004023e4 in set_sys_adm ()
Backtrace stopped: frame did not save the PC
(gdb) c
Continuing.
[Detaching after fork from child process 10040]
[Detaching after fork from child process 10044]
[Detaching after fork from child process 10048]
Thread 2.1 "adm.cgi" received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
(gdb) bt
#0 0x41414141 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info reg
zero at v0 v1 a0 a1 a2 a3
R0 00000000 00000000 00000000 00000000 7fe87830 7fe87830 7fe87848 00000000
t0 t1 t2 t3 t4 t5 t6 t7
R8 00000000 0000fc00 862c4740 00000004 00000001 00000000 00000012 81f9e000
s0 s1 s2 s3 s4 s5 s6 s7
R16 41414141 41414141 41414141 41414141 41414141 76ec4c10 0043183c ffffffff
t8 t9 k0 k1 gp sp s8 ra
R24 00000000 76e9f6d0 00000000 00000000 76f3e490 7fe879c8 00450000 41414141
status lo hi badvaddr cause pc
0100fc13 00000de8 00000138 41414140 50800008 41414141
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.