Talos Vulnerability Report

TALOS-2024-2018

Wavlink AC3000 login.cgi set_sys_init() command injection vulnerabilities

January 14, 2025
CVE Number

CVE-2024-39759,CVE-2024-39761,CVE-2024-39760

SUMMARY

Multiple OS command injection vulnerabilities exist in the login.cgi set_sys_init() functionality of Wavlink AC3000 M33A8.V5030.210505. A specially crafted HTTP request can lead to arbitrary code execution. An attacker can make an unauthenticated HTTP request to trigger these vulnerabilities.

CONFIRMED VULNERABLE VERSIONS

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

PRODUCT URLS

Wavlink AC3000 - https://www.wavlink.com/en_us/product/WL-WN533A8.html

CVSSv3 SCORE

10.0 - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

CWE

CWE-77 - Improper Neutralization of Special Elements used in a Command (‘Command Injection’)

DETAILS

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.

When dealing with the login.cgi binary however, this login check does not exist, since the login.cgi is normally in charge of doing authentication, as such all login.cgi vulnerabilities are unauthenticated. Regardless of this, the basic code flow is the same, and our HTTP Post page parameter determines the code flow within our .cgi binary:

004010d0              int32_t contlen_int = strtol(getenv("CONTENT_LENGTH"), 0, 0xa)
004010e4              if (contlen_int - 1 u>= 0x1f3)
004014cc                  sprintf(&var_418, "http://%s/login.shtml?login=0", nvram_bufget(0, "lan_ipaddr"))
004014e4                  web_redirect_wholepage(&var_418)
// [...]
004018c8        else if (strcmp(page_decoded, "sysinit") == 0)
00401934             set_sys_init(inpbuf: malloc_contlen)

It’s worth noting that our Content-Length must be less than 0x1f3, but assuming so, if we provide page=sysinit, we appropriately enter the set_sys_init function and our provided POST data is further parsed therein:

0040464c  int32_t set_sys_init(char* inpbuf)
// [...]
0040481c      int32_t restart_hour_value_get_dup = strdup(web_get("restart_hour_value", inpbuf, 0)) // [1]
00404854      int32_t restart_min_value_get_dup = strdup(web_get("restart_min_value", inpbuf, 0))   // [2]
0040488c      int32_t restart_week_value_get_dup = strdup(web_get("restart_week_value", inpbuf, 0)) // [3]
// [...]
004049d8      if (sx.d(*restart_hour_value_get_dup) == 0 || (sx.d(*restart_hour_value_get_dup) != 0 && sx.d(*restart_min_value_get_dup) == 0))
004049f4          nvram_bufset(flag: 0, nvram_var_name: "SCH_Reboot", nvram_var_value: &data_407abc[0x24])
004049d8      if (sx.d(*restart_hour_value_get_dup) != 0 && sx.d(*restart_min_value_get_dup) != 0)
00405148          restart_week_value_ = restart_week_value_get_dup
00405158          snprintf(&sch_reboot_nvram, 0x80, "%s %s * * %s /sbin/sch_reboot.sh reboot", restart_min_value_get_dup, restart_hour_value_get_dup) // [4]
00405174          nvram_bufset(flag: 0, nvram_var_name: "SCH_Reboot", nvram_var_value: &sch_reboot_nvram)  // [5]

Our provided restart_hour [1] ,restart_min [2], and restart_week [3] POST parameters are all combined into a buffer [4], and then written to the SCH_Reboot nvram item at [5]. This buffer resembles a crontab item and as we will soon see within further scripts, this line will indeed be added to a crontab and run. To see this we must look at the system call to schedule.sh init at [6]:

// [...]
echo "0 12 * * * echo 3 > /proc/sys/vm/drop_caches" >> /var/spool/cron/crontabs/"$user"
echo "0 23 * * * echo 3 > /proc/sys/vm/drop_caches" >> /var/spool/cron/crontabs/"$user"
echo "0 23 * * * killall lighttpd" >> /var/spool/cron/crontabs/"$user"
echo "1 23 * * * lighttpd -f /etc_ro/lighttpd/lighttpd.conf -m /etc_ro/lighttpd/lib" >> /var/spool/cron/crontabs/"$user"
echo  "*/2  * * * * monitor_process.sh" >> /var/spool/cron/crontabs/"$user"
echo "0 5 * * * echo 0 > /tmp/url_filter_lib_state" >> /var/spool/cron/crontabs/"$user"
if [ N`nvram_get 2860 MeshMode` == "N1" ]
then
    echo  "*/1  * * * * generate_arp.sh" >> /var/spool/cron/crontabs/"$user"
fi
#           echo "0 3 * * * init_system restart" >> /var/spool/cron/crontabs/"$user"
crond

#check current time
while true
do
    ntp_year=`date "+%Y"`
    [ $ntp_year -gt 2000 ] && break
    sleep 20
done
killall crond
sleep 1

Inside of this script we can see a crontab being created for the adm2860 user and eventually written to /var/spool/cron/crontabs/adm2860. The script then waits until the ntp service is running and there is a correct date in place. Assuming so, it continues on with the following:

// [...]
echo "excute shc_reboot.sh"
sch_reboot.sh init
// [...]

Continuing into the /sbin/sch_reboot.sh script:

#!/bin/sh

# schedule reboot
user=`nvram_get 2860 Login`
SCH_Reboot=`nvram_get 2860 SCH_Reboot`

