WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 wireless.cgi has no filtering on parameters: delete_list, delete_al_mac, b_delete_list and b_delete_al_mac, which leads to command injection in page /wifi_mesh.shtml.

**WAVLINK Router AC1200 page /wizard\_router\_mesh.shtml Command Injection in adm.cgi****Description:**

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 adm.cgi has no filtering on parameters: web_pskValue, wl_Method, wlan_ssid, EncrypType, rwan_ip, rwan_mask, rwan_gateway, ppp_username, ppp_passwd and ppp_setver, which leads to command injection in page /wizard\_router\_mesh.shtml.

   

**Poc:**

Login is needed.

Visit /wizard\_router\_mesh.shtml.

When setting ""Router Mode" it redirects to /cgi-bin/adm.cgi with POST parameters: web_pskValue, wl_Method, wlan_ssid, EncrypType, rwan_ip, rwan_mask, rwan_gateway, ppp_username, ppp_passwd and ppp_setver. Use "xxx;command" for command injection.

**WAVLINK Router AC1200 page /ledonoff.shtml Command Injection in adm.cgi****Description:**

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 adm.cgi has no filtering on parameter led_switch, which leads to command injection in page /ledonoff.shtml.

**Poc:**

Login is needed.

Visit /ledonoff.shtml.

When switching LED, it redirects to /cgi-bin/adm.cgi with POST parameter led_switch. Use "xxx;command" for command injection.

**WAVLINK Router AC1200 page /wan.shtml Command Injection in adm.cgi****Description:**

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 adm.cgi has no filtering on parameters: ppp_username, ppp_passwd, rwan_gateway, rwan_mask and rwan_ip, which leads to command injection in page /wan.shtml.

 

**Poc:**

Login is needed.

Visit /wan.shtml.

When setting "WAN" it redirects to /cgi-bin/adm.cgi with POST parameters: ppp_username, ppp_passwd, rwan_gateway, rwan_mask and rwan_ip. Use "xxx;command" for command injection.

**WAVLINK Router AC1200 page /wizard\_rep.shtml Command Injection in adm.cgi****Description:**

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 adm.cgi has no filtering on parameters: wlan_signal, web_pskValue, sel_EncrypTyp, sel_Automode, wlan_bssid, wlan_ssid and wlan_channel, which leads to command injection in page /wizard\_rep.shtml.

  

**Poc:**

Login is needed.

Visit /wizard\_rep.shtml.

When setting "Repeater Mode" it redirects to /cgi-bin/adm.cgi with POST parameters: wlan_signal, web_pskValue, sel_EncrypTyp, sel_Automode, wlan_bssid, wlan_ssid and wlan_channel. Use "xxx;command" for command injection.

 

**WAVLINK Router AC1200 page /ledonoff.shtml hidden parameter "ufconf" Command Injection in api.cgi****Description:**

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 api.cgi has no filtering on parameter ufconf, and this is a hidden parameter which doesn't appear in POST body, but exist in cgi binary. This leads to command injection in page /ledonoff.shtml.

**Poc:**

Login is needed.

Visit /ledonoff.shtml.

When switching LED, it redirects to /cgi-bin/adm.cgi. Change url as /cgi-bin/api.cgi and add ufconf in POST body as a parameter. Use "xxx;command" for command injection.

**Command Injection occurs when deleting blacklist in WAVLINK Router AC1200 page /cli\_black\_list.shtml in firewall.cgi****Description:**

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 firewall.cgi has no filtering on parameter add_mac, which leads to command injection in page /cli\_black\_list.shtml.

**Poc:**

Login is needed.

Visit /cli\_black\_list.shtml.

When adding WIFI blacklist, it redirects to /cgi-bin/firewall.cgi with POST parameter add_mac. Use "xxx;command" for command injection.

**Command Injection occurs when adding blacklist in WAVLINK Router AC1200 page /cli\_black\_list.shtml in firewall.cgi****Description:**

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 firewall.cgi has no filtering on parameter del_mac and parameter flag, which leads to command injection in page /cli\_black\_list.shtml.

