Troy Wilson

CVE-2025-25504

Intro

During a recent exploration penetration test, I stumbled across my first Gefen web portal and decided to explore it. During the test, I identified a critical vulnerability in Gefen AV over IP devices that allows unauthenticated remote code execution as the root user. This blog post details the discovery of that vulnerability, how to exploit it, and the potential impact.

This was tested on the following versions, which are the only ones available to me at the time of this test:

The Discovery

While connecting to web portals on one of the networks, I ran into multiple Gefen AV over IP devices. These hosts were comprised of both senders and receivers. I hadn’t run across these in the past, so I decided to spend some time looking over their capabilities. On this particular test, I found that the default credentials had been left in place, allowing administrative access to the portal. Worse yet, I could execute commands as root using a debugging text field. I thought this would be the end of my findings, but while reviewing the netstat output, I noted that port 4444/TCP was open.

Port 4444/TCP caught my eye since it happens to be the default callback port by Metasploit. I was curious if these devices had been compromised previously or if another penetration tester had setup a shell and forgot to remove it at the end of the test. The Gefen devices are very basic, so many of the usual tools I would use for this weren’t available and I didn’t want to modify the devices by adding any additional applications. Instead, I used what I could find, which was perfectly fine for my purposes.

I found that the port was open and provided /bin/sh via netcat. This looks almost exactly like you would find on a bind shell cheat sheet. Once again, I wondered if this may be left over from a previous pen tester or an actual compromise that the customer may or may not have known about. This warranted further investigation since I knew the source needed to be determined.

After a bit of poking around, I found that the vulnerability stems from the /usr/local/bin/jncs.sh script. This script starts a persistent netcat listener on TCP port 4444, bound to a system shell, exactly like the process I saw currently bound to the port. This setup allows anyone with network access to the device to connect to this port and execute commands with root privileges—completely unauthenticated.

Here’s the part of the script that resulted in this blog post:

#!/bin/sh
while true; do
    nc -lp 4444 -e /bin/sh
done

This script is run by one of two scripts that appear to run on startup: * /usr/local/bin/link_mgrc.sh * /usr/local/bin/link_mgrh.sh

Both of those scripts are referenced in configuration files in the /usr/local/bin directory, which is what appears to allow those scripts to be run at startup.

I could not find reference to this in any of the Gefen documentation I found and I believe it’s not meant to be tampered with, but from what I found, it appears to be part of how the sender and receiver communicate over the network. Specifically I found references to files that are changed by sending commands to other devices on port 4444/TCP. Overall, this is a very dangerous way to achieve this task and definitely goes against all security best practices.

Steps to Exploit

Exploiting this vulnerability is straightforward for any threat actor with remote access to port 4444/TCP.

1. Connect to the vulnerable device on port 4444 using netcat:

nc [DEVICE_IP] 4444

That’s really it. That’s the only necessary step. However, from here, a threat actor may want to upgrade their shell using something like:

/bin/sh -i

Impact

The implications of this vulnerability are significant. An attacker could:

• Obtain password hashes for users
• Make configuration changes
• Achieve persistence on the device
• Use the device to proxy malicious traffic
• Conducting denial-of-service attacks by modifying the device configuration

Given the ease of exploitability and the fact that these devices do not have any security software on them, it would be extremely enticing to a threat actor.

Responsible Disclosure

After discovering this vulnerability, I reached out to Gefen to report the issue and provide them with the details necessary to address it. As of this writing, the vendor has not responded or acknowledged this vulnerability. Following responsible disclosure guidelines, I have submitted this issue for a CVE assignment and am disclosing this information publicly to raise awareness.

The timeline is as follows:

Recommendations

If you are using Gefen AV over IP devices, there is no current fix for this that I am aware of. Gefen has not responded to any of my attempts to reach them. Until a fix is released, I recommend the following steps to mitigate the risk:

1. Restrict Network Access: Ensure that access to these devices is limited to trusted networks and users. Use firewall rules to block access to port 4444/TCP from all other networks.
2. Monitor for Unauthorized Activity: Regularly check logs and network activity for unusual connections to or from these devices.

Conclusion

CVE-2025-25504 highlights the importance of securing network-connected devices, particularly those used in critical environments. While these devices provide valuable functionality, they must be designed with security in mind to prevent unauthorized access and misuse. The mistakes made here were very basic and could easily be caught by any secure coding review whether automated or manual.

As always, I advocate for responsible disclosure and collaboration between researchers and vendors to ensure vulnerabilities are addressed effectively. I’ll update this post with any developments, including vendor responses or patches.

If you have questions or would like to discuss this issue further, feel free to reach out to me at troy[@]troy-wilson[.]com.

Contact

troy[@]troy-wilson[.]com