The TCL LinkHub Mesh Wi-Fi system is a multi-device Wi-Fi system that allows users to expand access to their network over a large physical area. What makes the LInkHub system unique is the lack of a network interface to manage the devices individually or in the mesh. Instead, a phone application is the only method to interact with these devices. This is noteworthy because, in theory, it significantly reduces the common attack surface on most small office/home office (SOHO) routers, as it moves the entire HTTP/S code base from the product. This means, in theory, fewer issues with integration or hacked-together scripts to trigger various functions within the device. One of the issues with this approach though is that its functionality still needs to reside somewhere for the user to manage the device.

However, this setup leaves the LinkHub Mesh Wi-Fi system open to several vulnerabilities, which we are disclosing today. An attacker could exploit these vulnerabilities to carry out a variety of malicious actions, including injecting code at the operating system level, stealing credentials and causing a denial of service of the entire network. Cisco Talos is disclosing these vulnerabilities despite no official fix from TCL, all in adherence to Cisco’s vulnerability disclosure policy.
Moving all the management functionality to the phone application makes it the most interesting path to research for this device. The first step is to understand the protocol used for communication. There are a few easy choices, TCL could have decided to use HTTP with hidden endpoints, or some hand-rolled protocol for communication, to make capturing and identifying the traffic the priority. Looking at the capture right away, it’s not HTTP or another text-based protocol, so the next step is determining if this is a custom protocol or something more widely used.

Network traffic capture of Android application communication. 

While investigating various binaries on the device and the Android application, it became clear that the method for serializing data is the widely used Proto Buffers library. Proto Buffers serializes data using a platform-agnostic definition file. Once the definition file has been created, the protoc compiler can create the boilerplate code needed for various programming languages to communicate using the defined serialization. An interesting side effect of utilizing Proto Buffers is that the definition code needs to be embedded in the boilerplate code for each side to be able to deserialize data into a usable format for each language supported by the compiler. By determining how this data is included in the deserializing code, one can recover an almost perfect representation of the definition file from compiled binaries.

Proto Buffer structure recovered from binary. 
Proto file recovered from the binary. 

Once the proto files have been recovered, the file can be compiled to any supported language. This makes interacting with the service incredibly simple once the proto file has been extracted. The usage of Proto Buffers has another advantage for vulnerability research: The Proto Buffer serialization and deserialization are very well tested. That is not to say that it is perfect and bug-free, but for the purposes of this research, it made sense to ignore any code generated from protoc. This research was completely focused on the business logic and handling of data once it had been deserialized, all code which TCL is responsible for.

The next roadblock for general security research to begin was authentication. The user does not need to provide a password in the TCL app to authenticate the device, so it was either pre-negotiated upon pairing or some other information is used. After reviewing some network captures with recovered protocol information, it was clear that these devices use the serial number as the password for authentication, what is worse is that a serial number can be requested (and is requested in normal authentication flow) without any permissions and as such, this is not an authentication method at all. After recreating this pseudo-login method, the research could proceed to look for vulnerabilities.

During this research, 17 different vulnerability reports were generated. These reports group together similar CVEs into reports that are sent to vendors, and in this case are a grouping of 41 unique CVEs. Many of the discovered vulnerabilities are related to the Proto Buffer management protocol, as well as the general usage of recovering configurations from memory For more information on each of these vulnerabilities, check out their full reports, linked below.

The following Snort rules will detect exploitation attempts against this vulnerability: 59013, 59020, 59026 – 59029, 59058, 59059, 59061, 59289 – 59291 and 59406 - 59411. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Firepower Management Center or Snort.org.

Buffer overflow vulnerabilities

  • Talos-2022-1454: TCL LinkHub Mesh Wifi confsrv set_port_fwd_rule stack-based buffer overflow vulnerability
  • Talos-2022-1455: TCL LinkHub Mesh Wifi confsrv set_mf_rule stack-based buffer overflow vulnerability
  • Talos-2022-1456: TCL LinkHub Mesh Wifi confers ucloud_add_node_new stack-based buffer overflow vulnerability
  • Talos-2022-1462: TCL LinkHub Mesh Wi-Fi confsrv confctl_set_app_language stack-based buffer overflow vulnerability
  • Talos-2022-1463: TCL LinkHub Mesh Wifi GetValue buffer overflow vulnerability
  • Talos-2022-1482: TCL LinkHub Mesh Wi-Fi confsrv addTimeGroup stack-based buffer overflow vulnerability
  • Talos-2022-1483: TCL LinkHub Mesh Wi-Fi confsrv ucloud_set_node_location stack-based buffer overflow vulnerability
  • Talos-2022-1484: TCL LinkHub Mesh Wi-Fi confsrv ucloud_set_node_location buffer overflow vulnerability

Command injection vulnerabilities

  • Talos-2022-1457: TCL LinkHub Mesh Wifi confsrv ucloud_add_node_new OS command injection vulnerability
  • Talos-2022-1458: TCL LinkHub Mesh Wifi confsrv ucloud_add_node OS command injection vulnerability

Information disclosure vulnerabilities

  • Talos-2022-1503: TCL LinkHub Mesh Wifi confctl_get_guest_wlan information disclosure vulnerability
  • Talos-2022-1504: TCL LinkHub Mesh Wifi confctl_get_master_wlan information disclosure vulnerability

Denial-of-service vulnerabilities

  • Talos-2022-1502: TCL LinkHub Mesh Wifi confctl_set_guest_wlan denial of service vulnerability
  • Talos-2022-1505: TCL LinkHub Mesh Wifi confctl_set_master_wlan denial of service vulnerability
  • Talos-2022-1506: TCL LinkHub Mesh Wi-Fi confctl_set_wan_cfg denial of service vulnerability
  • Talos-2022-1507: TCL LinkHub Mesh Wifi ucloud_del_node denial of service vulnerability

Hard-coded credential vulnerability

  • Talos-2022-1459: TCL LinkHub Mesh Wifi libcommonprod.so prod_change_root_passwd hard-coded password vulnerability