Talos Vulnerability Report

SUMMARY

An external config control vulnerability exists in the nas.cgi set_nas() 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-15 - External Control of System or Configuration Setting

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 nas.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:

00400bfc          if (contlenp1 s>= 2)
00400c08              if (contlenp1 s>= 0x200)
00400d58                  contlenp1 = 0x200
00400c1c              char inpbuf[0x200]
00400c1c              memset(&inpbuf, 0, 0x200)
00400c38              fgets(&inpbuf, contlenp1, *stdin)
00400c54              int32_t $v0_8 = web_get("page", &inpbuf, 0)
// [...]
00400d08              else if (strcmp($v0_8, "nas") == 0)
00400d2c                  set_nas(&inpbuf)

While our input POST data is limited to 0x200 bytes, if we provide page=nas, we enter the set_nas function and our provided POST data is further parsed therein.

00401864  int32_t set_nas(int32_t arg1)

00401890      web_debug_header()
004018c4      int32_t User1Passwd = strdup(web_get("User1Passwd", arg1, 0))
004018ec      int32_t User1Passwd_1
// [...]
004018fc      if (sx.d(*User1Passwd) != 0)
004019fc          do_system("chpasswd.sh %s %s", "share", User1Passwd)
00401a18          nvram_bufset(0, "User1Passwd", User1Passwd)
// [...] 
00401d08          nvram_bufset(0, "SmbEnabled", web_get("smb_enabled", arg1, 1))  // [1]
00401d40          nvram_bufset(0, "HostName", web_get("smb_workgroup", arg1, 1))  // [2]
00401d78          nvram_bufset(0, "SmbNetBIOS", web_get("smb_netbios", arg1, 1))  // [3]
00401d90          nvram_commit(0)
00401da8          do_system("storage.sh ftp")
00401dc0          sleep(5)
00401dc8          set_smb()


00401030  int32_t set_smb()
00401050      nvram_bufget(0, "Login")
0040106c      return do_system("storage.sh samba") __tailcall // [4]

In these functions we take our three HTTP POST parameters smb_enabled, smb_workgroup, and smb_netbios at [1], [2], and [3] respectively, throw them into nvram and then hit the call to storage.sh samba at [4]:

"samba")
    if [ "$CONFIG_NF_SHORTCUT_HOOK" = "y" ]; then
        rmmod nf_sc
    fi
    killall -q nmbd
    killall -q smbd
    smp.sh wifi
    echo 3 > /proc/sys/vm/drop_caches
    echo 2048 > /proc/sys/vm/min_free_kbytes
    if [ ! -e "$PART1" ]; then
        rm /etc/smb.conf
        echo "1st partition does not exist"
        exit 0
    fi
    smbenabled=`nvram_get 2860 SmbEnabled`
    if [ "$smbenabled" == "1" ]; then
        rm /etc/smb.conf      // [5]
        setSmb                // [6]

Assuming our smb_enabled argument is “1”, then the script deletes the existing /etc/smb.conf [5] and eventually regenerates it within setSmb()[6]:

setSmb()
{
    killall smbd
    killall nmbd
    smbnetbios=`nvram_get 2860 SmbNetBIOS`
    smbwg=`nvram_get 2860 HostName`
    echo "samba.sh "$smbnetbios" "$smbwg" "$PART1""
    samba.sh "$smbnetbios" "$smbwg" "$PART1"

The smbd and nmbd services are killed and we run the samba.sh script with our input smb_netbios [3] and smb_workgroup [2] arguments from before. Continuing in samba.sh:

#!/bin/sh
. /sbin/config.sh

opmode=`nvram_get 2860 OperationMode`
SAMBA_FILE=/etc/smb.conf

// [...]
NETBIOS_NAME="$1"
WORKGROUP="$2"
LOGPATH="$3"

echo "$LOGPATH"

echo "[global]
min receivefile size = 8192
use sendfile = yes
use mmap = yes
load printers = no
netbios name = $NETBIOS_NAME // [7]
server string = Samba Server
workgroup = admin2860
security = user
log file = /var/log.samba
encrypt passwords = yes
disable spoolss = yes
host msdfs = no
strict allocate = No
os level = 20
log level = 0
max log size = 100
dos charset = ASCII
unix charset = UTF8
display charset = UTF8
guest account = share
bind interfaces only = no" > $SAMBA_FILE

While only our smb_netbios input is directly written into the /etc/smb.conf file [7], we still need to provide a smb_workgroup or else the script does not fully run. Regardless, since there’s no character filtering on our smb_netbios, we can utilize newlines to write in entirely arbitrary samba configuration. The most efficient way to gain shell access from this vulnerability is to utilize the root preexec configuration line, which allows us to put arbitrary shell commands to be run whenever someone connects to the samba server, however there are also other ways of leveraging this power.

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