Critical RCE Vulnerability in TP-Link Wi-Fi Extenders Can Grant Attackers Remote Control

June 18, 2019
| |
5 min read

Wi-Fi extenders, also known as repeaters, are devices that can amplify a Wi-Fi signal inside a home. They are most often used in large or multistory homes or simply in places where the router’s reach is not optimal in all parts of the home. Extenders are sold at almost every electronics store. The extender captures the Wi-Fi signal from the main router and rebroadcasts it to areas where the Wi-Fi is weak or nonexistent.

As part of a recent series of vulnerabilities discovered in home routers, IBM X-Force researcher Grzegorz Wypych discovered a zero-day flaw in a TP-Link Wi-Fi extender. If exploited, this remote code execution (RCE) vulnerability can allow arbitrary command execution via a malformed user agent field in HTTP headers. This means that a remote attacker could get complete control over the device and command it with the same privileges of the device’s legitimate user.

The specific model we found and exploited this vulnerability in is the TP-Link RE365 Wi-Fi extender with firmware version 1.0.2, build 20180213 Rel. 56309. While this model is the only one we checked for this RCE flaw, after internal tests, TP-Link confirmed that three other models are also affected: RE650, RE350 and RE500. This vulnerability is attached to CVE-2019-7406 and links to TP-Link patches are available at the end of this article.

Unauthenticated Power

The vulnerability at hand is somewhat surprising because it can be exploited by a remote attacker without requiring login/authentication to the Wi-Fi extender. Moreover, while common in most attack kill chains, privilege escalation would not be needed here since all processes on these devices already run with root-level access. Running as root by default is quite risky because anyone who may compromise the device could perform any action on it.

So how does this happen? Like many routers, the extender in this case also operates on the MIPS architecture, but let’s start by examining an HTTP GET request sent to the Wi-Fi extender. There is some importance to the network setup for an attacker to attempt to connect to the extender. If someone is already connected to the network, they can easily access the device, but the real impact can come from an external party accessing the device from the internet via port forwarding.

The image below shows a malformed HTTP request that can allow any shell command to be executed on the targeted RE365 Wi-Fi extender. We can also see request parameters from the fully compromised device. The image was obtained by using Burp Suite, a graphical tool for testing web application security.

Figure 1: Exploitable malformed HTTP request sent to Wi-Fi extender

Next, let’s examine how the remote code execution vulnerability unfolds. For better visualization, we used IDA, a popular multiprocessor disassembler and debugger.

RCE Vulnerability Executed by a System Call

Looking at the binary in IDA, we could check for a specific user agent field, which checks what type of browser the user is accessing the extender from (mobile or another browser). We can see here an automated comment referencing the string Mobile Agent: {30bfbf8d9f2833f0337133e196b4dc87825dfb7d33a3602d05ee876ecd6f1178}s. It is printed on the device’s console’s screen and should not be used by the execve system call. This system call can execute anything on the console. This should have been limited and opens the extender to malicious actions.

Figure 2: PRINTF_ECHO function execution flow revealing user agent on the device’s console

The next image shows that a message using a shell command echo is sent to the console using the function execFormatCmd. The latter uses the execvesystem call internally, which is at the root of this RCE vulnerability.

Figure 3: Layered encapsulation of the execve system call with defined functions. This was likely supposed to give some obscurity to execve.

The call to execFormatCmd executes the system call execve, which we can use to merge the user agent field with a remote code execution command using a reverse shell over telnetd. Telnetd is an open-source telnet server daemon (DARPA TELNET protocol server) for remote login.

Figure 4: Body of the execFormatCmd function that executes the sub_40B740 command

Of note, the function vsprintf in this block can be exploited via buffer overflow, but it won’t be able to overwrite the return address in the MIPS architecture used in this sort of device. In such a case, an external attacker could trigger a denial-of-service attack, which is less critical than the RCE vulnerability at hand.

Figure 5 shows the body of the executed sub_40B740 function, which is there to create a child process that will print messages on the device’s console. The child process is created in the fork function viewed midway through the block. To do that, it uses execve, which, again, is an issue because this command can execute any shell command (aBinSh being the exact parameter) without limiting the actions that can be taken by a user — in this case, a potential attacker.

Figure 5: Execve sys call invocation with user-controlled input

The following image shows an open telnet session from a fully compromised device. After connecting to TCP port 4444 we were able to obtain root level shell on the Wi-Fi extender without any privilege escalation, with all processes running as root.

Figure 6: Unlimited access to the compromised device

Wi-Fi Extenders Pose Extended Risk

Wi-Fi extenders are devices that can be purchased in many electronics stores for a few dollars. While these devices are most often used in homes and small businesses, they can also be found inside the networks of larger organizations, where guest Wi-Fi is enabled and stretched between different floors to serve those wishing to connect.

This vulnerability can therefore affect a variety of end users, from home users to corporate users, and enable an attacker to send any request to the extender. The sort of impact that can result from such unauthenticated access includes, for example, requesting the device to browse to a botnet command-and-control (C&C) server or an infection zone. The thought of a Mirai infection on internet of things (IoT) devices is, of course, one of the first things that comes to mind, where automated scripts could potentially run as root on this type of device if the vulnerability is exploited.

Patching and Mitigating Risk

It’s important to mitigate the risk posted by this remote code-execution flaw (CVE-2019-7406) by implementing compensating controls or a patch as soon as one becomes available.

The TP-Link security team confirmed that there are four products affected by this issue:

  • From the current product lineup, aside from RE365, model RE650 was also confirmed vulnerable.
  • Two EOL models, RE350 and RE500, have also been confirmed to have this issue.
  • No other models have been confirmed as affected.

TP-Link has provided the following resources to help users update their firmware:

Users can also keep up to date on vulnerabilities with IBM X-Force Red’s vulnerability management services.

Learn more about IBM X-Force Red offensive security services

Grzegorz Wypych
Software Developer – IBM

Grzegorz Wypych loves to work with MIPS/ARM assembly code and hunt for 0-days in IoT devices. He may have started his career in software engineering, but his...
read more