MD5 attack on RADIUS/UDP opens door to unauthorized admin access

MD5 has been cryptographically broken since 2004, when researchers demonstrated the first collision attacks. In the two decades since, those attacks have only gotten faster and more practical against real-world protocols. Yet MD5 remains embedded in several network protocols—including RADIUS, the authentication protocol used for remote access to routers, switches, and other networking infrastructure.

Researchers have now demonstrated that this reliance on MD5 creates a practical vulnerability in RADIUS/UDP. The attack, dubbed Blast-RADIUS, allows a Monster-in-the-Middle (MitM) attacker with access to RADIUS traffic to gain unauthorized administrative access to devices using RADIUS for authentication—without brute-forcing passwords or shared secrets. The vulnerability is tracked as CVE-2024-3596 and VU#456537, and it affects all RADIUS/UDP authentication modes except those using EAP (Extensible Authentication Protocol).

How RADIUS/UDP uses MD5

RADIUS was first designed in 1991, during the dial-up era, and remains widely deployed in networking and industrial control environments. In a typical RADIUS/UDP deployment, a device running a RADIUS client sends an Access-Request containing a username and password to a remote RADIUS server over UDP. The server responds with an Access-Accept, Access-Reject, or Access-Challenge packet.

The Access-Request itself is unauthenticated—the server drops the packet only if its source IP address is unknown. Response packets, on the other hand, are protected by an ad hoc "MAC" called the Response Authenticator, which hashes a concatenation of fields from the request and response packets together with the shared secret:

MD5( Code || ID || Len || Request Authenticator || Attributes || Secret )

This construction dates back to 1994. It was not updated when HMAC was standardized in 1997, nor when MD5 collisions were first found in 2004. The RADIUS specifications do define an optional Message-Authenticator attribute using HMAC-MD5, added in RFC2869 in 2000, but it remains optional for non-EAP modes of RADIUS/UDP. HMAC-MD5 is not susceptible to the collision attacks described here; the vulnerability applies to default setups relying only on the Response Authenticator.

The Response Authenticator is not a real MAC

The Response Authenticator fails as a message authentication code because of two properties of MD5:

  • Length extension: MD5 processes input in consecutive blocks, so given MD5(X) and the length of X, anyone can compute MD5(X || Y) for any known Y.
  • Collision propagation: If MD5(X1) = MD5(X2), then MD5(X1 || Secret) = MD5(X2 || Secret).

This means an attacker who finds two colliding messages X1 and X2 can learn the MAC on X1 and reuse it on X2, never knowing the secret.

Early MD5 collision attacks produced "identical prefix" collisions of the form MD5(P || G1 || S) = MD5(P || G2 || S), where P and S are meaningful messages and G1/G2 are gibberish. The more powerful "chosen-prefix" collision attack, introduced in 2007, allows the attacker to choose different meaningful prefixes P1 and P2 entirely. The Blast-RADIUS researchers improved this chosen-prefix attack and applied it to RADIUS, where P1 corresponds to an Access-Reject packet and P2 to an Access-Accept packet.

Executing the attack

To convert an Access-Reject into an Access-Accept, the attacker must inject collision gibberish into the RADIUS packets. The attack leverages the Proxy-State attribute—an optional field that the RADIUS server must echo back in its response. Since Proxy-State is hashed in the Response Authenticator, it provides a suitable vehicle for collision blocks.

The attack flow works as follows:

  1. The attacker attempts to log in to a device running a RADIUS client using a bogus username and password.
  2. The client sends an Access-Request, which the MitM intercepts.
  3. The MitM runs the MD5 chosen-prefix collision attack to find gibberish blocks RejectGib and AcceptGib, where P1 || RejectGib collides with P2 || AcceptGib.
  4. The MitM inserts RejectGib into the intercepted Access-Request as multiple Proxy-State attributes. The collision gibberish must be formatted to be valid within these attributes—one of the novel contributions of the research.
  5. The server processes the modified request and responds with an Access-Reject containing the Proxy-State gibberish and a valid Response Authenticator computed as MD5(P1 || RejectGib || Secret).
  6. The MitM intercepts the response, extracts the Response Authenticator, and forges an Access-Accept packet with AcceptGib in its Proxy-State attribute.
  7. The client receives the forged packet. Because MD5(P1 || RejectGib || Secret) = MD5(P2 || AcceptGib || Secret), the Response Authenticator validates and the attacker is logged in with administrative access.

The attack works against RADIUS/UDP in PAP, CHAP, and MS-CHAP authentication modes.

Speed was the bottleneck

For the attack to succeed, the collision must be computed before the RADIUS client times out. The attack cannot be precomputed because the request's Request Authenticator is a fresh 16-byte random nonce that the MitM cannot predict before intercepting the packet in flight.

Existing MD5 chosen-prefix collision attacks took hours or up to a day to complete—far too slow for realistic client timeouts. The research team optimized the attack for speed and space, demonstrating a working collision in under five minutes on an aging cluster of about 2,000 CPU cores plus four low-end GPUs. Many RADIUS devices tolerate timeouts that long, though default timeouts on most devices are closer to 30 or 60 seconds. The attack is highly parallelizable, so a sophisticated adversary with better computing resources could achieve much faster timings.

Mitigations for RADIUS deployments

Several mitigations are available for RADIUS deployments. The strongest is to move to RADIUS over TLS (sometimes called RADSEC), which wraps the entire RADIUS payload in TLS and protects against any MD5-based attack. This requires upgrading both clients and servers.

For organizations that cannot yet make that transition, a short-term patch exists for RADIUS/UDP deployments:

  1. The recipient of any RADIUS/UDP packet must require the packet to contain a Message-Authenticator and validate the HMAC-MD5 value.
  2. RADIUS servers should send the Message-Authenticator as the first attribute in every Access-Accept or Access-Reject response.

Both client and server must change behavior for this mitigation to work. Patching only the client fails because a MitM could strip the Message-Authenticator (a downgrade attack). Patching only the server may be more effective in some configurations, but risks breaking compatibility with legacy clients that cannot send the attribute. There is also some evidence that requiring Message-Authenticator on requests from all clients could be a workable interim measure. See Alan DeKok's whitepaper for guidance on applying these mitigations to more complex, multihop RADIUS deployments.

Isolating RADIUS traffic—avoiding sending it in the clear over the public Internet and segregating it on internal networks—remains a best practice, though it does not fully protect against a MitM attack on its own. RADIUS/TCP is not a viable mitigation; it offers no security advantages over RADIUS/UDP.

EAP considerations

EAP-TLS requires careful distinction from RADIUS/TLS. With EAP-TLS, RADIUS traffic is still sent in the clear over UDP; the TLS handshake only authenticates the user between the client and the RADIUS server. The RADIUS specifications mandate the HMAC-MD5 Message-Authenticator attribute for all packets carrying EAP attributes, which would stop the Blast-RADIUS attack. However, specification ambiguities mean it is unclear what a RADIUS client should do if a MitM strips the EAP attributes from a response—along with the Message-Authenticator, which would be optional for the resulting non-EAP packet. The researchers have not demonstrated an attack against EAP-TLS implementations but cannot rule out the possibility of a variant. The recommended defense remains RADIUS/TLS, not EAP-TLS.

IETF efforts

The IETF's radext working group is considering proposals to deprecate RADIUS/UDP and create a standards-track specification for RADIUS over TLS or DTLS. The Blast-RADIUS research is likely to accelerate those efforts to reduce RADIUS's dependence on MD5.