Critical Security Alert: Hardcoded SSH Keys and Database Credentials Expose RUCKUS Network Director to Full System Takeover (CVE-2025-67305 & CVE-2025-67304)

RUCKUS Network Director (RND) – Hardcoded SSH Keys & Hardcoded Database Credentials

Executive Summary

Product: RUCKUS Network Director (RND)
Vulnerability Type: Hardcoded SSH private keys and hardcoded PostgreSQL credentials embedded in the OVA appliance
Affected Component: RND OVA deployment (on-prem virtual appliance)
Impact: Authentication bypass → Privileged access → Full appliance compromise
Attack Vector: Network
User Interaction: Not required
Privileges Required: None (network reachability required)
Exploit Availability: No widespread public exploit kit observed at this time; exploitation is technically straightforward if vulnerable version is deployed
Severity (Operational Assessment): Critical – because authentication material is embedded and shared across deployments
CVSS (Vendor/NVD may update): Not formally populated at time of writing

Two separate but related issues were identified in certain RND 4.5.x builds:

CVE-2025-67305 – A private SSH key was embedded in the appliance image and reused across installations.
CVE-2025-67304 – PostgreSQL database credentials for a privileged database user were hardcoded and not uniquely generated per deployment.

When combined, these weaknesses allow unauthorized access to the management appliance without guessing passwords or exploiting memory corruption. If the appliance is reachable over the network, full control can be obtained.

Affected Versions

RND 4.5.x builds prior to vendor-fixed releases (notably builds earlier than patched 4.5.0.6x series).
Verification should be performed against the official patched version recommended by RUCKUS.

Technical Description

CVE-2025-67305 – Hardcoded SSH Private Key

A static SSH private key was found to be embedded in the RND OVA image. This key is not regenerated during installation. Because the same key material is reused across deployments:

Any attacker who retrieves the key from the appliance image
Or extracts it from another deployed system
Or gains knowledge of it from prior exposure

can authenticate via SSH using public key authentication without knowing a password.

If SSH service is exposed and reachable, authentication succeeds as a privileged service account (commonly tied to database or system-level access). Once shell access is obtained, local privilege escalation is often unnecessary because the account already has database-level access.

This is categorized as use of a hardcoded cryptographic key (CWE-321).

CVE-2025-67304 – Hardcoded PostgreSQL Credentials

The RND OVA was found to contain static database credentials for the internal PostgreSQL instance. These credentials were not dynamically generated per installation.

If TCP port 5432 is reachable:

An attacker can connect directly to PostgreSQL
Authenticate using the static credentials
Gain superuser-level database access

From database superuser access, it becomes possible to:

Extract administrative user hashes
Create new application admin users
Modify configuration tables
Execute OS-level commands indirectly through database features
Establish persistence by modifying startup scripts or configuration

This is classified under use of hardcoded credentials (CWE-798).

Attack Scenarios

Scenario 1 – Direct SSH Access

Attacker identifies exposed RND appliance (SSH open).
Hardcoded private key is used for authentication.
SSH login succeeds without password prompt.
Database files and system configs are accessed.
Persistence is established via new keys or user accounts.

Scenario 2 – Direct Database Access

Attacker scans internal network and finds port 5432 open.
Hardcoded database credentials are used.
PostgreSQL superuser access is granted.
New administrative user is inserted into RND tables.
Web interface login is performed using injected admin.

Scenario 3 – Lateral Movement Pivot

Because RND centrally manages wireless and network infrastructure:

Device credentials stored in database can be extracted.
SSH keys for managed infrastructure may be exposed.
Controllers and AP clusters may be reconfigured.

This turns a single appliance compromise into environment-wide control.

Exploitability Assessment

No fully weaponized public exploit framework has been widely circulated at this time. However, exploitation does not require complex exploit development. If the key or credential is known, authentication works by design.

This is not a memory corruption vulnerability. It is a trust boundary failure. Exploitation complexity is low once network access is available.

