This blog post gives details about a zero-day vulnerability in TP-Link Archer C5 v4 routers that run firmware version 3.16.0 0.9.1 v600c.0 Build 180124 Rel.28919n. The issue has been reported as CVE-2017-7405 and issued patches by TP-Link. Please see links to patches at the end of this post and patch with priority.

Internet routers, an omnipresent device connecting us to work, services and leisure, have become an integral part of every home, business and public place. Yet although they are so essential to our connection to the world, they are one of the least secure devices we use on a daily basis.

In this post, IBM X-Force Red‘s Grzegorz Wypych (aka @horac341) describes a firmware vulnerability we found in TP-Link Archer C5 (v4) routers. This is a zero-day flaw that was not previously reported and can affect both home and business environments. If exploited, this router vulnerability can allow a remote attacker to take control of the router’s configuration via Telnet on the local area network (LAN) and connect to a File Transfer Protocol (FTP) server through the LAN or wide area network (WAN).

This flaw is considered critical since it can grant an unauthorized third-party access to the router with admin privileges, which are the default on this device for all users, without proper authentication taking place. The risk is greater on business networks where routers such as this can be used to enable guest Wi-Fi. If placed on the enterprise network, a compromised router can become a point of entry to an attacker, and a place to pivot from in recon and lateral movement tactics.

The release of this post follows a responsible disclosure process with TP-Link and is designed to help users and defenders take action to mitigate the risk to these devices. Patches released by TP-Link to address this issue in their firmware appear in the closing section of this blog.

A Password Overflow Issue

Before we delve into how we discovered this issue, the short way of describing this flaw is vulnerable HTTP requests that void the user’s password. In an overflow issue of sorts, when a string that’s shorter than the expected string length is sent through as the user’s password, the password value gets distorted into some non-ASCII bytes.

When the string is too long, however, the password gets completely voided, replaced by an empty value. This TP-Link device only features one user type — admin with root privileges — and all processes are run by the user under this access level, which can allow an attacker to operate as admin and take over the device.

Triggering the Router Vulnerability

When we looked into what triggered the vulnerable situation, we could see that one would only have to send the right request through to be granted access to the device. See figure 1 for a visual of an HTTP request we used to exemplify this trigger.

What we have here are two types of requests: safe, so to speak, and vulnerable. In the case of non-vulnerable requests for HTML content, there are two parameters that must be validated: the TokenID and the JSESSIONID. However, Common Gateway Interface (CGI) validation here is only based on the referrer’s HTTP headers. If it matches the IP address or the domain associated with tplinkwifi.net, then the router’s main service, HTTPD, will recognize it as valid.

Figure 1: Vulnerable HTTP POST request does not verify required parameters

If that referrer is removed from the header, the request will return a “Forbidden” response.

Figure 2: Referrer removed from request — HTTP response returns “403 Forbidden”

This issue affects both HTTP POST and GET requests in the same way, voiding the admin password when string length is over the allowed number of bytes.

Figure 3: HTTP GET request equally voids passwords

Looking at the Firmware

At this point, after seeing these requests void the password, we wanted to take a look at the device’s firmware. Since firmware is not always available on vendor websites, we had to extract the firmware from the device’s Flash storage chip.

With the memory chip’s version number in hand, it was easier to find more information about it online and we were able to extract the firmware directly from the chip using a chip clip and BinWalk, a binary file analysis tool.

Figure 4: Router firmware extracted with BinWalk

Notice that during extraction there was an RSA private key stored on memory. This key is used in encrypting and decrypting user passwords when accessing the web service.

After extracting the firmware, we found login data stored in the rootfs/etc folder. The default username and password were extremely weak. Leaving the default combination as is can allow access to an FTP server and grant console access. That’s a lot of access for such a weak password that can be guessed by just about anyone and, unfortunately, is also at the source of automated attacks that spread botnet malware like Mirai.

Figure 5: Root access to router

