CVE-2024-3596: Enable RADIUS Message Authenticator on Hitachi AFS AFR AFF

Hitachi Energy's AFS, AFR and AFF series of substation and network edge devices are vulnerable to a cryptographic attack against the RADIUS protocol that can let a local attacker forge authentication responses, potentially granting or denying network access, corrupting session state, and undermining device and service integrity across energy control networks. The vulnerability, tracked as CVE‑2024‑3596, exploits a chosen‑prefix collision attack against the MD5‑based RADIUS Response Authenticator defined in RFC 2865; Hitachi Energy recommends enabling the RADIUS Message‑Authenticator option immediately as a practical mitigation while operators verify vendor firmware and configuration guidance.

Background / Overview​

RADIUS (Remote Authentication Dial‑In User Service) is a ubiquitous AAA (Authentication, Authorization, Accounting) protocol deployed for VPN gateways, Wi‑Fi infrastructure, network access control, and other edge authentication services. The classic RADIUS response integrity check uses MD5 in a construction called the Response Authenticator: ResponseAuth = MD5(Code | ID | Length | RequestAuthenticator | Attributes | Secret). That construction was standardized in RFC 2865 and relies on the shared secret and request authenticator to validate responses; however, MD5 is cryptographically broken for collision resistance and — crucially for this vulnerability — is vulnerable to chosen‑prefix collision techniques that allow an adversary to craft two different messages that produce identical MD5 digests under controlled conditions. In July 2024 the chosen‑prefix MD5 attack against the RADIUS Response Authenticator was assigned CVE‑2024‑3596. Multiple vendor advisories and vulnerability databases describe the result: if a RADIUS deployment does not require or validate the RADIUS Message‑Authenticator attribute (RFC 3579/2869), an attacker positioned on the local network path (e.g., same Wi‑Fi segment or provisioning network) can intercept a legitimate RADIUS response and replace it with a crafted response (for example converting an Access‑Reject into an Access‑Accept) that still passes the Response Authenticator check due to a chosen‑prefix MD5 collision. That forgery can be performed within practical timeframes using contemporary collision tools and hardware. Hitachi Energy’s public coordination with CISA and their PSIRT advisory covering AFS, AFR and AFF series products identifies the affected models and publishes immediate recommendations — notably, to set the RADIUS configuration to default which enables the RADIUS server message authenticator option, and provides device‑specific CLI and MIB commands to enable this setting on affected platforms. The vendor guidance is explicitly focused on enabling Message‑Authenticator verification as the primary mitigation until more comprehensive firmware or protocol‑level fixes are applied.

---

Why this is serious: the cryptography and attack model​

MD5 chosen‑prefix collisions — a practical failure​

MD5 has not been collision‑resistant for many years; modern chosen‑prefix collision methods (which let an attacker pick two arbitrary prefixes and append colliding suffixes) enable an attacker to make two different full messages hash to the same MD5 value. For RADIUS the Response Authenticator is MD5 over a well‑structured concatenation of header fields, attributes, the RequestAuthenticator, and the secret. If an attacker can observe an original response and craft an alternate response with the same MD5 value, then the client that only checks the MD5 Response Authenticator cannot distinguish the forged message from the genuine one. Public vendor advisories and national CERT writeups confirm the attack is feasible in practice and that time‑to‑collision is within operational windows for many networks.

Exploitation prerequisites and scope​

• Local network access: the attacker needs to be on the same layer‑2 or otherwise local segment where they can sniff and inject RADIUS responses (for example an open Wi‑Fi, compromised switch port, or a proxy path). This is not a remote Internet‑wide exploit without additional access.
• Ability to observe or influence request/response attributes: practical collisions often require control or knowledge of certain attribute fields to shape the prefixes used in the collision generation step. Vendors’ guidance therefore emphasizes enforcement of Message‑Authenticator to defeat the feasibility of the attack.
• Time & compute: CERT‑style writeups estimated practical collision generation is achievable in minutes on modern hardware, though exact times vary by implementation and available compute. That means the attack can fit within typical RADIUS retransmit/timeout windows.

What the attacker can do​

• Convert an Access‑Reject into an Access‑Accept (granting unauthorized network or VPN access).
• Convert an Access‑Accept into an Access‑Reject (denial of access to legitimate users).
• Modify Access‑Challenge flows to subvert multi‑factor or second‑factor interactions.
• Tamper with attributes that govern session parameters (e.g., VLAN assignment, session time), thereby manipulating network placement or QoS.
  These actions compromise integrity and availability of authentication flows and can have cascading operational impacts in critical infrastructure environments.

---

Affected Hitachi products and versions (what operators need to check)​

Hitachi Energy lists the following products as known affected for CVE‑2024‑3596:

• AFS 660‑B/C/S
• AFS 665‑B/S
• AFS 670 v2.0
• AFS 650
• AFS 655
• AFS 670
• AFS 675
• AFS 677
• AFR 677
• AFF 660
• AFF 665

