ABB Cylon Aspect 3.07.02 (userManagement.php) - Weak Password Policy

ABB Cylon Aspect 3.07.02 (userManagement.php) — Weak Password Policy (CVE-2024-48845)

This article describes a weak password policy vulnerability discovered in ABB Cylon / Aspect building management products. The flaw allows creation of users with overly simple or empty credentials via userManagement.php, reducing account security and enabling unauthorized access. The weakness is tracked as CVE-2024-48845 and was publicly reported by Gjoko "LiquidWorm" Krstic (ZeroScience).

Key details

Affected product	NEXUS Series, MATRIX-2 Series, ASPECT-Enterprise, ASPECT-Studio (Firmware ≤ 3.07.02)
Vendor	ABB Ltd. (global.abb)
Discovery	Gjoko 'LiquidWorm' Krstic / ZeroScience — Advisory ZSL-2024-5898
CVE	CVE-2024-48845
Advisory	ZSL-2024-5898

Summary of the vulnerability

The web management endpoint userManagement.php accepts POST parameters for USER and PASSWORD without adequate server-side validation. This allows operators or remote attackers who can reach the management interface to create accounts with trivial passwords (e.g., a single digit) or blank values. Weak credential acceptance greatly increases the likelihood of account compromise by brute-force or opportunistic attackers.

Why this matters (impact)

• Unauthorized access to building management functions (HVAC, sensors, schedules).
• Potential for operational disruption, data exfiltration, or safety risk if control systems are modified.
• Default/weak credentials are trivial to brute-force if network access exists.
• Persistence: illicit accounts can be created and used later, bypassing ordinary password changes.

Proof-of-Concept (PoC) example

The researcher demonstrated the issue with a simple HTML form that posts to userManagement.php. The following PoC shows how a client can create a user "admin2" with password "7":

<form action="http://192.168.73.31/userManagement.php" method="POST">
  <input type="hidden" name="USER" value="admin2" />
  <input type="hidden" name="PASSWORD" value="7" />
  <input type="hidden" name="ACTION" value="Add" />
  <input type="submit" value="Create" />
</form>

Explanation: This form submits three POST fields (USER, PASSWORD, ACTION) to the device's userManagement.php. Because the server-side code does not enforce password complexity or non-empty values, it accepts the weak password "7" and creates the account.

Detection: how to check if a device is vulnerable

• Locate the web management interface and identify userManagement.php or similar endpoints.
• Attempt a controlled POST that tries to create a user with a very weak password while monitoring server response and logs.
• Check firmware version: if firmware ≤ 3.07.02 on affected products, treat as potentially vulnerable until patched.

Example curl test (controlled, internal network only)

curl -k -X POST "https:///userManagement.php" \
  -d "USER=testweak" \
  -d "PASSWORD=1" \
  -d "ACTION=Add"

Explanation: This curl POST attempts to add a user 'testweak' with password '1'. Only run this against systems you own or have permission to test. If the request returns a success or the user is present afterward, the endpoint lacks sufficient checks.

Immediate mitigations (what to do now)

• Restrict access to management interfaces: place devices behind firewalls, VPNs, and dedicated management VLANs.
• Disable web administration on untrusted networks and restrict to trusted IP ranges.
• Change default credentials for all accounts to strong, unique passwords or disable unused accounts.
• Enable multi-factor authentication (if supported) or centralized authentication (RADIUS/LDAP) instead of local accounts.
• Monitor logs for account creations, unexpected administrative actions, and unknown users.

Permanent remediation and secure fixes

The vendor should release firmware that enforces server-side password policies and account creation rules. If you are a site operator, apply vendor patches as soon as they become available. If a vendor patch is not yet available, apply compensating technical controls (network restrictions, monitoring).

Recommended server-side validation for user creation (example PHP)

Below is a secure PHP pattern for validating and storing passwords safely. It enforces complexity, rejects empty usernames, and uses bcrypt hashing.

<?php
// Example secure user creation (illustrative)
function is_strong_password($pwd) {
    // Minimum 12 chars, at least one uppercase, one lowercase, one digit, one special
    return preg_match('/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*\W).{12,}$/', $pwd);
}

$username = trim($_POST['USER'] ?? '');
$password = $_POST['PASSWORD'] ?? '';

// Basic checks
if ($username === '') {
    http_response_code(400);
    echo 'Username required';
    exit;
}
if (!is_strong_password($password)) {
    http_response_code(400);
    echo 'Password does not meet complexity requirements';
    exit;
}

// Hash using bcrypt (password_hash)
$hash = password_hash($password, PASSWORD_BCRYPT);

// Use prepared statements to insert user (PDO example)
$pdo = new PDO('sqlite:/var/db/aspect_users.db');
$stmt = $pdo->prepare('INSERT INTO users (username, password_hash, created_at) VALUES (?, ?, ?)');
$stmt->execute([$username, $hash, time()]);

echo 'User created';
?>

Explanation: This code enforces a minimum 12-character password with mixed character types, rejects empty usernames, and hashes passwords with bcrypt using PHP's password_hash. Prepared statements prevent SQL injection when storing account data.

Additional secure controls (recommended)

• Account lockout and throttling: lock or throttle after N failed attempts to stop brute-force attacks.
• Secure session handling: rotate session tokens and set secure cookie flags (HttpOnly, Secure, SameSite).
• CSRF protection: require CSRF tokens on forms that modify accounts.
• Audit and alerting: log account creations and administrative actions; forward logs to a central SIEM.
• Password reuse prevention and forced rotation policies aligned with risk assessments.

Example: simple failed-login tracking (concept)

// Pseudocode: increment a counter for failed logins and lock after threshold
$failed = (int)redis_get("fail:{$username}:count");
if ($is_login_successful) {
  redis_del("fail:{$username}:count");
} else {
  $failed = redis_incr("fail:{$username}:count");
  if ($failed >= 5) {
    redis_setex("lock:{$username}", 900, 1); // lock 15 minutes
    deny_login();
  }
}

Explanation: This example demonstrates rate limiting and temporary lockout using Redis as a simple backend. Locking slows attackers and prevents repeated credential guessing.

Network and operational hardening checklist

• Update device firmware when vendor releases fixes that address CVE-2024-48845.
• Isolate building management systems from general IT networks and the internet.
• Use VPN or management jump hosts for remote administration.
• Implement MFA for privileged users where supported.
• Maintain a secure backup and recovery plan and an incident response playbook for control-system breaches.

Disclosure and credits

This vulnerability was responsibly disclosed by Gjoko "LiquidWorm" Krstic and published by ZeroScience (Advisory ZSL-2024-5898). Operators should consult ABB for official patches and guidance. See the advisory link in the table above and CVE-2024-48845 for canonical tracking.

Final recommendations (Executive summary)

Devices running ABB Aspect firmware ≤ 3.07.02 may accept weak or empty credentials via userManagement.php. Treat affected systems as vulnerable: restrict access, change credentials, monitor for suspicious administration, and apply vendor patches when available. In development and operations, enforce robust server-side validation, secure password hashing, account throttling, and strong network segmentation to reduce the risk surface for building management systems.