**Poc:**

Login is needed.

Visit /cli\_black\_list.shtml.

When deleting WIFI blacklist, it redirects to /cgi-bin/firewall.cgi with POST parameters: del_mac and flag. Use "xxx;command" for command injection.

**WAVLINK Router AC1200 page /man\_security.shtml Command Injection in firewall.cgi****Description:**

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 firewall.cgi has no filtering on parameters: remoteManagementEnabled, blockPortScanEnabled, pingFrmWANFilterEnabled and blockSynFloodEnabled, which leads to command injection in page /man\_security.shtml.

**Poc:**

Login is needed.

Visit /man\_security.shtml.

When setting system firewall, it redirects to /cgi-bin/firewall.cgi with POST parameters: remoteManagementEnabled, blockPortScanEnabled, pingFrmWANFilterEnabled and blockSynFloodEnabled. Use "xxx;command" for command injection.

**WAVLINK Router AC1200 page /login.shtml Command Injection in login.cgi****Description:**

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 login.cgi has no filtering on parameter key, which leads to command injection in page /login.shtml.

 

**Poc:**

Visit /login.shtml.

When clicking login, it redirects to /cgi-bin/login.cgi with POST parameter key. Use "xxx;command" for command injection.

**WAVLINK Router AC1200 page /nas\_disk.shtml Command Injection in nas.cgi****Description:**

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 nas.cgi has no filtering on parameters: User1Passwd and User1, which leads to command injection in page /nas\_disk.shtml.

**Poc:**

Login is needed.

Visit /nas\_disk.shtml.

When clicking the button, it redirects to /cgi-bin/nas.cgi with POST parameters: User1Passwd and User1. Use "xxx;command" for command injection.

**WAVLINK Router AC1200 page /qos.shtml hidden parameters Command Injection in qos.cgi****Description:**

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 qos.cgi has no filtering on parameters: cli_list and cli_num, which leads to command injection in page /qos.shtml.

**Poc:**

Login is needed.

Visit /qos.shtml.

 

When clicking the button, it redirects to /cgi-bin/qos.cgi. Modify POST packet and add parameters: cli_list and cli_num. Use "xxx;command" for command injection.

**WAVLINK Router AC1200 page /qos.shtml Command Injection in qos.cgi****Description:**

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 qos.cgi has no filtering on parameters: qos_bandwith and qos_dat, which leads to command injection in page /qos.shtml.

**Poc:**

Login is needed.

Visit /qos.shtml.

 

When clicking the button, it redirects to /cgi-bin/qos.cgi with POST parameters: qos_bandwith and qos_dat. Use "xxx;command" for command injection.

**WAVLINK Router AC1200 page /wifi\_multi\_ssid.shtml Command Injection in wireless.cgi****Description:**

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 wireless.cgi has no filtering on parameter hiddenSSID32g and SSID2G2, which leads to command injection in page /wifi\_multi\_ssid.shtml.

  

**Poc:**

Login is needed.

Visit /wifi\_multi\_ssid.shtml

When setting WIFI SSID to extend, it redirects to /cgi-bin/wireless.cgi with POST parameter hiddenSSID32g and SSID2G2. Use "xxx;command" for command injection.

 

**WAVLINK Router AC1200 page /wifi\_mesh.shtml hidden parameter Command Injection in wireless.cgi****Description:**

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 wireless.cgi has no filtering on parameters: mac_5g and Newname, which leads to command injection in page /wifi\_mesh.shtml.

**Poc:**

Login is needed.

Visit /wifi\_mesh.shtml

When clicking the button, it redirects to /cgi-bin/wireless.cgi. Modify the POST packet and add parameter mac_5g and Newname. Use "xxx;command" for command injection.

**Command Injection occurs when adding extender in WAVLINK Router AC1200 page /wifi\_mesh.shtml in wireless.cgi****Description:**

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 wireless.cgi has no filtering on parameter macAddr, which leads to command injection in page /wifi\_mesh.shtml.

**Poc:**

Login is needed.

Visit /wifi\_mesh.shtml

