ABB Cylon Aspect 3.08.03 (CookieDB) - SQL Injection

ABB Cylon ASPECT 3.08.03 (CookieDB) — SQL Injection Vulnerability Analysis

Executive summary

A SQL injection vulnerability (Advisory ZSL-2025-5900) affects ABB Cylon ASPECT products running firmware versions up to and including 3.08.03. The problem is located in the CookieDB component where untrusted values for cookie "key" and "user" are concatenated directly into SQL statements. An attacker who can supply these parameters may be able to manipulate SQL queries, read or modify records in the Cookies table, and — depending on the database and privilege set — escalate to broader data exposure or command execution on the database host.

Products and affected versions

Vendor	Product	Affected firmware / versions
ABB Ltd.	NEXUS Series, MATRIX-2, ASPECT-Enterprise, ASPECT-Studio	Firmware <= 3.08.03 (CookieDB)

Credits and references

• Discovered by Gjoko "LiquidWorm" Krstic (@zeroscience)
• Advisory: ZSL-2025-5900 — https://www.zeroscience.mk/en/vulnerabilities/ZSL-2025-5900.php

Vulnerability details

The vulnerable code constructs SQL statements by concatenating unescaped values for cookie keys and users directly into SQL strings. Two representative operations are:

// Vulnerable pseudocode (concatenation)
removeUserCookie() -> DELETE FROM Cookies WHERE Key=" + key + " AND User=\"" + user + "\"";
getAllUserCookies() -> SELECT * FROM Cookies WHERE User=\"" + user + "\"";

Because these values are not sanitized or parameterized, specially crafted input may alter query semantics. The root cause is dynamic SQL built with string concatenation instead of parameterized statements (prepared statements) or strict whitelist validation.

Potential impact

• Unauthorized disclosure of cookie records (SELECT queries).
• Modification or deletion of cookie records (UPDATE/DELETE).
• Depending on database features and privileges, more extensive data access or database manipulation.
• Indirect impact on business processes that rely on cookie/state information in building management systems.

Safe reproduction and testing guidance

Only test systems you own or are authorized to assess. Non-destructive testing techniques and code review are recommended to confirm vulnerability presence without causing operational impact. Prefer read-only checks and static analysis over live destructive tests. Engage vendor or site operators for coordinated testing and remediation.

Secure coding remediation (recommended fixes)

The robust fix is to stop building SQL by string concatenation and use parameterized queries / prepared statements with bound parameters. Additionally, perform input validation (whitelist where suitable), enforce least-privileged DB accounts, and log suspicious activity.

Example: Secure Java fix using PreparedStatement

/* Java example - use parameterized queries to avoid SQL injection */public boolean removeUserCookie(Connection conn, String key, String user) throws SQLException {
    String sql = "DELETE FROM Cookies WHERE Key = ? AND User = ?";
    try (PreparedStatement ps = conn.prepareStatement(sql)) {
        ps.setString(1, key);
        ps.setString(2, user);
        int rows = ps.executeUpdate();
        return rows > 0;
    }
}

public List getAllUserCookies(Connection conn, String user) throws SQLException {
    String sql = "SELECT Key, Value, Expires FROM Cookies WHERE User = ?";
    try (PreparedStatement ps = conn.prepareStatement(sql)) {
        ps.setString(1, user);
        try (ResultSet rs = ps.executeQuery()) {
            List cookies = new ArrayList();
            while (rs.next()) {
                cookies.add(new Cookie(rs.getString("Key"), rs.getString("Value"), rs.getTimestamp("Expires")));
            }
            return cookies;
        }
    }
}

Explanation: The code replaces concatenated SQL with PreparedStatement and uses '?' placeholders for parameters. The values are bound via ps.setString(...) so the driver treats them as data (not SQL), preventing injection. This approach is portable across JDBC-compatible databases and should be applied wherever untrusted input reaches SQL statements.

Input validation and hardening

In addition to parameterized queries, apply these practices:

• Whitelist accepted cookie key and user formats (e.g., regex limiting to alphanumerics and known separators).
• Limit length of inputs — enforce maximum reasonable sizes.
• Reject or normalize unexpected characters early in the request pipeline.
• Use prepared statements for all database access, not just this module.

Example: Input validation (Java snippet)

/* Simple whitelist validation before database use */private boolean isValidCookieKey(String key) {
    // Example: allow only ASCII letters, digits, hyphen and underscore, 1-64 chars
    return key != null && key.matches("^[A-Za-z0-9_-]{1,64}$");
}

Explanation: This snippet demonstrates a conservative whitelist: only allowed characters and bounded length. Apply similar validation rules for user identifiers according to system expectations. Validation reduces risks from malformed or unexpected input.

Operational mitigations (short- and medium-term)

• Upgrade firmware to a vendor-patched version as soon as one is available.
• Apply a web application firewall (WAF) to monitor and block suspicious SQL patterns as an interim mitigation.
• Restrict access to management interfaces and databases to trusted networks (network segmentation, VPN, IP allowlisting).
• Use least-privilege database accounts: the DB account used by CookieDB should only be able to operate on the Cookies table and only with the minimum necessary privileges (avoid full admin rights).
• Enable and review detailed application and database logging to detect anomalous queries or failed attempts.

Detection and scanning guidance

To identify instances of this vulnerability across an environment:

• Conduct code review in the CookieDB module and any other components that build SQL from user input.
• Use static analysis tools to flag string concatenation into SQL APIs and lack of prepared statements.
• Use non-destructive application security testing (AST) tools or authenticated dynamic scanners against test systems you own. Avoid exploiting production systems or performing destructive tests.

Risk prioritization and impact assessment

Factor	Assessment
Exploit complexity	Low — injection occurs through input concatenation
Privileges required	Typically attacker needs access to the affected interface (network reachable). Risk increases if interface is exposed.
Potential impact	High — data disclosure and modification, dependent on DB privileges and network exposure

Vendor response and recommended timeline

Contact ABB support to obtain an official patch or firmware update. Coordinate disclosure and remediation if you operate affected devices. If a vendor patch is not immediately available, implement the operational mitigations above (network restrictions, WAF, least privilege) and plan prioritized patching when a vendor fix is released.

Logging and monitoring recommendations

• Log unusual query patterns and repeated failed operations against the CookieDB interface.
• Alert on SQL errors that reveal query structure (avoid exposing such errors to unauthenticated users in production).
• Correlate auth failures and anomalous query behavior with network logs to detect possible scanning or exploitation attempts.

Final recommendations

• Apply vendor patches as soon as available.
• Replace string-concatenated SQL with parameterized queries in all database-accessing code.
• Harden runtime environment: restrict access, use least-privileged DB accounts, enable logging and monitoring.
• Perform periodic code reviews and security testing focused on injection classes of vulnerabilities.