Proof of Concept (Educational)

The following demonstrates how exploitation would conceptually occur in a lab environment.

SSH-Based Access

If the private key is obtained:

ssh -i extracted_key postgres@<RND_IP>

If vulnerable, authentication will succeed without password.

PostgreSQL Access

If credentials are known:

psql -h <RND_IP> -U ruckus -d <database_name>

Once connected:

SELECT usename, usesuper FROM pg_user;
CREATE ROLE backdoor WITH LOGIN SUPERUSER PASSWORD 'StrongPassword!';

Indicators of Compromise

SSH log entries showing successful publickey authentication for service accounts.
PostgreSQL logs showing connections from unusual IP addresses.
Unexpected creation of database roles.
Newly created administrative users in RND web interface.
Unrecognized SSH keys present in authorized_keys files.
Firewall logs showing unexpected inbound connections to ports 22 or 5432.

Log Sources for Detection

Linux authentication logs (/var/log/auth.log, /var/log/secure)
PostgreSQL logs
RND application logs
Hypervisor audit logs
Network firewall logs
IDS/IPS telemetry
EDR telemetry from the appliance (if deployed)

Detection Queries

Splunk – Suspicious SSH Public Key Authentication

index=linux_logs sourcetype=secure OR sourcetype=auth
"Accepted publickey"
| stats count by user, src_ip, host
| where user IN ("postgres","ruckus","root")

Splunk – PostgreSQL External Access

index=postgres_logs
"connection authorized"
| stats count by user, src_ip
| where user IN ("ruckus","postgres")

Elastic (KQL) – Suspicious SSH Login

event.dataset:linux.auth AND event.action:"ssh_login" AND
(user.name:"postgres" OR user.name:"ruckus") AND
NOT source.ip:(10.0.0.0/8 OR 172.16.0.0/12 OR 192.168.0.0/16)

Elastic – Database Role Creation

event.dataset:postgresql.log AND
message:"CREATE ROLE"

Network Monitoring – Unexpected PostgreSQL Access

Trigger alert when:

Destination port = 5432
Destination IP = RND appliance
Source not in management subnet

Mitre ATT&CK Mapping

T1078 – Valid Accounts
T1021 – Remote Services (SSH)
T1505 – Server Software Component
T1136 – Create Account
T1552 – Unsecured Credentials
T1484 – Domain/Policy Modification (if lateral expansion occurs)

Risk Assessment

These vulnerabilities remove authentication trust assumptions. Security controls based solely on password secrecy are ineffective if credentials are embedded in the product image.

If RND is internet-accessible or reachable from untrusted internal networks, compromise probability increases significantly.

If exposed only within tightly segmented management VLANs, risk remains high but exposure likelihood is reduced.

Remediation

Upgrade immediately to vendor-patched release.
Regenerate all SSH keys.
Rotate all database credentials.
Audit for unknown users.
Restrict network access to management interfaces.
Review historical logs for signs of compromise.
Rebuild appliance from clean patched image if compromise is suspected.

Official Patch / Upgrade

The official RUCKUS security bulletin and patched software releases are available here:

Ruckus Security Bulletin & Downloads:
https://support.ruckuswireless.com/security_bulletins/333

RND Product Downloads:
https://support.ruckuswireless.com/products/156-ruckus-network-director-rnd

Only software obtained directly from the official RUCKUS support portal should be used for remediation.

Post-Remediation Validation

After upgrade:

Confirm SSH keys are unique.
Confirm database password is not default.
Verify no unauthorized DB roles exist.
Validate firewall restrictions.
Re-run internal vulnerability scan.

Conclusion

The vulnerabilities stem from embedded authentication artifacts within the appliance image. Because authentication material was reused across deployments, compromise does not require brute force or exploit chains. If network access is available, access can be achieved using known credentials or keys.

Organizations operating RND appliances should treat this as a priority upgrade and perform log review to confirm no unauthorized access occurred before remediation.