When adding the extender, it redirects to /cgi-bin/wireless.cgi with POST parameter macAddr. Use "xxx;command" for command injection.

**Command Injection occurs when clicking the button in WAVLINK Router AC1200 page /wifi\_mesh.shtml in wireless.cgi****Description:**

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 wireless.cgi has no filtering on parameters: delete_list, delete_al_mac, b_delete_list and b_delete_al_mac, which leads to command injection in page /wifi\_mesh.shtml.

**Poc:**

Login is needed.

Visit /wifi\_mesh.shtml  When clicking the button, it redirects to /cgi-bin/wireless.cgi with POST parameters: delete_list, delete_al_mac, b_delete_list and b_delete_al_mac. Use "xxx;command" for command injection.

CVE-2022-35538: othercveinfo/wavlink at main · TyeYeah/othercveinfo

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 wireless.cgi has no filtering on parameter macAddr, which leads to command injection in page /wifi_mesh.shtml.

CVE-2022-35535: othercveinfo/wavlink at main · TyeYeah/othercveinfo

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 wireless.cgi has no filtering on parameters: mac_5g and Newname, which leads to command injection in page /wifi_mesh.shtml.

CVE-2022-35537: othercveinfo/wavlink at main · TyeYeah/othercveinfo

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 nas.cgi has no filtering on parameters: User1Passwd and User1, which leads to command injection in page /nas_disk.shtml.

CVE-2022-35518: othercveinfo/README.md at main · TyeYeah/othercveinfo

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 firewall.cgi has no filtering on parameters: remoteManagementEnabled, blockPortScanEnabled, pingFrmWANFilterEnabled and blockSynFloodEnabled, which leads to command injection in page /man_security.shtml.

CVE-2022-35521: othercveinfo/README.md at main · TyeYeah/othercveinfo

WAVLINK WN572HP3, WN533A8, WN530H4, WN535G3, WN531P3 api.cgi has no filtering on parameter ufconf, and this is a hidden parameter which doesn't appear in POST body, but exist in cgi binary. This leads to command injection in page /ledonoff.shtml.

CVE-2022-35520: othercveinfo/README.md at main · TyeYeah/othercveinfo

New research found troubling vulnerabilities in the 5G platforms carriers offer to wrangle embedded device data.

True 5G wireless data, with its ultrafast speeds and enhanced security protections, has been slow to roll out around the world. As the mobile technology proliferates—combining expanded speed and bandwidth with low latency connections—one of its most touted features is starting to come into focus. But the upgrade comes with its own raft of potential security exposures.

A massive new population of 5G-capable devices, from smart city sensors to agriculture robots and beyond, are gaining the ability to connect to the internet in places where Wi-Fi isn't practical or available. Individuals may even elect to trade their fiber optic internet connection for a home 5G receiver. New research that will be presented on Wednesday at the Black Hat security conference in Las Vegas, though, warns that the interfaces carriers have set up to manage internet of things data are riddled with security vulnerabilities they fear will dog the industry long term.

After years of examining potential security and privacy issues in mobile data radio frequency standards, Technical University of Berlin researcher Altaf Shaik says he was curious to investigate the application programming interfaces (APIs) carriers are offering to make IoT data accessible to developers. These are the conduits applications can use to pull, say, real-time bus tracking data or information about stock in a warehouse. Such APIs are ubiquitous in web services, but Shaik points out that they haven't been widely used in core telecommunications offerings. Looking at the 5G IoT APIs of 10 mobile carriers around the world, Shaik and his colleague Shinjo Park found common, widely-known API vulnerabilities in all of them, and some could be exploited to gain authorized access to data or even direct access to IoT devices on the network.

“There's a big knowledge gap, this is the beginning of a new type of attack in telecom,” Shaik told WIRED ahead of his presentation. “There's a whole platform where you get access to the APIs, there’s documentation, everything, and it's called something like ‘IoT service platform.’ Every operator in every country is going to be selling them if they're not already, and there are virtual operators and subcontracts, too, so there will be a ton of companies offering this kind of platform.”