The vendor report marks these models as “known_affected” and provides explicit CLI and MIB commands to enable Message‑Authenticator verification on the RADIUS client/server configuration on these platforms. Operators should treat every listed model as vulnerable until they confirm the device is configured to require and validate the Message‑Authenticator attribute or has received a vendor firmware update that addresses the protocol weakness.
Note: independent vulnerability databases and operating system advisories (Ubuntu, Amazon Linux, NVD) list a wide range of products and RADIUS implementations (freeRADIUS, vendor‑specific stacks) as impacted at the protocol level; the practical exposure depends on whether the device or server enforces the Message‑Authenticator attribute or uses TLS/RADSEC for RADIUS transport. Check each endpoint’s RADIUS configuration and vendor patch status.

---

Hitachi’s recommended mitigations (what to do now)​

Hitachi Energy’s immediate, vendor‑level mitigation is to enable the RADIUS Message‑Authenticator option on the affected devices. Their advisory contains platform‑specific instructions and CLI commands:

• For AFS65x, AFS67x and AFR67x: CLI command — radius server msgauth. MIB: hmAgentRadiusServerMsgAuth.
• For AFS66x, AFS670 v2.0, AFF66x: CLI command — radius server auth modify msgauth. MIB: hm2AgentRadiusServerMsgAuth.

These commands toggle enforcement of the Message‑Authenticator attribute, which uses HMAC‑MD5 over the entire packet and the shared secret in a construction that prevents straightforward forgery via chosen‑prefix MD5 collisions. Other vendors and vendors’ notices (Fortinet, A10, and many gateway/VPN providers) have converged on the same mitigation: either require Message‑Authenticator for UDP/TCP RADIUS or migrate RADIUS transport to TLS (RadSec). Short‑term operational checklist (high priority)

• Identify all Hitachi AFS/AFR/AFF devices and confirm current RADIUS settings.
• Enable Message‑Authenticator enforcement on the device(s) per the CLI commands above, and confirm via show/verification commands.
• Where Message‑Authenticator enforcement causes interoperability issues, segregate affected devices and temporarily restrict RADIUS endpoints to trusted management networks until vendors release compatible patches for clients/servers.
• Where feasible, transition RADIUS traffic to RadSec (RADIUS over TLS) or otherwise ensure transport encryption and server authentication for RADIUS, which eliminates the UDP MD5 integrity primitive that is the attack surface.

Why Message‑Authenticator matters: this attribute adds an HMAC over the entire packet with the shared secret in a way that defeats the practical collision technique used against the legacy Response Authenticator. Enabling it is the fastest, least disruptive mitigation that preserves RADIUS functionality while closing the immediate forgery vector. Multiple vendors explicitly published command examples and patches implementing the same change, reinforcing it as the industry standard short‑term fix.

---

Confirmed and recommended vendor steps beyond Hitachi​

• Enable Message‑Authenticator checking on RADIUS clients (VPN gateways, access points, NAC devices). Vendors such as Fortinet and A10 documented configuration switches to force Message‑Authenticator validation and to reject unexpected Proxy‑State attributes as defense‑in‑depth.
• Update RADIUS server software (freeRADIUS, vendor implementations) to versions that either enforce Message‑Authenticator or offer RadSec/TLS transport. Operating system vendors have released freeRADIUS patches and Linux distro security advisories; check your distro advisories (Ubuntu, Amazon Linux, Oracle Linux) for package fixes.
• Where possible, move sensitive authentication flows to EAP‑TLS or other methods that provide end‑to‑end TLS protection, and disable legacy MSCHAPv2/PAP where not required.

---

Practical remediation steps — a prescriptive procedure​

• Inventory and prioritize (immediate, within 24–72 hours)
• Enumerate all devices that use RADIUS for authentication: Wi‑Fi APs, VPN concentrators, network access controllers, Hitachi edge devices. Record model, firmware, management IP, and RADIUS peers.
• Apply quick mitigation (within hours where operationally possible)
• On each Hitachi AFS/AFR/AFF device listed as affected, enable the Message‑Authenticator option via the CLI commands in the vendor advisory and verify the configuration.
• Verify client compatibility (same day)
• Confirm that RADIUS clients (VPNs, APs) are sending Message‑Authenticator. If not, either update client firmware or restrict the client until a secure configuration can be enforced. Many vendors shipped client updates to add Message‑Authenticator support.
• Patch management (1–4 weeks)
• Obtain and schedule vendor firmware updates where Hitachi or downstream vendors provide protocol hardening or other fixes. Test in staging before mass rollout in OT/ICS zones.
• Longer‑term architecture changes (30–90+ days)
• Migrate RADIUS transport to TLS (RadSec) where feasible, adopt EAP‑TLS, and move away from MD5‑reliant constructs. Harden VPN authentication methods and enforce MFA to reduce impact if an authentication response is manipulated.

---

Detection, monitoring and incident response​

