Mitigate CVE-2024-3596: Enable RADIUS Message-Authenticator on FOX61x

Hitachi Energy has confirmed that certain FOX61x devices are affected by a critical RADIUS protocol vulnerability (tracked as CVE‑2024‑3596) that allows an on‑path attacker to forge RADIUS responses by exploiting a chosen‑prefix collision attack against the MD5‑based Response Authenticator; Hitachi’s immediate mitigation is to enable the RADIUS Message‑Authenticator option on both the FOX61x device and the RADIUS servers, and to upgrade to the vendor‑recommended firmware where available. /www.cisco.com/c/en/us/support/docs/csa/cisco-sa-radius-spoofing-july-2024-87cCDwZ3.html)

Background​

What’s broken and why it matters​

RADIUS (Remote Authentication Dial‑In User Service) remains a cornerstone protocol for authentication, authorization and accounting in enterprise VPNs, Wi‑Fi networks and network access devices. The RADIUS Response Authenticator — specified in RFC 2865 — historically relies on an MD5 digest over several packet fields and a shared secret to protect server responses. That construction is now demonstrably weak: modern chosen‑prefix collision techniques against MD5 let attackers craft two different messages that produce the same MD5 digest under controlled conditions, enabling response forgery.
The practical consequence is simple and severe: if a RADIUS deployment does not require or validate the Message‑Authenticator attribute (RFC 2869 / RFC 3579), an attacker on the local network path can intercept a genuine RADIUS response (for example, an Access‑Reject) and replace it with a forged Access‑Accept that will be accepted by the network access device (NAD). That can grant unauthorized network access, deny legitimate users service, or manipulate session attributes such as VLAN assignment — an outcome especially dangerous in industrial and critical‑infrastructure environments.

Who’s affected​

Hitachi Energy lists FOX61x devices as known affected when configured to use remote RADIUS authentication, and A and earlier (and R18 behaviour dependent on configuration) as impacted unless the Message‑Authenticator mitigation is enabled. The advisory explicitly ties the exposure to RADIUS setups that do not enforce the Message‑Authenticator attribute.
This protocol‑level weakness has been widely acknowledged across vendor advisories and vulnerability databases; it is not limited to a single vendor or product line — the real difference between safe and vulnerable deployments is whether the Message‑Authenticator is required and enforced, or whether RADIUS is transported over a protected channel (for example, RadSec/RADIUS‑over‑TLS).

---

Technical analysis: how the forgery works​

MD5, Response Authenticator and chosen‑prefix collisions​

RADIUS Response Authenticator = MD5(Code | ID | Length | RequestAuthenticator | Attributes | Secret). The Response Authenticator does not cover every byte in all practical ways that would prevent chosen‑prefix collisions, and MD5’s collision resistance is broken in ways that are directly exploitable for RADIUS response forgery. Chosen‑prefix collisions let an attacker select two different prefixes and compute suffixes such that the final MD5 digest matches for both prefixed messages; when that digest is used as the Response Authenticator, a forged reply can pass verification.

Preconditions and attacker capabilities​

This is not a purely remote, Internet‑wide worm: exploitation requires local network access or the ability to observe and inject RADIUS traffic on the path between the NAD and the RADIUS server (for example, a compromised access point, a malicious insider on the same VLAN, or a man‑in‑the‑middle device on a provisioning network). In addition, practical collision generation is typically easier when the attacker can influence or observe certain attributes used as prefixes. However, multiple writeups and vendor guidance indicate collision generation times are within operational RADIUS retransmit windows on modern hardware, making this a practical attack in real networks.

Why Message‑Authenticator defeats the attack​

The RADIUS Message‑Authenticator attribute (RFC 2869 / RFC 3579) uses an HMAC‑MD5 construction that covers the full packet and therefore resists the chosen‑prefix collision approach used against the Response Authenticator. When the Message‑Authenticator is present and validated by the server and client, it prevents an intermediary from successfully swapping or modifying packets without the shared secret and HMAC key material. For that reason, vendors and operators converge on enabling and enforcing Message‑Authenticator as the primary practical mitigation until transport‑level protections (RadSec/TLS) or protocol redesigns are available.

---

What Hitachi Energy says and immediate rem’s advisory and recommended actions​