The designs of IoT service platforms aren’t specified in the 5G standard and are up to each carrier and company to create and deploy. That means there's widespread variation in their quality and implementation. In addition to 5G, upgraded 4G networks can also support some IoT expansion, widening the number of carriers that may offer IoT service platforms and the APIs that feed them.

The researchers bought IoT plans on the 10 carriers they analyzed and got special data-only SIM cards for their networks of IoT devices. This way they had the same access to the platforms as any other customer in the ecosystem. They found that basic flaws in how the APIs were set up, like weak authentication or missing access controls, could reveal SIM card identifiers, SIM card secret keys, the identity of who purchased which SIM card, and their billing information. And in some cases, the researchers could even access large streams of other users' data or even identify and access their IoT devices by sending or replaying commands that they shouldn’t have been able to control.

The researchers went through disclosure processes with the 10 carriers they tested and said that the majority of vulnerabilities they found so far are being fixed. Shaik notes that the quality of security protections on the IoT service platforms varied widely, with some appearing more mature while others were “still sticking to the same old, bad security policies and principles.” He adds that the group isn't publicly naming the carriers they looked at in this work because of concerns about how widespread the issues might be. Seven of the carriers are based in Europe, two are in the United States, and one is in Asia.

“We found vulnerabilities that could be exploited to access other devices even though they don’t belong to us, just by being on the platform,” Shaik says. “Or we could talk to other IoT devices and send messages, extract information. It’s a big issue.”

Shaik emphasizes that he and his colleagues didn’t hack any other customers or do anything improper once they discovered the different flaws. But he points out that none of the carriers detected the researchers’ probing, which in itself indicates a lack of monitoring and safeguards, he says.

The findings are just a first step, but they underscore the challenges of securing massive new ecosystems as the full breadth and scale of 5G starts to appear on the horizon.

One of 5G's Biggest Features Is a Security Minefield

The new Pretty Good Phone Privacy service for Android hides the data linking you to your mobile device.

As marketers, data brokers, and tech giants endlessly expand their access to individuals’ data and movements across the web, tools like VPNs or cookie blockers can feel increasingly feeble and futile. Short of going totally off the grid forever, there are few options for the average person to meaningfully resist tracking online. Even after coming up with a technical solution last year for how phone carriers could stop automatically collecting users’ locations, researchers Barath Raghavan and Paul Schmitt knew it would be challenging to convince telecoms to implement the change. So they decided to be the carrier they wanted to see in the world.

The result is a new company, dubbed Invisv, that offers mobile data designed to separate users from specific identifiers so the company can’t access or track customers’ metadata, location information, or mobile browsing. Launching in beta today for Android, the company’s Pretty Good Phone Privacy or PGPP service will replace the mechanism carriers normally use to turn cell phone tower connection data into a trove of information about users’ movements. And it will also offer a Relay service that disassociates a user’s IP address from their web browsing.

“If you can decouple a user’s identity from the way they connect to a network, that’s a general-purpose hammer that can solve a lot of privacy problems,” says Raghavan, a professor at the University of Southern California. “Privacy should be the default and it’s not currently, so we’re working on that. There’s a growing appetite as people become more concerned about what their phone is leaking to telecoms and tech companies.”

PGPP’s ability to mask your phone’s identity from cell towers comes from a revelation about why cell towers collect the unique identifiers known as IMSI numbers, which can be tracked by both telecoms and other entities that deploy devices known as IMSI catchers, often called stringrays, which mimic a cell tower for surveillance purposes. Raghavan and Schmitt realized that at its core, the only reason carriers need to track IMSI numbers before allowing devices to connect to cell towers for service is so they can run billing checks and confirm that a given SIM card and device are paid up with their carrier. By acting as a carrier themselves, Invisv can implement their PGPP technology that simply generates a “yes” or “no” about whether a device should get service. 

