The Article

A maximum-severity security flaw has been disclosed in the TP-Link Archer C5400X gaming router that could lead to remote code execution on susceptible devices by sending specially crafted requests. The vulnerability, tracked as CVE-2024-5035, carries a CVSS score of 10.0. It impacts all versions of the router firmware including and prior to 1_1.1.6. It has been patched in version 1_1.1.7 released on May 24, 2024.

“By successfully exploiting this flaw, remote unauthenticated attackers can gain arbitrary command execution on the device with elevated privileges,” German cybersecurity firm ONEKEY said in a report published Monday. The issue is rooted in a binary related to radio frequency testing “rftest” that’s launched on startup and exposes a network listener on TCP ports 8888, 8889, and 8890, thus allowing a remote unauthenticated attacker to achieve code execution. While the network service is designed to only accept commands that start with “wl” or “nvram get,” ONEKEY found that the restriction could be trivially bypassed by injecting a command after shell meta-characters like ; , & , or, | (e.g., “wl;id;”). Cybersecurity

TP-Link’s implemented fix in version 1_1.1.7 Build 20240510 addresses the vulnerability by discarding any command containing these special characters. “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,” ONEKEY said.

The disclosure arrives weeks after security flaws were also revealed by the company in Delta Electronics DVW W02W2 industrial Ethernet routers (CVE-2024-3871) and Ligowave networking gear (CVE-2024-4999) that could allow remote attackers to gain remote command execution with elevated privileges. It’s worth noting that these flaws remain unpatched due to the devices being no longer actively maintained, making it imperative that users take adequate steps to limit exposure of administration interfaces to reduce the potential for exploitation.

  • Fungah@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    5 months ago

    Dude I wish. I’d love to be able to point you in the right direction but getting this all working for me was just the product.of determination and posts / videos from all over the place.

    I can tell you that adding proxmox to the equation made things way more complicated. And that vlans are not intuitive.

    My advice would be to just kind of go for it. I ended up needing a smart switch, a mul5i nic pace card, a regular switch, and two access points (you could get a vlan aware access point but I couldn’t find anything that made sense price wise).

    The whole thing took days to set up. I frequently didn’t know why things weren’t working. It sucked.

    You can pm me if you get stuck and I can try to give you a hand buy the frustrating truth I learned about the process was that I was kind of on my own since every set up is kind of unique based on your hardware.

    I’m glad its done but doing it frankly sucked…

    • laurelraven@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      1
      ·
      5 months ago

      Thanks for the reply!

      I’ll probably just start messing around with things and see where they go, worst case I’ll spend some time and learn some things

      • Fungah@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        4 months ago

        Pm me if you feel like ripping your hair out and putting a whole in the wall with your face. Which I often did. I can try and help. Though there are probably better options