ABB Cylon FLXeon 9.3.4 - Cross-Site Request Forgery

ABB Cylon FLXeon 9.3.4 — Limited Cross‑Site Request Forgery (CSRF)

Summary: A CSRF (Cross‑Site Request Forgery) weakness was identified in ABB’s Cylon FLXeon / BACnet field controllers with firmware versions up to and including 9.3.4. The issue is constrained by the device's CORS configuration (Access‑Control‑Allow‑Origin: * without Access‑Control‑Allow‑Credentials: true), which prevents many common remote exploitation techniques. Nevertheless, specific conditions — such as same‑domain hosting of a malicious page, local network access, man‑in‑the‑middle (MitM), misconfigured CORS, or presence of a reflected XSS — can allow an attacker to cause state‑changing requests on behalf of an authenticated user.

Why this matters

ABB’s FLXeon controllers are used to control HVAC and other building systems. Successful CSRF that changes controller configuration or commands could disrupt HVAC, lighting, metering, or other controls, resulting in operational impact for commercial buildings.

Affected products and firmware

Product family	Series / Models	Firmware
FLXeon Series	FBXi, FBTi, FBVi	≤ 9.3.4
CBX / FLX Series	CBX	≤ 9.3.4
CBT Series	CBT	≤ 9.3.4
CBV Series	CBV	≤ 9.3.4

Technical overview — CSRF and CORS interaction

• CSRF: a web threat where a victim’s browser is tricked into making authenticated requests (e.g., POST/GET) to a target site using the browser’s stored credentials (cookies, HTTP auth, client certs).
• CORS (Cross‑Origin Resource Sharing): a browser mechanism that controls whether cross‑origin JavaScript (fetch/XHR) can read responses from another origin. Headers such as Access‑Control‑Allow‑Origin (ACAO) and Access‑Control‑Allow‑Credentials (ACAC) determine allowed origins and whether credentialed cross‑origin requests are permitted.
• Interplay here: the device sets ACAO: * and does not set ACAC: true. This configuration means modern cross‑origin XHR/fetch requests with credentials cannot be used to read responses from the device (and credentialed responses with wildcard are disallowed by browsers). However, classic CSRF via form submission or image requests may still cause the server to perform actions if the endpoint accepts those request types and uses browser‑sent cookies/credentials.
• Net result: exploitation is limited — an attacker cannot trivially use cross‑origin JavaScript to both send credentialed requests and read the responses — but several realistic attack paths remain if other conditions are met (same domain/subdomain, LAN/MitM, misconfigurations, reflected XSS).

Exploit scenarios — when CSRF becomes practical

• Same‑domain hosting: If an attacker can host a malicious page under the same origin (domain + scheme + port) as the device (for example via DNS takeover, virtual hosting on the same domain, or hosting on an allowed subdomain when cookies are valid for that domain), the browser treats the page as same‑origin and will send credentials with AJAX requests and allow response access.
• Local network (LAN) access: A malicious actor on the same network (or an attacker who can run a rogue wifi hotspot) can host a page or intercept traffic and trigger CSRF against the controller reachable on the LAN.
• Man‑in‑the‑Middle (MitM): If an attacker can intercept and modify traffic (e.g., unsecured HTTP, flawed TLS), they can inject a malicious page or modify responses to loosen protections.
• Subdomain abuse / misconfigured cookie domain: If cookies set by the controller use a wide domain scope (e.g., .example.com) and the attacker controls a subdomain (attacker.example.com), CSRF is possible from the subdomain.
• Reflected XSS: If a reflected XSS exists on the same origin, an attacker can execute JavaScript in the controller’s origin and fully control authenticated requests.
• Endpoints accepting simple form content: Many CSRF attacks use HTML forms because browsers automatically include cookies on form submits. If the controller exposes state‑changing endpoints that accept standard form content types (application/x‑www‑form‑urlencoded or multipart/form-data) or GET requests without additional protections, those endpoints can be targeted by classic CSRF techniques.

Detection — how to quickly check a target’s behaviour (benign testing)

Use non‑destructive checks to verify headers and CORS policy. The following curl command fetches response headers; do not use it to modify or disrupt production devices.

curl -I http://DEVICE_IP_OR_HOSTNAME/