On the PGPP “Mobile Pro” plan, which costs $90 per month, users get unlimited mobile data in the US and, at launch, unlimited international data in most European Union countries. Users also get 30 random IMSI number changes per month, and the changes can happen automatically (essentially one per day) or on demand whenever the customer wants them. The system is designed to be blinded so neither INVISV nor the cell towers you connect to know which IMSI is yours at any given time. There’s also a “Mobile Core” plan for $40 per month that offers eight IMSI number changes per month and 9 GB of high-speed data per month.

Both of these plans also include PGPP’s Relay service. Similar to Apple’s iCloud Private Relay, PGPP’s Relay is a method for blocking everyone, from your internet provider or carrier to the websites you visit, from knowing both who you are and what you’re looking at online at the same time. Such relays send your browsing data through two way stations that allow you to browse the web like normal while shielding your information from the world. When you navigate to a website, your IP address is visible to the first relay—in this case, Invisv—but the information about the page you’re trying to load is encrypted. Then the second relay generates and connects an alternate IP address to your request, at which point it is able to decrypt and view the website you’re trying to load. The content delivery network Fastly is working with Invisv to provide this second relay. Fastly is also one of the third-party providers for iCloud Private Relay.

In this way, each relay knows some of the information about your browsing; the first simply knows that you are using the web, and the second sees the sites you connect to, but not who specifically is browsing there. In addition to being included in the two PGPP data plans, customers can also purchase the Relay service on its own for $5 per month and turn it on while connected to mobile data or Wi-Fi. 

“User privacy has historically been in the backseat for internet systems,” says Jana Iyengar, Fastly’s product lead for infrastructure services. “At Fastly, we have always believed that communication and data privacy is fundamental to the future of the internet. We believe it is time to invest, engage, and create products that will move the internet forward in this direction.”

Invisv is still working to bring its services to Apple’s iOS, and the company doesn’t provide voice calling services, only mobile data. But Raghavan and Schmitt say that their goal for this initial launch was to start offering something that would give customers drastically more privacy protection than what they get from other mobile carriers while being truly easy to use.

“The reason we’re doing this, honestly, is that it’s clear nobody else is going to do it,” Schmitt says. “I’m hopeful that people will just start to see what's possible from this, so we can start to make a dent.”

A Phone Carrier That Doesn’t Track Your Browsing or Location

In Airspan AirSpot 5410 version 0.3.4.1-4 and under there exists a Unauthenticated remote command injection vulnerability. The ping functionality can be called without user authentication when crafting a malicious http request by injecting code in one of the parameters allowing for remote code execution. This vulnerability is exploited via the binary file /home/www/cgi-bin/diagnostics.cgi that accepts unauthenticated requests and unsanitized data. As a result, a malicious actor can craft a specific request and interact remotely with the device.

**Airspan AirSpot 5410 vulnerabilities.****Product description:  
**

The AirSpot 5410 from Airspan is an advanced, LTE, CAT12, outdoor, multi-service antenna that provides a Gigabit PoE connection to connect user terminal devices, such as a router or WiFi AP products.  

**Affected products:  
**

All Airspan AirSpot 5410 devices from version 0.3.4.1-4 and under.

**Summary of the 4 vulnerabilities found / What we were able to find:**

*   Vulnerability 1 - Unauthenticated remote Persistent Cross-site Scripting (Stored XSS).  
    As the binary file /home/www/cgi-bin/login.cgi does not check if the user is authenticated, a malicious actor can craft a specific request on the login.cgi endpoint that contains a base32 encoded XSS payload that will be accepted and stored. A successful attack will results in the injection of malicious scripts into the user settings page.
    
*   Vulnerability 2 - Unauthenticated remote command injection.  
    The ping functionality can be called without user authentication but can also be injected by any Linux command. This vulnerability is exploited via the binary file /home/www/cgi-bin/diagnostics.cgi that accept unauthenticated request and unsanitized data. As a result, a malicious actor can craft a specific request and interact remotely with the device.
    
*   Vulnerability 3 - Unauthenticated remote Arbitrary File Upload.  
    Unrestricted file upload allows overwriting arbitrary files. A malicious actor can remotely upload the file of his choice and overwrite any file in the system by manipulating the filename and append a relative path that will be interpreted during the upload process. Using this method, it is possible to rewrite any file in the system.
    
