Security Advisory: Arbitrary Command Execution on TP-Link Archer C5400X

[ad_1]

Introduction

Before the release of our binary zero-day identification feature, we tested and validated it on our firmware corpus to make sure we were providing meaningful analysis results. In the process, we identified numerous vulnerabilities that we reported to vendors. Over the course of 2024, we hope to make most of these vulnerabilities public, such as the ones identified in Cisco WAP321. We continue in this blog post with another access point device: the TP-Link Archer C5400X Tri-Band Gaming Router.

After the automated analysis completed and we quickly reviewed the results manually to confirm findings, we had one command injection, a format string in a shell and a few buffer overflows affecting rftest and libshared.

The format string can only be exploited under specific circumstances, so in this blog post, we’ll focus on the rftest binary. rftest, as the name implies, is related to radio frequency testing and is there to help the access point do wireless interfaces self-assessment. To do so, it exposes a network listener on TCP ports 8888, 8889, and 8890. This listener is vulnerable to command injection and buffer overflows.

Remote Command Execution

Summary

The affected device launches a binary called rftest during its initialization sequence. This binary expose a network service that is vulnerable to unauthenticated command injection.

Impact

By successfully exploiting this flaw, unauthenticated attacker located on LAN can gain arbitrary command execution on the device with elevated privileges.

According to TP-Link: “After a thorough internal source code analysis (including an in-depth review of the function call path), TP-Link have determined that CVE-2024-5035 is more of a source code weakness than an available LAN vulnerability with a specific killchain. As such, CVE-2024-5035 disclosure does not increase information security risks in daily use.

Description

The command injection was spotted by our binary static analysis pipeline. The user controlled source is a call to read() on the TCP socket listening on port 8888:

This source is propagated multiple times and ends up in two different popen() calls, one of them if the received bytes contains “wl”, the other if the received bytes starts with “nvram” and contains “get”, pictured below:

The rftest binary is launched on boot by following this sequence:

  1. The /etc/init.d/wireless init script is executed. This script executes the command /sbin/wifi init .
  2. The wifi script imports the file /lib/wifi/tplink_brcm.sh and executes the function wifi_init from that file.
  3. Within /lib/wifi/tplink_brcm.sh , the following function call tree happens wifi_init -> wifi_start -> wifi_start_calibrate -> wifi_start_rftest -> rftest
  4. The rftest function in /lib/wifi/tplink_brcm.sh starts /usr/sbin/rftest

When executed, the binary launches a TCP server on port 8888. The network service accepts commands from clients, limiting commands to commands that starts with wl or nvram get .

However, to turn it into a command injection, this limitation can simply be bypassed by injecting a command after shell meta-characters like ; , & , or | :
As we can see in the output below, we connect to the service on port 8888 and inject the command id:

TP-Link applied a fix by discarding any command containing shell meta-characters, as can be seen below:

Recommendation

We recommend you upgrade to version 1_1.1.7 by using the upgrade feature of the C5400X.

Key Takeaways

It seems the need to provide a wireless device configuration API at TP-Link had to be answered either fast or cheap, which ended up with them exposing a supposedly limited shell over the network that clients within the router could use as a way to configure wireless devices. With details of this “API” abstracted away, the fact that it does indeed expose a shell remotely due to insecure coding practices got lost in the review process.

Therefore, this advisory further demonstrate the importance of performing automated binary static analysis of the final compiled version of the firmware to unearth vulnerabilities that affect components your product development team may not even be aware exists. In this case, exposing remote unauthenticated root access over LAN on high end gaming routers.

Timeline

  • 2024-02-16 –Report submitted to TP-Link PSIRT through encrypted email.
  • 2024-02-19 –Case opened by TP-Link PSIRT.
  • 2024-04-10 –TP-Link shares a beta version of 1.1.7p1 for validation.
  • 2024-04-17 –Patch confirmed by ONEKEY.
  • 2024-05-27 –Release ONEKEY advisory in coordination with TP-Link

[ad_2]

Source link