Talos Vulnerability Report

SUMMARY

A command execution vulnerability exists in the qos.cgi qos_sta() 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.

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

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

CWE

CWE-74 - Improper Neutralization of Special Elements in Output Used by a Downstream Component (‘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.

Assuming that we’ve passed this check in the qos.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:

00400ce0                  int32_t $v0_9 = web_get("page", $v0_7, 0)
// [...]
00400d08                  else if (strcmp($v0_9, "qos_sta") == 0)
00400ebc                      qos_sta_settings($v0_7)

If we provide page=qos_sta, we enter the qos_sta_settings function and our provided POST data is further parsed therein:

00401508  int32_t qos_sta_settings(int32_t arg1)

0040155c      int32_t cli_list_1 = strdup(web_get("cli_list", arg1, 0))
00401594      int32_t cli_num_1 = strdup(web_get("cli_num", arg1, 0))
004015cc      int32_t time_control_num_1 = strdup(web_get("time_control_num", arg1, 0))
// [...]
0040165c      nvram_bufset(0, "TIME_CONTROL_STA_NUM", time_control_num_1)
00401680      if (atoi(time_control_num_1) s<= 0)              // [1]
00401864          remove("/vendor/time_control_sta_list")
00401884          nvram_bufset(0, "TIME_CONTROL", &data_4033d4)
00401680      else
004016b0          int32_t $v0_6 = strdup(web_get("time_control", arg1, 0)) // [2]
004016cc          int32_t control_sta_list_fd = open("/vendor/time_control_sta_list", 0x302)  
004016d8          if (control_sta_list_fd s>= 0)
00401704              write(control_sta_list_fd, $v0_6, strlen($v0_6)) // [3]
0040171c              close(control_sta_list_fd)

Among the different POST parameters that this function can read in, we see that if our time_control_num POST parameter is any number greater than zero [1], then we read in the time_control POST parameter at [2]. This input is then written to the /vendor/time_control_sta_list file at [3]. This file is accessed by five different scripts:

sbin/sta_time_control_mesh.sh:    sta_data=`cat /vendor/time_control_sta_list`
sbin/sta_time_control.sh:    sta_data=`cat /vendor/time_control_sta_list `
etc_ro/lighttpd/www/cgi-bin/get_device.sh:time_control=`cat /vendor/time_control_sta_list `
etc_ro/lighttpd/www/cgi-bin/sta_data_mac_rep.sh:time_control=`cat /vendor/time_control_sta_list` 
etc_ro/lighttpd/www/cgi-bin/sta_data.sh:time_control=`cat /vendor/time_control_sta_list `        

Since we only need injection once, we will only talk about the /sbin/sta_time_control.sh init script, which is run by /sbin/schedule.sh once the NTP service has been started running and has successfully synchronized time (which will happen if the device is connected via WAN to the internet). Continuing within sta_time_control.sh init, we will call the data_init() function therein:

data_init() {
    user=`nvram_get 2860 Login`
    clean_old_rule
    [ N`nvram_get 2860 TIME_CONTROL_STA_NUM` == "N" ] && exit 0
    [ N`nvram_get 2860 TIME_CONTROL_STA_NUM` == "N0" ] && exit 0
    sta_data=`cat /vendor/time_control_sta_list `                // [4]
    sta_num=`echo $sta_data| awk -F'#' '{print NF-1}' `
    date_num=`date +%w `
    for i in `seq 1 $sta_num`
    do
        data=`echo $sta_data|cut -d '#' -f $i`
        mac=`echo $data|cut -d ',' -f 1`
        block_all=`echo $data|cut -d ',' -f 2`

        if [ $block_all == "1" ]
        then
            iptables -I FORWARD  -m mac --mac-source "$mac" -j DROP
            echo $mac >> /tmp/time_control_sta
            continue
        fi

        for k in `seq 1 7`
        do
            start_time=`echo $data|cut -d ',' -f  $(expr 2 + 2 \* $k - 1)`
            end_time=`echo $data|cut -d ',' -f  $(expr 2 + 2 \* $k )`
            [ $start_time == "00:00" ] && [ $end_time == "00:00" ] && continue
            start_hour=`echo $start_time|cut -d ':' -f 1`
            start_min=`echo $start_time|cut -d ':' -f 2`
            end_hour=`echo $end_time|cut -d ':' -f 1`
            end_min=`echo $end_time|cut -d ':' -f 2`
            echo "$start_min $start_hour * * $k /sbin/sta_time_control.sh off $mac" >> /var/spool/cron/crontabs/"$user"  // [5]
            echo "$end_min $end_hour * * $k /sbin/sta_time_control.sh on $mac" >> /var/spool/cron/crontabs/"$user"       // [6]

We can see our data being read in at [4], and then some basic parsing occurs on it immediately after. Following this, we write directly to a crontab at [5] and [6]. Without really caring much about the preprocessing, it suffices to say that we can simply inject commands to be run into the crontab relatively easily with this script, the only thing to watch out for is if we include a “ * “ within our data, it gets globbed out and messes with the final result. This can be avoided either by only using numbers for the crontab scheduling, or by using “*/1" for instance, which will still let us run commands more frequently but without the globbing.

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