CVE-2024-37186
An os command injection vulnerability exists in the adm.cgi set_ledonoff() functionality of Wavlink AC3000 M33A8.V5030.210505. A specially crafted HTTP request can lead to arbitrary code 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-77 - Improper Neutralization of Special Elements used in a Command (‘Command Injection’)
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 authentication 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:
00401a98 else if (strcmp(webget_page, "ledonoff") == 0)
00401b34 set_ledonoff(contlen_buf, &data_410000)
Continuing into set_ledonoff:
004139a0 int32_t set_ledonoff(char *arg1)
004139e4 int32_t $v0_1 = strdup(web_get("led_cmd", arg1, 0)) //[1]
00413a0c if (access("/tmp/web_log", 0) == 0)
00413a44 int32_t $v0_4 = fopen("/dev/console", &data_415758)
00413a50 if ($v0_4 != 0)
00413a80 fprintf($v0_4, "%s:%s:%d:led_cmd=%s\n\n", "adm.c", "set_ledonoff", 0x10f4, $v0_1, 0x439d20)
00413a98 fclose($v0_4)
00413ac0 return do_system("%s", $v0_1) __tailcall
00413a30 return do_system("%s", $v0_1) __tailcall // [2]
At [1], the binary grabs our ledonoff post parameter, and then at [2] it just runs that command, leading to extremely straight forward arbitrary command injection.
It is important to note that a very similar issue has been previously found in the Wavlink AC1200 router and assigned CVE-2022-35525. Due to the fact that this is a different router model and also that the parameter injected into is slightly different (led_cmd as opposed to led_switch), along with the fact that this vulnerability is present in the newest AC3000 firmware, we are assigning a new CVE to this vulnerability.
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.