*   Vulnerability 4 - Hidden system command web page.  
    After performing a reverse engineering of the firmware we discovered that a hidden page not listed in the administration management interface allows to execute Linux commands on the device with root privileges. From here we had access to all the system files but also be able to change the root password and have full access on the device.
    

**Step by Step Example (How to Reproduce and verify) the vulnerabilities:****Unauthenticated remote Persistent Cross-site Scripting (Stored XSS).**

1.  As the application encodes all data in Base32 we will start by encode our XSS payload.  
    
2.  Once our payload is encoded we will craft the malicious request.  
      
    As we can see in the server response, our request has been granted.
    
3.  When a legitimate user access the User Settings page of the web management interface, the JavaScript payload will be triggered.  
    

**Unauthenticated remote command injection.**

1.  For this command injection example we have decided to display the contents of the /etc/passwd file, for this we will inject the targetIP variable as follows:  
      
    We can see that our request was perfectly accepted by the server without being authenticated.
    
2.  Now the second step is to get the result of our malicious injected ping command. To do this we will call the same endpoint diagnotics.cgi but this time with the command getReport.  
      
    
3.  The server returns a response in XML format, the key pingDiactnostic contains the result of the injected ping command encoded in hexadecimal.  
    

**Hidden system command web page.**

Once logged on the web administration interface using the default credentials admin:admin it is possible to access the hidden page superconsole.html, from this page it is now possible to execute the Linux commands of our choice as root. We have for example in the following screenshot display the contents of the /etc/passwd file with the root hard coded hash.  

**Unauthenticated remote Arbitrary File Upload.**

1.  This vulnerability gives us the possibility to overwrite any file on the device by taking advantage of the restore backup function which allows us to upload a backup of the configuration file. For this example we will show how it is possible to override the /etc/passwd file and add a backdoor account called pwned remotely and without being authenticated.  
    
2.  Now that our fake passwd file is ready we will send our evil crafted request to the endpoint update.cgi which does not check if the requests are authenticated. We will also modify the filename by a relative path which will rewrite the original passwd by our fake passwd file.  
    
3.  We can now login to the telnet port using our pwned account which has root privileges.  
    

**Recommendations for how to fix the 4 vulnerabilities:**

*   Vulnerability 1 (To Fix/Remediate): Make sure that all requests to /home/www/cgi-bin/login.cgi are authenticated, and also verify that all data sent to the server, even encoded, are sanitized to avoid any injections.
    
*   Vulnerability 2: Make sure that all requests to /home/www/cgi-bin/diagnostics.cgi are authenticated, it is also important to strengthen the back-end logic to make sure that the data sent to the server are clean.
    
*   Vulnerability 3: Make sure that all requests to /home/www/cgi-bin/update.cgi are authenticated, also make sure set a very strict file storage location, better filename sanitizaion logic, file content validation rule.
    
*   Vulnerability 4: The pages /home/www/superconsole.html and /home/www/cgi-bin/superconsole.cgi should be removed from the devices in production, as the default password is very weak admin:admin it is easy for any attacker to inject a backdoor on the device through this page.
    

**Reference:**

https://wdi.rfwel.com/cdn/techdocs/AirSpot5410.pdf  
https://www.airspan.com/

**Security researchers:**

*   Thomas Knudsen
*   Samy Younsi

CVE-2022-36267: Airspan-AirSpot-5410.md

A stack-based buffer overflow vulnerability exists in the confers ucloud_add_node_new functionality of TCL LinkHub Mesh Wi-Fi MS1G_00_01.00_14. A specially-crafted network packet can lead to stack-based buffer overflow. An attacker can send a malicious packet to trigger this vulnerability.

**SUMMARY**

A stack-based buffer overflow vulnerability exists in the confers ucloud\_add\_node\_new functionality of TCL LinkHub Mesh Wi-Fi MS1G\_00\_01.00\_14. A specially-crafted network packet can lead to stack-based buffer overflow. An attacker can send a malicious packet 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.

TCL LinkHub Mesh Wifi MS1G\_00\_01.00\_14