With root-level access, we could now gain some control over binaries. We also had TFTP, so we downloaded a MIPS gdbServer, a control program for Unix-like systems that allows the operator to remotely debug other programs from another system. In that way, the debugger did not need to reside on the same device, only the executable we wanted to debug needed to reside on our target system.

We combined using this tool with the use of IDA, a multi-processor disassembler and debugger, to get both static and dynamic analysis going so we could locate the source of the router vulnerability, going through this process to explain how we found the vulnerability without actually triggering it.

The following image shows the relevant part of the parsed HTTP header viewed on IDA:

Figure 6: Parsed HTTP header shows referrer setup

Note that the function strncmp is being used here to validate the Referrer header with the string tplinkwifi.net. The preceding branch also validates for an IP address. Attaching the debugger to have a look at these details confirmed that this is indeed an exploitable router vulnerability.

A Vulnerable Request

Our next step was to check what happens with the password file when we sent a vulnerable request through using different string lengths. At first, we tried to send a shorter string, with only a few bytes.

Figure 7: Sending HTTP GET request with shorter password string

This short string went through and corrupted the password file. The result is that the user would not be able to log in, and nor would the attacker. This issue affects Telnet, FTP and the web service.

Figure 8: Password file corrupted by shorter string of bytes submitted by the user

Next, we tried sending through a password longer than the allowed number of characters.

Figure 9: Sending a long password through

This time, the password was voided altogether, and the value was now empty. From this point on, we were able to access TELNET and FTP without any password, using only “admin” as the username, which is the only available user on the device by default.

Figure 10: Admin password was voided

Additional Issues

After attaining admin access without needing real authentication, we found out that this specific device also allows for the configuration of FTP on the WAN. Furthermore, we could remotely manage the router over a secure HTTPS connection, which is also vulnerable to this CGI attack. The impact and implications of this router vulnerability, if exploited by a malicious third party, can be detrimental.

Not only can attackers attain privileged access, but the legitimate user can also be locked out and would no longer be able to log in to the web service through the user interface since that page would no longer accept any passwords (unbeknownst to the user). In such an event, the victim could lose access to the console and even a shell, and thereby would not be able to re-establish a new password. Even if there was a way to set a new password, the next vulnerable LAN/WAN/CGI request would, once again, void the password. The only access would, therefore, be FTP files via a USB port connection.

Another aspect of the potential impact is that the RSA encryption key would fail since it is not designed to work with an empty password value.

The bottom line is that the victim’s device, FTP (if configured to be used on WAN) and Telnet (LAN only) can become completely exposed to an attacker.

Vulnerable Routers Abound — How to Protect Your Data

This recent critical vulnerability on TP-Link routers is part of a much larger problem in the world of internet of things (IoT) security. Nowadays, almost every home uses a router, but five out of six routers are inadequately updated for security flaws, according to a study from the American Consumer Institute. When these flaws surface, they expose millions of home and business users to the risk of data compromise. And it’s not only textual information that can be lost — think about footage from webcams, baby monitors and other connected devices in the home that use that same router to connect to the internet.

To mitigate these risks, users must treat router security with more attention, and the first thing to do is change default passwords. If a device does not allow for the modification of usernames and passwords, it is a sure way to see more trouble down the line. Businesses using default devices where passwords cannot be changed should apply mitigating controls and enable two-factor authentication (2FA) to such device access where possible.

TP-Link Patches

The following patches have been issued by TP-Link to address this issue on version TP-Link Archer C5 v4 and other versions that may be exposed. We recommend patching devices ASAP.

Firmware for Archer C5 V4:

https://static.tp-link.com/2019/201909/20190917/Archer_C5v4190815.rar

Archer MR200v4:

https://static.tp-link.com/2019/201909/20190903/Archer%20MR200(EU)_V4_20190730.zip

Archer MR6400v4:

https://static.tp-link.com/2019/201908/20190826/Archer%20MR6400(EU)_V4_20190730.zip

Archer MR400v3:

https://static.tp-link.com/2019/201908/20190826/Archer%20MR400(EU)_V3_20190730.zip