Talos Vulnerability Report

SUMMARY

An external config control vulnerability exists in the openvpn.cgi openvpn_client_setup() 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 openvpn.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:

00400e9c                  if (strcmp(vpn_type, "client") == 0)
00400f6c                      openvpn_client_setup(contlen_malloc)

As shown above, when we provide vpn_type=client, we enter the openvpn_client_setup function and our provided POST data is further parsed therein.

004011b0  int32_t openvpn_client_setup(int32_t arg1)

00401210      int32_t sel_open_client_val = strdup(web_get("sel_open_client_val", arg1, 0))
0040122c      nvram_bufset(0, "openvpn_client_en", sel_open_client_val)
00401248      nvram_bufset(0, "openvpn_mode", &_0)
// [...]
00401280      nvram_bufset(0, "openvpn_client_en", sel_open_client_val)
00401298      nvram_commit(0)
004012bc      if (strcmp(sel_open_client_val, "1") != 0)  
00401484          system("/sbin/openvpn.sh disable&")
004012bc      else  // [1]
// [...]
00401378          int32_t $v0_6 = web_big_data_get("ovpn_text", arg1, 0)  // [2]
00401390          int32_t strlen = strlen($v0_6)
004013b0          int32_t client_ovpn_fd = open("/vendor/openvpn/client/client.ovpn", 0x302, 0x1a4) // [3]
004013bc          if (client_ovpn_fd s> 0)
004013c8              int32_t $s1_1 = 0
004013c4              if (strlen s> 0)
004013d4                  do
004013e8                      int32_t $v0_7 = write(client_ovpn_fd, $v0_6 + $s1_1, strlen - $s1_1) // [4]

Assuming that our sel_open_client_val POST parameter is set to “1”, then we enter the branch at [1] and our ovpn_text POST parameter is read into the heap at [2]. The binary then opens the /vendor/openvpn/client/client.ovpn file at [3], and writes our ovpn_text data into the file at [4], simple enough - we have complete control over the client’s openvpn configuration. To leverage this into something useful, we can simply insert a line like up "/bin/sh -c '<arbitrary_command>'", and we will run whatever commands we want when the client connection is initiated, which is something we can do through the web portal or through .cgi binaries.

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