ABB Cylon FLXeon 9.3.4 - WebSocket Command Spawning

ABB Cylon FLXeon 9.3.4 — WebSocket Command Spawning (CVE-2024-48849)

Overview: In 2024 a vulnerability (CVE-2024-48849) affecting ABB’s Cylon FLXeon family of BACnet smart building controllers was publicly disclosed. The issue centers on an unauthenticated WebSocket-based control interface that can be abused to spawn system commands (observed in the wild to start multiple tcpdump processes). Successful exploitation enables resource exhaustion, denial-of-service (DoS) conditions, and potential network traffic capture/data exposure.

Why this matters

• Devices affected are building-automation controllers (HVAC, lighting, remote I/O) often deployed in critical environments with persistent network connectivity.
• The vulnerability is accessible over the controller’s management interface and can be triggered without authentication, increasing risk when management ports are reachable from untrusted networks.
• Attack outcomes include DoS via process flooding, extended packet-capture (tcpdump) for reconnaissance or data exfiltration, and potential lateral movement if sensitive BACnet or building-management traffic is intercepted.

Summary of technical details (high-level)

• Vector: WebSocket interface exposed on the management port (HTTPS/WSS).
• Root cause: Insufficient access control and weak input handling for a JSON-RPC-like WebSocket endpoint that can trigger privileged subsystems/processes.
• Observed malicious action: spawning tcpdump processes (packet capture) and doing so repeatedly in a loop to exhaust device resources.
• Affected firmware: FLXeon Series (and related FLX/CBX/CBT/CBV product families) with firmware versions up to and including 9.3.4.
• CVE: CVE-2024-48849; disclosure and advisory details are available from the researcher and public vulnerability trackers.

Vendor	ABB Ltd.
Product	ABB Cylon / FLXeon series BACnet controllers
Affected versions	Firmware ≤ 9.3.4 (per advisory)
CVE	CVE-2024-48849
Discovery	Reported publicly by security researcher Gjoko Krstic / ZeroScience

Impact and attack scenarios

The primary risks are:

• Denial of Service: An unauthenticated attacker may spawn multiple processes repeatedly, consuming CPU, memory and storage and degrading device operation.
• Information exposure: Spawning tcpdump or other packet-capture processes enables interception of building automation traffic (BACnet/IP, credentials, telemetry), which can facilitate further attacks or data theft.
• Persistence and amplification: Continuous spawning can be scripted to survive reboots (if file system access exists) or to create multiple simultaneous captures across devices on the same network.

Detection: indicators and monitoring

Focus monitoring and detection on artifacts that indicate unusual process creation, packet capture activity, or WebSocket connections to management interfaces.

Host-based indicators

• Multiple instances of tcpdump (or other packet-capture binaries) running on the controller.
• System logs showing network interfaces entering/leaving promiscuous mode (kernel messages like “device lo entered promiscuous mode”).
• High CPU/load averages on controllers without a corresponding change in building automation activity.
• Unexpected file creation or large log/journal files (tcpdump pcap files can grow quickly).

Network-based indicators

• Unexpected or long-lived WebSocket (wss://) sessions to device management ports from external or untrusted IPs.
• Large outbound flows of pcap-like traffic or flows to external collectors that do not match normal telemetry patterns.

Example defensive queries and signatures

Below are safe, defensive examples you can use to detect suspicious activity. These do not exploit the vulnerability; they only identify potentially malicious outcomes (e.g., packet capture processes).

/* Splunk example: search for tcpdump activity in syslog/journalctl */index=linux_logs (process="tcpdump" OR message="tcpdump") | stats count by host, process, _time

Explanation: This Splunk query looks for entries mentioning tcpdump in log data to highlight systems that have invoked packet capture processes.

/* ELK/Elasticsearch example: find kernel messages about promiscuous mode */GET /logs-*/_search
{
  "query": {
    "match_phrase": {
      "message": "entered promiscuous mode"
    }
  }
}

Explanation: Devices that enter promiscuous mode may be used for network sniffing. This query finds log messages indicating such mode changes.

/* Suricata/IDS signature (defensive): alert when websocket payload contains "tcpdump" */alert http any any -> any any (msg:"WebSocket payload contains tcpdump - possible remote packet capture"; content:"tcpdump"; http_client_body; nocase; sid:1000001; rev:1;)

Explanation: A network IDS rule to flag HTTP/WebSocket payloads that include “tcpdump”. Use this as a starting point and tune to reduce false positives. Do not use this rule to interact with or probe devices.

Mitigation and remediation

Immediate steps you should take if you operate ABB Cylon / FLXeon devices (or manage networks that include them):

• Patch: Apply the vendor patch or firmware update that addresses CVE-2024-48849 as soon as it is available from ABB. Confirm firmware versions and vendor guidance.
• Network segmentation: Restrict access to management interfaces (HTTPS/WSS) to a dedicated management VLAN and limit access with ACLs or firewall rules. Do not expose management ports to the public Internet.
• Access controls: Enforce strong authentication and authorization on all management interfaces. If an interface cannot be secured, disable it until a fix is applied.
• Disable unnecessary services: If WebSocket-based management is not required, disable that service on the device or block it at the network edge.
• Resource hardening: Apply OS-level mitigations where possible — set ulimits to limit the number of processes per user, use process supervisors with strict policies, and remove or restrict use of diagnostic binaries (like tcpdump) if not required for operations.
• Monitor and respond: Instrument devices and the network to detect indicators above. If tcpdump processes or promiscuous mode are observed, assume compromise and isolate the device for forensic analysis.

Longer-term mitigations

• Engage with the vendor for secure configuration guidance and long-term firmware support.
• Use network access control (NAC) and strong micro-segmentation for building automation networks.
• Implement centralized logging and monitoring for all building controllers to shorten detection time.

Forensics and incident response guidance

• Collect volatile evidence: process lists, open sockets, and running tcpdump processes. Capture memory if feasible and allowed by policy.
• Preserve logs: export system journals and device logs immediately (journalctl, /var/log, application logs) and checksum the artifacts.
• Network captures: if possible, take a controlled packet capture (from a monitored tap or span port) to observe command-and-control or data exfiltration flows.
• Check device filesystem for large pcap files, unusual scripts or cron entries that may indicate persistence.
• Coordinate with the vendor for deeper artifact collection; vendor support can provide device-specific guidance and cleanup tools.

Responsible disclosure and references

• Original public advisory and details: ZeroScience vulnerability advisory (ZSL-2025-5913).
• CVE entry: CVE-2024-48849 (public registry).
• Vendor resources: consult ABB product and security advisories on the vendor’s official site, and subscribe to vendor security mailing lists for firmware updates.

References (recommended reading)

• Vendor security advisories — check ABB’s security and product pages for FLXeon updates.
• CVE database — CVE-2024-48849 for canonical metadata.
• ZeroScience advisory and researcher write-up for technical background and disclosure timeline.

Practical recommended checklist

• Inventory: identify all ABB Cylon/FLXeon and related devices on your network.
• Patching: update firmware per vendor guidance; confirm post-update integrity.
• Access control: restrict management protocols and apply strong authentication.
• Monitoring: add rule-based detection for unusual process creation, promiscuous-mode logs, and WebSocket anomalies.
• Hardening: apply system-level resource limits and remove or restrict capture utilities if not needed.
• Incident readiness: ensure your IR team has a plan for isolating and investigating controller compromises.

Final notes

This vulnerability underscores the risk of exposing management interfaces with insufficient authentication and the unique threat profile of building automation systems. Prioritize patching and network-level protections, and treat any signs of packet-capture or repeated process spawning as a high-severity incident until proven otherwise.