CVE-2024-46874: Ruijie Reyee OS Auth Bypass Vulnerability

CVE-2024-46874 Overview

CVE-2024-46874 is a critical improper access control vulnerability affecting Ruijie Reyee OS, the operating system powering Ruijie's cloud-managed network devices. The vulnerability exists in the MQTT (Message Queuing Telemetry Transport) implementation, where clients connecting with device credentials can send messages to unauthorized topics. This flaw enables attackers who possess device credentials to issue commands to other devices on behalf of Ruijie's cloud infrastructure, potentially compromising entire network deployments.

Critical Impact

Attackers with device credentials can impersonate cloud commands and control other devices in the Ruijie Reyee ecosystem, leading to widespread network compromise and unauthorized device manipulation.

Affected Products

• Ruijie Reyee OS versions 2.206.x up to (but not including) 2.320.x
• Cloud-managed network devices running vulnerable Reyee OS firmware
• Enterprise and SMB network infrastructure utilizing Ruijie Reyee cloud management

Discovery Timeline

• 2024-12-06 - CVE-2024-46874 published to NVD
• 2024-12-10 - Last updated in NVD database

Technical Details for CVE-2024-46874

Vulnerability Analysis

This vulnerability stems from improper permission handling (CWE-280) within the MQTT broker implementation of Ruijie Reyee OS. MQTT is a lightweight publish-subscribe messaging protocol commonly used in IoT and network device communication. In properly secured implementations, topic-level access controls ensure that authenticated clients can only publish or subscribe to topics they are explicitly authorized to access.

In vulnerable versions of Reyee OS, the access control mechanism fails to adequately restrict which MQTT topics a device-authenticated client can publish messages to. This architectural weakness allows an attacker who has obtained valid device credentials to send messages to topics normally reserved for cloud-to-device communication, effectively impersonating the Ruijie cloud management platform.

Root Cause

The root cause is classified as CWE-280 (Improper Handling of Insufficient Permissions or Privileges). The MQTT broker in Reyee OS does not properly validate whether an authenticated device has permission to publish to specific topics before accepting and forwarding messages. This insufficient permission validation creates a privilege escalation pathway where device-level credentials can be leveraged to perform cloud-level operations.

Attack Vector

The attack requires network access to the MQTT broker and valid device credentials. An attacker can exploit this vulnerability through the following attack flow:

1. Credential Acquisition: The attacker obtains valid device credentials through physical access, network interception, or credential harvesting
2. MQTT Connection: Using the device credentials, the attacker establishes an authenticated MQTT connection to the Ruijie cloud infrastructure
3. Topic Abuse: The attacker publishes malicious commands to restricted MQTT topics that control other devices
4. Device Manipulation: Target devices receive and execute commands believing they originate from the legitimate cloud management platform

This attack does not require user interaction and can be executed remotely over the network. The complexity is elevated due to the requirement for valid device credentials, but once obtained, exploitation is straightforward.

Detection Methods for CVE-2024-46874

Indicators of Compromise

• Unusual MQTT message patterns originating from device credentials targeting administrative topics
• Device configuration changes occurring outside normal management windows or without corresponding administrator actions
• MQTT topic subscription or publication attempts from unexpected source IP addresses
• Log entries indicating commands received from device identities that should not have administrative privileges

Detection Strategies

• Implement MQTT topic monitoring to detect publication attempts to restricted cloud-to-device command topics from device clients
• Deploy network traffic analysis to identify anomalous MQTT message patterns or unexpected topic usage
• Enable comprehensive logging on the Ruijie cloud management platform to track all device-to-cloud communications
• Monitor for firmware downgrades or configuration changes across managed devices that were not initiated by administrators

Monitoring Recommendations

• Establish baseline MQTT communication patterns for your Reyee device fleet and alert on deviations
• Implement network segmentation monitoring to detect lateral movement attempts following device compromise
• Deploy intrusion detection signatures for known MQTT protocol abuse patterns
• Review Ruijie cloud management logs regularly for unauthorized command issuance or suspicious device behavior

How to Mitigate CVE-2024-46874

Immediate Actions Required

• Upgrade all Ruijie Reyee OS devices to version 2.320.x or later immediately
• Audit device credentials and rotate any that may have been exposed or compromised
• Review device configurations for unauthorized changes that may indicate prior exploitation
• Implement network segmentation to limit the blast radius of any compromised devices

Patch Information

Ruijie has addressed this vulnerability in Reyee OS version 2.320.x and later. Organizations should consult the CISA ICS Advisory ICSA-24-338-01 for detailed remediation guidance and update their devices through the standard Ruijie cloud management firmware update process. All devices running versions 2.206.x through 2.319.x should be prioritized for immediate patching.

Workarounds

• If immediate patching is not possible, implement strict network access controls to limit which systems can communicate with the MQTT broker
• Deploy additional authentication layers or VPN requirements for device management traffic
• Monitor MQTT communications closely using network security tools until patches can be applied
• Consider temporarily isolating vulnerable devices from production networks if the risk is deemed unacceptable

# Network segmentation example - restrict MQTT access to management VLAN only
# Adjust interface and IP ranges according to your network topology
iptables -A INPUT -p tcp --dport 1883 -s 10.10.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 1883 -j DROP
iptables -A INPUT -p tcp --dport 8883 -s 10.10.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 8883 -j DROP