Explanation: this sends an HTTP HEAD request and prints response headers. Look for Access‑Control‑Allow‑Origin and Access‑Control‑Allow‑Credentials in the output. Example output might include:

Access-Control-Allow-Origin: *

If ACAO is '*', and ACAC is not present or false, the device is disallowing credentialed cross‑origin XHR responses but not necessarily preventing form‑based CSRF.

Proof‑of‑concept considerations (responsible disclosure)

Public advisories typically avoid publishing destructive exploit code. For defensive testing you can simulate CSRF conditions in a controlled lab using:

• A browser with a test account and the controller on an isolated network.
• Non‑destructive form submissions that hit a safe, read‑only endpoint (if available) to confirm that the browser sends cookies to the device.
• Checking logs on the device for unexpected requests or referer/origin mismatches.

Mitigations and recommended fixes

Owners and administrators of ABB Cylon controllers should prioritize firmware patches from the vendor. In addition, apply the following defenses where possible:

• Apply vendor updates: install ABB firmware updates and security patches as they become available.
• Implement CSRF tokens: require anti‑CSRF tokens (synchronizer token or double‑submit cookie) for any state‑changing operations.
• Harden CORS: avoid wildcard ACAO. If cross‑origin requests with credentials are required, set Access‑Control‑Allow‑Credentials: true and explicitly echo a single allowed Origin value only after strict server‑side validation of the Origin header.
• Restrict cookie scope: set a narrow cookie domain and use the SameSite cookie attribute (SameSite=strict or SameSite=lax) to reduce automatic credential sending to cross‑site contexts.
• Require strong auth for sensitive actions: re‑authenticate or require 2FA for critical configuration changes, and avoid relying solely on session cookies for high‑impact commands.
• Validate Origin/Referer: on state‑changing endpoints, verify the Origin and/or Referer header matches an expected value; reject requests without expected headers.
• Limit HTTP surface: restrict management interfaces to trusted networks (e.g., management VLAN) and avoid exposing devices to the public Internet when not required.
• Network controls: use network segmentation, firewall rules, and access control lists to prevent untrusted clients from reaching controllers on the LAN.

Example: safer CORS pattern (Node.js / Express)

// Example: only allow a single validated origin and credentials when allowed
const allowedOrigins = new Set([
  'https://ops.example.com'  // trusted management UI origin
]);

app.use((req, res, next) => {
  const origin = req.get('Origin');
  if (origin && allowedOrigins.has(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Access-Control-Allow-Credentials', 'true');
    res.setHeader('Access-Control-Allow-Methods', 'GET,POST,PUT,DELETE,OPTIONS');
    res.setHeader('Access-Control-Allow-Headers', 'Content-Type,Authorization');
  }
  next();
});

Explanation: This code snippet demonstrates a defensive CORS configuration: it checks the incoming Origin header against a trusted list and, if allowed, echoes that exact origin and enables credentials. This avoids using a wildcard ACAO and prevents credentials from being accepted for arbitrary origins.

Detection and monitoring recommendations

• Monitor device logs for requests with unexpected Referer or Origin headers or for repeated POSTs from non‑UI clients.
• Alert on configuration changes that occur without explicit operator action or that originate from unusual IP addresses on the management network.
• Run regular vulnerability and configuration scans of controllers to detect exposed management interfaces and insecure headers (ACAO: * etc.).
• Use web application scanners and manual review (OWASP ZAP, Burp Suite) in a lab to confirm CSRF protections are effective.

Incident response guidance

• Isolate affected controllers from external networks if you suspect active exploitation.
• Collect logs and network captures for forensic review, noting timestamps and the clients that issued the requests.
• Reset credentials and review user accounts and access controls if unauthorized state changes are observed.
• Coordinate with ABB support and follow vendor guidance for remediation and firmware updates.

References and credits

• Vulnerability originally discovered by Gjoko “LiquidWorm” Krstic (@zeroscience).
• Advisory: ZSL‑2025‑5918 — https://www.zeroscience.mk/en/vulnerabilities/ZSL-2025-5918.php
• General CSRF guidance: OWASP CSRF Prevention Cheat Sheet.

Takeaway: Although the FLXeon devices’ CORS headers limit some forms of remote exploitation, administrators should treat this as a real risk. Apply vendor patches, tighten CORS and cookie settings, require CSRF tokens for state changes, and restrict network exposure to eliminate viable attack paths.