Hitachi Energy’s coordination (published in their PSIRT/CISA conversion) identifies FOX61x models affected and recommends:

• Upgrade to FOX61x R18 where available, and
• Enable the RADIUS Message‑Authenticator option in both the FOX61x device and the remote RADIUS server configuration.

If an immediate upgrade is not possible, Hitachi also recommends segmentation of FOX management/RADIUS traffic and applying standard ICS network hardening practices (isolate control networks, protect management ports, limit remote access).

Important configuration nuance​

Merely sending a Message‑Authenticator in Access‑Requests is not enough. The server must require and validate it; otherwise, an attacker could strip or alter the attribute on the client side before the server computes a response. Successful mitigation therefore generally requires both the NAD to include the attribute on requests and the RADIUS server to enforce that requests/responses contain a valid Message‑Authenticator. Vendor documentation and device‑specific commands (for other Hitachi product lines) were published to toggle and verify Message‑Authenticator enforcement; operators should consult their FOX61x Technical User Documentation for the precise CLI or management UI steps relevant to their firmware revision.

---

Operational risk and impact—why control networks should prioritize this​

Confidentiality, integrity and availability on the line​

A forged Access‑Accept can grant an attacker a valid session credential to an operational network (confidentiality and integrity breach). A forged Access‑Reject can deny service to legitimate operators (availability impact), and an attacker can manipulate session attributes (such as VLAN or network placement) to re‑route or segregate traffic for follow‑on attacks. In industrial environments, where network access maps to access to instrumentation, control PLCs or substation devices, the downstream physical and safety impacts can be meaningful even if the protocol vulnerability itself is purely digital.

Likelihood and attractiveness for attackers​

While exploitation requires local positioning, many real‑world environments provide that access surface: guest Wi‑Fi that bridges to provisioning networks, contractor laptops, misconfigured management VLANs, or compromised on‑site devices. In short: the attack is sufficiently practical that defenders should treat FOX61x RADIUS deployments as high‑priority to remediate or mitigate. This is reflected in the high CVSS scores assigned by vendors and aggregators.

---

Practical, prioritized remediation plan (for WindowsForum readers managing FOX61x)​

Below is a field‑tested, prioritized checklist you can follow to reduce risk this week and remediate properly over the coming weeks.

1. Inventory and scope (Immediate)
   • Identify all FOX61x devices in your estate and log current firmware versions and whether they use remote RADIUS authentication. Confirm whether management/RADIUS traffic traverses shared or exposed networks.
2. Confirm RADIUS server behaviour (Immediate)
   • Check your RADIUS server(s) (Windows NPS, FreeRADIUS, vendor appliances) and confirm whether they:
     • are configured to include Message‑Authenticator in responses, and
     • are configured to require and validate Message‑Authenticator on incoming Access‑Requests.
   • If not, plan to enable these options and prepare for interoperability testing. Microsoft and other vendors provide KBs for the exact configuration options to enforce message‑auth; enabling both client inclusion and server validation is essential.
3. Enable Message‑Authenticator in a controlled test (Short‑term, same day)
   • On a non‑production NAD or in a lab: enable Message‑Authenticator on the NAD and on the RADIUS server requiring it. Validate normal authentication flows and check logs for NADs are legacy and cannot include Message‑Authenticator, you must either segment them or upgrade.
4. Rollout to production (1–7 days)
   • After successful testing, schedule a phased rollout to production FOX61x devices. Monitor for interoperability issues, especially with third‑party VPN gateways or older NADs that may not support Message‑Authenticator. Keep rollback plans and maintenance windows ready.
5. Firmware upgrades (2–8 weeks)
   • Follow Hitachi’s upgrade path to R18 where available, per vendor guidance. Upgrading removes configuration ambiguity and often sets secure defaults; after upgrading, ensure Message‑Authenticator enforcement remains enabled.
6. Network hardening (ongoing)
   • Segment control and management networks (separate VLANs and firewalls), deny direct Internet access from process control networks, and restrict RADIUS traffic to trusted management subnets. This reduces the attack surface if any device cannot be immediately remedied.
7. Long‑term: move off MD5‑only protections
   • Where possible, migrate RADIUS over TLS (RadSec) or use modern transport protections and authentication methods that avoid MD5 constructions entirely. Consider vendor roadmaps for protocol updates and phase out older appliances that cannot support these transports.