Detection is non‑trivial because a forged RADIUS response can appear syntactically valid. However, defenders can take concrete detection measures:

• Monitor for unusual accept/reject ratios, duplicated transaction IDs, or unusual Proxy‑State attributes — forgery attempts may generate anomalies in accounting or replayed IDs.
• Enable RADIUS server logging at verbose levels to record attribute contents and anomalous attribute lengths that might indicate appended collision blocks.
• Perform network‑level IDS/IPS monitoring for suspicious injection activity on ports 1812/1813/1645/1646 and for abnormal bursts of RADIUS traffic.
• Segment and audit the local networks that host RADIUS clients (e.g., Wi‑Fi management VLAN), and treat any lateral access in these segments as high‑priority for containment. CISA guidance underscores minimizing Internet exposure and isolating control‑system networks behind firewalls.

If you suspect an incident:

• Immediately isolate the affected RADIUS client or server.
• Capture and preserve packet captures of the suspect authentication sessions for offline forensic analysis.
• Rotate shared secrets between RADIUS peers after confirming no attacker persistence.
• Apply vendor‑recommended updates and re‑enable hardened settings (Message‑Authenticator) verified on both ends.
• Notify appropriate incident response and regulatory teams per your environment policy. CISA recommends reporting suspected malicious activity for centralized tracking.

---

Strengths and limits of the mitigation strategy​

• Strength: Enabling Message‑Authenticator is immediate, widely supported, and effective at neutralizing the specific MD5 chosen‑prefix forgery attack in UDP/TCP RADIUS deployments. Vendors across the networking ecosystem converged on the same mitigation quickly, which is valuable in operational settings where firmware rollouts take time.
• Limit: Requiring Message‑Authenticator presumes both client and server support/emit the attribute. Legacy endpoints or proprietary stacks that never added the attribute may experience interoperability problems; this forces short‑term segmentation or vendor coordination. In the longer term the only robust fix is migration away from weak hash primitives and toward authenticated, encrypted transport (RadSec/TLS) or modern EAP methods.
• Risk: Environments with exposed engineering or vendor networks often host RADIUS clients that are reachable beyond tightly controlled management zones. Even with Message‑Authenticator enabled, misconfigurations or fallback to legacy servers could leave windows open; rigorous inventory and validation are therefore essential.

---

Cross‑verification of key technical claims​

• The RADIUS Response Authenticator construction and the MD5 usage are documented in RFC 2865; this is the canonical protocol source confirming why MD5 is in the verification path.
• NVD and multiple distribution advisories list CVE‑2024‑3596 with high severity and describe the chosen‑prefix MD5 collision attack against the Response Authenticator. Some vendors and OS distributions report CVSS values in the 8.7–9.0 range; CISA’s advisory cites a CVSS v3.1 base score of 9 in its metrics. These differences reflect vendor scoring nuance but converge on high criticality for affected use cases.
• National CERTs and industry vendors (CERT‑EU, Fortinet, A10, etc. corroborate the attack’s feasibility, recommended mitigation (Message‑Authenticator), and the operational prerequisites (local access, ability to inject or manipulate RADIUS payloads). This cross‑reference confirms the technical description and the practical countermeasures.

If any claim in the advisories lacks direct vendor patch detail (for example, product‑specific fixed firmware version identifiers), treat the vendor advisory as the authoritative source for exact patch levels and follow Hitachi’s PSIRT channels and change control procedures to obtain certified updates.

---

Recommended reading and next‑steps for WindowsForum readers managing ICS/OT​

• Treat the Hitachi guidance to enable RADIUS Message‑Authenticator as high priority and verify the change across both RADIUS clients and servers.
• Inventory all RADIUS‑dependent services and place them on a prioritized remediation plan: enable Message‑Authenticator, apply vendor updates, transition to RadSec/EAP‑TLS, and isolate and harden management networks.
• Incorporate RADIUS hardening into ongoing ICS/OT defense‑in‑depth strategies: network segmentation, least‑privilege access, multifactor authentication, strict management host policies, and continuous logging/monitoring. CISA technical guidance reiterates these defensive practices for critical infrastructure operators.

---

Conclusion​

CVE‑2024‑3596 is a protocol‑level failure exposed by advances in cryptanalysis and collision generation techniques against MD5. For Hitachi Energy AFS, AFR and AFF series operators the fastest, practical, vendor‑endorsed step is to enforce the RADIUS Message‑Authenticator option immediately and confirm interoperability across RADIUS peers. That action significantly reduces the attack surface while organizations coordinate firmware updates and longer‑term migrations to authenticated, encrypted RADIUS transports (RadSec) or stronger EAP methods. Network defenders should assume that any RADIUS‑based authentication mechanism using legacy MD5 constructs needs urgent review, prioritization, and remediation to protect integrity and availability of network and OT authentication services.

---

Source: CISA Hitachi Energy AFS, AFR and AFF Series | CISA