**PRODUCT URLS**

LinkHub Mesh Wifi - https://www.tcl.com/us/en/products/connected-home/linkhub/linkhub-mesh-wifi-system-3-pack

**CVSSv3 SCORE**

8.8 - CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

**CWE**

CWE-121 - Stack-based Buffer Overflow

**DETAILS**

The LinkHub Mesh Wi-Fi system is a node-based mesh system designed for Wi-Fi deployments across large homes. These nodes include most features standard in current Wi-Fi solutions and allow for easy expansion of the system by adding nodes. The mesh is managed solely by a phone application and the routers have no web-based management console.

The LinkHub Mesh system uses protobuffers to communicate both internally on the device as well as externally with the controlling phone application. These protobuffers can be sent to port 9003 while on the Wi-Fi provided by the LinkHub Mesh in order to issue commands, much like the phone application would. Once the protobuffer is received, it is routed internally starting from the ucloud binary and is dispatched to the appropriate handler.

In this case, the handler is confsrv which handles many message types, in this case we are interested in ManualNodeInfo

    message ManualNodeInfo {
        required string serialNumMd5 = 1;        [1]
        optional uint64 timestamp = 2;
    } 
    

At \[1\] we have control over serialNumMd5 in the packet. The parsing of the protobuffer data occurs in ucloud_add_node_new

    0042876c  int32_t ucloud_add_node_new(int32_t arg1, int32_t arg2, int32_t arg3)
    
    0042878c      arg_0 = arg1
    00428798      int32_t $a3
    00428798      arg_c = $a3
    004287bc      printf("%s(%d)\n", "ucloud_add_node_new", 0x756)
    004287c8      int32_t var_b0 = 0
    004287cc      int32_t var_ac = 0
    004287d0      int32_t var_a8 = 0
    004287d4      int32_t var_a4 = 0
    004287d8      int32_t var_a0 = 0
    004287dc      int32_t var_9c = 0
    004287e0      int32_t var_98 = 0
    004287e4      int32_t var_94 = 0
    004287e8      int32_t var_90 = 0
    00428808      void var_8c
    00428808      memset(&var_8c, 0, 0x80)
    00428818      int32_t $v0_1
    00428818      if (arg2 == 0) {
    00428840          printf("ManualNodeInfo is NULL%s(%d)\n", "ucloud_add_node_new", 0x75d)
    0042884c          $v0_1 = 0xffffffff
    0042884c      } else {
    00428874          struct ManualNodeInfo* pkt = manual_node_info__unpack(0, arg3, arg2)
    00428888          if (pkt == 0) {
    004288b0              printf("manual_node_info__unpack error%s…", "ucloud_add_node_new", 0x766)
    004288bc              $v0_1 = 0xffffffff
    004288bc          } else {
    004288d0              if (pkt->serialNumberMd5 == 0) {
    00428938                  printf("[arainc][NodeInfo->serialnummd5 …", "ucloud_add_node_new", 0x76f)
    0042892c              } else {
    00428904                  printf("[arainc][NodeInfo->serialnummd5 …", pkt->serialNumberMd5, "ucloud_add_node_new", 0x76d, 0x4ae4b0)
    00428788              }
    00428958              update_add_node_list(serial_number: pkt->serialNumberMd5)
    00428988              sprintf(&var_8c, "echo %s >> /proc/mesh/authorized", pkt->serialNumberMd5)                                     [2]
    004289bc              printf("[arainc][cmd_tmp = %s]%s(%d)\n", &var_8c, "ucloud_add_node_new", 0x773, 0x4ae4b0)
    004289d8              doSystemCmd(&var_8c)
    004289ec              if (pkt->__offset(0x10).d != 0) {
    00428a1c                  sprintf(&var_ac, "%llu", pkt->timestamp.d, pkt->timestamp:4.d)
    00428a40                  SetValue(name: "sys.cfg.stamp", input_buffer: &var_ac)
    00428a34              }
    00428a54              CommitCfm()
    00428a70              manual_node_info__free_unpacked(pkt, 0)
    00428a7c              $v0_1 = 0
    00428a7c          }
    00428a7c      }
    00428a90      return $v0_1 
    