---

Detection and monitoring guidance​

• Enable and centralize RADIUS logs for correlation: log both Access‑Request and Response contents (where policy allows) and monitor for suspicious patterns such as rapid access decision flips, mismatched transaction IDs, or unexpected changes in session attributes for known endpoints.
• Watch network traffic for anomalous RADIUS packet alterations or duplicate responses within short time windows; an on‑path attacker may inject forged packets quickly to maintain timing. Consider IDS rules tuned to detect RADIUS replay/duplicate patterns.
• Correlate authentication anomalies with network events (e.g., DHCP/VLAN changes) and physical access events (guest Wi‑Fi usage, contractor access) to rapidly detect potential exploitation attempts.

---

Interoperability caveats and testing notes​

• Not all NADs include Message‑Authenticator by default; some client stacks only include it when EAP is used. That means enabling Message‑Authenticator enforcement on the server can break legacy clients that never send it. The correct sequence is: enable NADs to send the attribute, then enable server enforcement, with staged testing. Cisco and Microsoft advisories both emphasize this operator ordering.
• In environments with third‑party or legacy VPN concentrators, create a compatibility matrix and test each NAD/server pair prior to wide enforcement. Where legacy NADs cannot be upgraded, isolate them behind dedicated RADIUS proxies or management VLANs and restrict their use.

---

Why this is also a governance and procurement problem​

CVE‑level protocol weaknesses like this expose a wider issue: many control‑plane appliances still rely on legacy cryptography by default. Organizations should require vendors to:

• Adopt modern transport protections (RadSec/TLS) and move away from MD5‑based integrity checks.
• Provide secure default configurations that require strong integrity/authentication attributes.
• Supply clear CLI/UI guidance for toggling mitigations and provide compatibility guidance for mixed‑vendor environments.

Procurement language should include minimum cryptographic baseline requirements and support SLAs for security advisories and firmware upgrades. Hitachi’s advisory and the supporting CISA republication make clear this is a cross‑vendor, system‑level problem that requires operator discipline and vendor responsiveness.

---

Strengths and limitations of the vendor mitigation​

Notable strengths​

• Enabling Message‑Authenticator is a pragmatic, immediate mitigation that can be implemented without major protocol redesign. It provides strong protection in real networks when enforced on both ends. Hitachi’s guidance to enable the setting and push for upgrades is the correct operational first step.

Remaining limitations and risks​

• Message‑Authenticator relies on correct deployment: if only one side uses it, or if proxies strip the attribute, the protection can be bypassed. Operators must verify enforcement end‑to‑end.
• Legacy devices or third‑party NADs that cannot send/handle Message‑Authenticator may force risky exceptions, detours or segmentation workarounds that increase operational complexity and management cost.
• Message‑Authenticator uses HMAC‑MD5; while HMAC constructions are stronger than raw MD5 collision constructs, HMAC‑MD5 is not future‑proof cryptography. The long‑term objective remains migration to transport‑level TLS protections or modern cryptographic primitives.

---

Final assessment and recommended priority for WindowsForum readers​

• Treat FOX61x RADIUS deployments as high priority to remediate: enable athenticator on both device and server, test for compatibility, and roll the change out in a phased manner. Where possible, upgrade FOX61x firmware per Hitachi’s recommendation and harden network segmentation immediately.
• If you cannot immediately enable Message‑Authenticator or upgrade firmware, isolate affected devices and restrict RADIUS management traffic to a tightly controlled management network. Consider short‑term compensating controls such as VPNs for remote access (with up‑to‑date VPN stacks), strict firewall rules, and enhanced logging/monitoring while you plan permanent fixes.
• Finally, update your vendor‑risk assessments and procurement controls so future RADIUS deployments are either protected by Message‑Authenticator enforcement by default or migrated to RadSec/TLS. This advisory is a clear reminder that legacy cryptography in ubiquitous protocols can create critical, cross‑sector risk if left unmitigated.

---

Enabling Message‑Authenticator and verifying enforcement is the single most effective immediate step to blunt this class of attack; plan upgrades and architecture changes for the medium term, and treat RADIUS deployments in control networks as high‑value assets requiring urgent attention.

---

Source: CISA Hitachi Energy FOX61x | CISA