echo "$1"
if [ "$1" = "init" ]; then
        if [ "$SCH_Reboot" != "" ]; then
            echo "$SCH_Reboot" >> /var/spool/cron/crontabs/"$user"
        fi
fi

if [ "$1" = "reboot" ]; then
    reboot
fi

We clearly see our SCH_Reboot nvram item get read in and written into the adm2860 crontab. Thus, as long as our original restart_hour [1] ,restart_min [2], or restart_week [3] variables are formatted correctly, we can inject crontab configuration into the crontab and quickly establish code execution.

CVE-2024-39759 - restart_hour_value

0040464c  int32_t set_sys_init(char* inpbuf)
// [...]
0040481c      int32_t restart_hour_value_get_dup = strdup(web_get("restart_hour_value", inpbuf, 0)) 
// [...]
004049d8      if (sx.d(*restart_hour_value_get_dup) == 0 || (sx.d(*restart_hour_value_get_dup) != 0 && sx.d(*restart_min_value_get_dup) == 0))
004049f4          nvram_bufset(flag: 0, nvram_var_name: "SCH_Reboot", nvram_var_value: &data_407abc[0x24])
004049d8      if (sx.d(*restart_hour_value_get_dup) != 0 && sx.d(*restart_min_value_get_dup) != 0)
00405148          restart_week_value_ = restart_week_value_get_dup
00405158          snprintf(&sch_reboot_nvram, 0x80, "%s %s * * %s /sbin/sch_reboot.sh reboot", restart_min_value_get_dup, restart_hour_value_get_dup) 
00405174          nvram_bufset(flag: 0, nvram_var_name: "SCH_Reboot", nvram_var_value: &sch_reboot_nvram) 

Continuing into the /sbin/sch_reboot.sh script:

#!/bin/sh

# schedule reboot
user=`nvram_get 2860 Login`
SCH_Reboot=`nvram_get 2860 SCH_Reboot`

echo "$1"
if [ "$1" = "init" ]; then
        if [ "$SCH_Reboot" != "" ]; then
            echo "$SCH_Reboot" >> /var/spool/cron/crontabs/"$user"
        fi
fi

CVE-2024-39760 - restart_min_value

0040464c  int32_t set_sys_init(char* inpbuf)
// [...]
00404854      int32_t restart_min_value_get_dup = strdup(web_get("restart_min_value", inpbuf, 0))  
// [...]
004049d8      if (sx.d(*restart_hour_value_get_dup) == 0 || (sx.d(*restart_hour_value_get_dup) != 0 && sx.d(*restart_min_value_get_dup) == 0))
004049f4          nvram_bufset(flag: 0, nvram_var_name: "SCH_Reboot", nvram_var_value: &data_407abc[0x24])
004049d8      if (sx.d(*restart_hour_value_get_dup) != 0 && sx.d(*restart_min_value_get_dup) != 0)
00405148          restart_week_value_ = restart_week_value_get_dup
00405158          snprintf(&sch_reboot_nvram, 0x80, "%s %s * * %s /sbin/sch_reboot.sh reboot", restart_min_value_get_dup, restart_hour_value_get_dup) 
00405174          nvram_bufset(flag: 0, nvram_var_name: "SCH_Reboot", nvram_var_value: &sch_reboot_nvram) 

Continuing into the /sbin/sch_reboot.sh script:

#!/bin/sh

# schedule reboot
user=`nvram_get 2860 Login`
SCH_Reboot=`nvram_get 2860 SCH_Reboot`

echo "$1"
if [ "$1" = "init" ]; then
        if [ "$SCH_Reboot" != "" ]; then
            echo "$SCH_Reboot" >> /var/spool/cron/crontabs/"$user"
        fi
fi

CVE-2024-39761 - restart_week_value

0040464c  int32_t set_sys_init(char* inpbuf)
// [...]
0040488c      int32_t restart_week_value_get_dup = strdup(web_get("restart_week_value", inpbuf, 0)) 
// [...]
004049d8      if (sx.d(*restart_hour_value_get_dup) == 0 || (sx.d(*restart_hour_value_get_dup) != 0 && sx.d(*restart_min_value_get_dup) == 0))
004049f4          nvram_bufset(flag: 0, nvram_var_name: "SCH_Reboot", nvram_var_value: &data_407abc[0x24])
004049d8      if (sx.d(*restart_hour_value_get_dup) != 0 && sx.d(*restart_min_value_get_dup) != 0)
00405148          restart_week_value_ = restart_week_value_get_dup
00405158          snprintf(&sch_reboot_nvram, 0x80, "%s %s * * %s /sbin/sch_reboot.sh reboot", restart_min_value_get_dup, restart_hour_value_get_dup) 
00405174          nvram_bufset(flag: 0, nvram_var_name: "SCH_Reboot", nvram_var_value: &sch_reboot_nvram) 

Continuing into the /sbin/sch_reboot.sh script:

#!/bin/sh

# schedule reboot
user=`nvram_get 2860 Login`
SCH_Reboot=`nvram_get 2860 SCH_Reboot`

echo "$1"
if [ "$1" = "init" ]; then
        if [ "$SCH_Reboot" != "" ]; then
            echo "$SCH_Reboot" >> /var/spool/cron/crontabs/"$user"
        fi
fi
TIMELINE

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

Credit

Discovered by Lilith >_> of Cisco Talos.