Looking at the assembly at \[2\]

    0042896c  1800c28f   lw      $v0, 0x18($fp) {var_b0_1}
    00428970  0c00428c   lw      $v0, 0xc($v0) {ManualNodeInfo::serialNumberMd5}
    00428974  3c00c427   addiu   $a0, $fp, 0x3c {var_8c}
    00428978  21286000   move    $a1, $v1  {data_4810d8, "echo %s >> /proc/mesh/authorized"}
    0042897c  21304000   move    $a2, $v0
    00428980  0088828f   lw      $v0, -0x7800($gp)  {sprintf}
    00428984  21c84000   move    $t9, $v0
    00428988  09f82003   jalr    $t9
    0042898c  00000000   nop    
    

We see this is a straightforward heap buffer overflow. The serialNumberMd5 is taken directly from the packet and passed into a %s formatter without any length limits. The buffer is 0x80 bytes long, and thus, an input of length 0x8C will take control of $ra

**Crash Information**

    Program received signal SIGSEGV, Segmentation fault.
    0x41414141 in ?? ()
    [ Legend: Modified register | Code | Heap | Stack | String ]
    ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── registers ────$zero: 0x0
    $at  : 0x7f8d2488  →  0x00000000
    $v0  : 0x0
    $v1  : 0x1
    $a0  : 0x1
    $a1  : 0x1
    $a2  : 0x1
    $a3  : 0x0
    $t0  : 0x004c28b8  →  0x004c34b0  →  0x00000000
    $t1  : 0x30
    $t2  : 0x21
    $t3  : 0x0
    $t4  : 0x7f8d1c20  →  0x777af3f0  →  0x00000000
    $t5  : 0x8
    $t6  : 0x0
    $t7  : 0x0
    $s0  : 0x7f8d26a8  →  0x82071107
    $s1  : 0x7f8d26a8  →  0x82071107
    $s2  : 0x77b96a60  →  "uc_api_lib.c"
    $s3  : 0x0
    $s4  : 0x77b97be4  →  "_session_read_and_dispatch"
    $s5  : 0x77b7d090  →   lui gp, 0x3
    $s6  : 0x9b
    $s7  : 0x10
    $t8  : 0x0
    $t9  : 0x77c91008  →  <__pthread_mutex_unlock_usercnt+0> lui gp, 0x2
    $k0  : 0x0
    $k1  : 0x0
    $s8  : 0x41414141 ("AAAA"?)
    $pc  : 0x41414141 ("AAAA"?)
    $sp  : 0x7f8d2580  →  "AAAAAA; >> /proc/mesh/authorized"
    $hi  : 0xfff
    $lo  : 0x97248a23
    $fir : 0x0
    $ra  : 0x41414141 ("AAAA"?)
    $gp  : 0x004ae4b0  →  0x00000000
    ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── stack ────0x7f8d2580│+0x0000: "AAAAAA; >> /proc/mesh/authorized"   ← $sp
    0x7f8d2584│+0x0004: "AA; >> /proc/mesh/authorized"
    0x7f8d2588│+0x0008: ">> /proc/mesh/authorized"
    0x7f8d258c│+0x000c: "proc/mesh/authorized"
    0x7f8d2590│+0x0010: "/mesh/authorized"
    0x7f8d2594│+0x0014: "h/authorized"
    0x7f8d2598│+0x0018: "thorized"
    0x7f8d259c│+0x001c: "ized"
    ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── code:mips:MIPS32 ────[!] Cannot disassemble from $PC
    [!] Cannot access memory at address 0x41414140
    ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── threads ────[#0] Id 1, stopped 0x41414141 in ?? (), reason: SIGSEGV
    ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── trace ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── 
    

**TIMELINE**

2022-02-08 - Initial Vendor Contact  
2022-02-09 - Vendor Disclosure  
2022-08-01 - Public Release

Discovered by Carl Hurd of Cisco Talos.

Tag

#wifi