If you are an end user, there is nothing that you can or should do.

If you are a system administrator, then consider the following questions:

1. Is all RADIUS traffic accounting, and only accounting? Our attack does not seem to be practical in that setting. You should still upgrade everything, but you can take your time.

2. Are all Access-Request packets sent over RADIUS/TLS (RadSec)? The TLS should protect against our attack. You should still upgrade everything, but you can take your time.

3. Are your RADIUS servers only doing EAP authentication, and no other kinds of authentication? Our attack does not seem to be practical in that setting. You should still upgrade everything, but you can take your time.

4. Are the RADIUS servers only handling local requests? That is, no RADIUS servers in your network are doing proxying? Upgrade your RADIUS servers first. All server vendors have deployed a mitigation that includes a Message-Authenticator attribute as the first attribute of every response, which we believe mitigates our attack. You should still upgrade your NAS equipment/RADIUS clients, but this is less critical than updating servers immediately.

5. For everyone else, you should upgrade your RADIUS servers immediately, then upgrade clients/NAS equipment where possible, and set the configuration flags on both sides to require Message-Authenticator attributes. The specific configuration is vendor-specific and you will need to consult your RADIUS vendor.

You can find other FAQs on the upgrade process here.

CERT/CC coordinated our disclosure and has assigned CVE-2024-3596 and VU#456537 to this vulnerability.

A script with an example collision is available here. The --verbose option allows the printing of unshortened values. The script goes through the attack step by step:

1. The Access-Request sent by the RADIUS client, from which the adversary learns the Request Authenticator and IDs.
2. The MITM uses these values from the Access-Request to predict Accept and Reject prefixes and then computes the collision gibberish that it computes for these prefixes.
3. The MITM assembles the Access-Request with that Reject gibberish appended, that is sent to the RADIUS server.
4. The Access-Reject sent back by the server contains the Response Authenticator.
5. The MITM puts this value to assemble the Access-Accept.
6. We show both the Access-Accept and Access-Reject both produce the same Response Authenticator.

We are not publishing end-to-end attack code. Our improvements to the MD5 chosen-prefix collision attack are available in the hashclash GitHub repository.

If you are a vendor or system administrator who wishes to test for this vulnerability, a RADIUS server implementation is vulnerable if it does not require a Message-Authenticator attribute in every client request. A RADIUS client is vulnerable if it does not require a Message-Authenticator attribute from every server response. See Alan DeKok’s white paper for more information.

Our attack is more complex than simply applying an old MD5 collision attack.

While an MD5 hash collision was first demonstrated in 2004, it was not thought to be possible to exploit this in the context of the RADIUS protocol. Our attack identifies a protocol vulnerability in the way RADIUS uses MD5 that allows the attacker to inject a malicious protocol attribute that produces a hash collision between the server-generated Response Authenticator and the attacker’s desired forged response packet.

In addition, because our attack is online, the attacker needs to be able to compute a so-called chosen-prefix MD5 collision attack in minutes or seconds. The previous best reported chosen-prefix collision attack times took hours, and produced collisions that were not compatible with the RADIUS protocol.

We introduce several improvements in speed, space, and scaling for the existing MD5 attacks to demonstrate that these collisions can be computed in at most minutes and can fit within RADIUS protocol attributes.

Yes and no. In the proof-of-concept attacks described in our paper, it took us 3 to 6 minutes to compute the MD5 chosen-prefix hash collision required for the attack. This is longer than the 30- to 60-second timeouts that are commonly used in practice for RADIUS.

However, every step of the collision algorithm parallelizes well and is amenable to hardware optimization, so we expect a well-resourced attacker could obtain running times that are tens or hundreds of times faster by implementing the attack on GPUs, FPGAs, or hardware.

Our reported running times are from optimizing some 15 year old code and running it on a bunch of 7 to 10 year old CPUs, because this is what we have access to. We did not think that spending further engineering effort to make MD5 collisions faster was a good use of time when MD5 should have been abolished 20 years ago.

Our attack requires the adversary to have network access to act as a man-in-the-middle attacker on the connection between the victim device’s RADIUS client and RADIUS server. When there are proxies, the attack can occur between any hop. Our attacker will need to be able to act as a full network man-in-the-middle who can read, intercept, block, and modify inbound and outbound network packets.

Such access to RADIUS traffic may happen through different mechanisms. Although sending RADIUS/UDP over the open internet is discouraged, this is still known to happen in practice. For internal network traffic, the attacker might initially compromise part of an enterprise network; such compromises appear frequently in news reports and security advisories. Even if RADIUS traffic is confined to a protected part of an internal network, configuration or routing mistakes might unintentionally expose this traffic. An attacker with partial network access may be able to exploit DHCP or other mechanisms to cause victim devices to send traffic outside of a dedicated VPN.

Our adversary does not know the shared secret between the RADIUS client and server.

A current best practice for RADIUS/UDP traffic is to expose it only to a restricted-access management VLAN within an organization. While this reduces the attack surface and is certainly preferable to exposing UDP traffic to a broader network or the open internet, there may still be vulnerabilities in case of a network misconfiguration or attacker compromise of this portion of the network.

This approach is also at odds with the US Executive Branch Office of Management and Budget’s 2022 memo, which envisions moving to systems that do not rely on network separation for security: “A key tenet of a zero trust architecture is that no network is implicitly considered trusted”.

Nearly all RADIUS/UDP implementations are vulnerable to our protocol attack when using non-EAP authentication methods. RADIUS is used by many organizations to control access to a wide variety of network devices and services. Our attack requires man-in-the-middle network access; organizations should evaluate their own network security threat model.

RADIUS implementers, vendors, and system administrators should follow best practices and the guidance in this document. Our attack does not compromise end user credentials, and there is nothing that end users can do to protect against this attack.

EAP authentication methods are protected against our attack because RFC 2869 mandates that a Message-Authenticator attribute must be present, and this attribute is an HMAC-MD5 over the entire packet that we cannot forge. A theoretical protocol vulnerability appears to exist, but may not be practically exploitable. RADIUS Accounting also appears to be affected by a theoretical protocol vulnerability that seems to be difficult to exploit in practice.

An adversary exploiting our attack can escalate privileges from partial network access to being able to log into any device that uses RADIUS for authentication, or to assign itself arbitrary network privileges.

RADIUS is used for remote access for diverse use cases including network routers and switches, industrial control systems, VPNs, ISPs using DSL or FTTH, Linux Pluggable Authentication Modules, 2G and 3G cellular roaming and 5G DNN authentication, and mobile Wi-Fi offload with SIM card-based authentication.

Yes, but you need log files of Access-Rejects on the RADIUS server and Access-Accepts on the RADIUS client.

If you have detailed log files on the RADIUS client that log the values of all attributes, you could look for suspicious Proxy-State attributes. If there are Access-Accept packets with Proxy-State attributes consisting of random bytes, then this might be a sign of an attack. End clients should not receive packets with Proxy-State attributes.

To confirm an attack, you need would need to find the corresponding Access-Reject (or any other type) response packet in the RADIUS server logs, and verify that the server’s response differs from the response received by the client, and that both contain valid Response Authenticator values for the request ID and Request Authenticator.

If both of these packets produce the same MD5 hash in the Response Authenticator, this issue was exploited in your system.

We recommend reading the detailed guide for implementors published by Alan DeKok, the maintainer of FreeRADIUS.

Patches including the short-term mitigation described in the mitigation section will be available from major RADIUS implementations in coordinated release with this work; downstream vendors and network operators should check for and apply these patches. Where an option exists to require a Message-Authenticator attribute on all packets, this option should be enabled.

Implementers, vendors, and admins should follow the guidance in this IETF draft to deprecate insecure practices in RADIUS to mitigate numerous other attacks; we expect future versions to mandate Message-Authenticator attributes in more settings.

The long-term mitigation for our attack is to use RADIUS inside of a modern cryptographically protected transport like TLS 1.3. The IETF RADEXT working group has existing drafts in progress outlining RADIUS/(D)TLS.

It depends.

Including a Message-Authenticator attribute in every packet is backward compatible. Unfortunately, requiring the presence of a Message-Authenticator attribute in requests and responses may not be backward compatible with old client or server implementations that do not have the option to include them.

Our long-term mitigation of moving to RADIUS/TLS requires clients and servers that support TLS, as well as new configuration (like PKI) on the part of network operators. TLS may not be supported at all on older hardware.

A number of tempting, commonly suggested countermeasures do not sufficiently mitigate the vulnerability.

Decreasing Timeouts

It is tempting to hope that simply setting a shorter client timeout would mitigate our attack. We believe this should not be done: it decreases usability and does not protect against our attack.

Our MD5 collisions were computed after applying some optimizations to a 15-year-old proof-of-concept codebase, which we are running on CPUs mostly dating from seven to ten years ago, because these are the resources we have access to. An adversary with a budget for professional engineering would be able to decrease the computational cost of the collision by a factor of tens to hundreds.

The most common timeout in practice is 30 seconds, and 60 seconds is commonly recommended when multifactor authentication is involved, since shorter timeouts could be problematic for real users.

Using TACACS+ or Diameter

RADIUS is not the only protocol to suffer from the types of security issues that we outline. TACACS+ is a popular (TCP-based) administrator login protocol for switches that also does not meet modern cryptographic security standards. RFC 8907 was published in September 2020, and explicitly mandates that TACACS+ be used with a secure transport. However, much like RADIUS, TACACS+ is still most commonly used over insecure transports.

Diameter (RFC 6733) was initially designed as a successor to RADIUS, although it never replaced RADIUS for many common use cases. It is used in 3G+ networks, and is generally only supported in large NAS equipment used by bigger ISPs and telecommunications providers; consumer or enterprise-grade equipment typically only supports RADIUS.
Although Diameter was intended to replace RADIUS, the protocol itself offers no security when used over TCP. As a result, RFC 6733 suggests that Diameter messages should be secured using TLS or DTLS; 5G has replaced Diameter with signaling over HTTP/2. The US government has described exploits against Diameter targeting mobile users.

Random shared secrets

Organizations can protect against dictionary attacks on the shared secret by picking random shared secrets of sufficient length, as the runtime of such an attack grows exponentially with the entropy of the secret. For example, this work-in-progress IETF draft recommends shared secrets with at least 96 bits of entropy, so an offline dictionary attack would involve on the order of \(2^{96}\) MD5 compressions. However, as our attack does not try to brute force the shared secret, choosing a strong shared secret does not affect the runtime of our attack.

Using Multi-Factor Authentication (MFA)

Using MFA or 2FA is not a mitigation either. Our attack largely bypasses the user authentication mechanism, and forges the accept response from the server’s reject. MFA may be supported through multiple mechanisms within the RADIUS protocol, including authentication protocols like PAP that are vulnerable by default to our attack.

Rejecting Proxy-States

Our forged Access-Accept packets contain Proxy-State attributes that the client is not expecting. However, having the client discard packets with unexpected Proxy-States does not mitigate the vulnerability. First, such a mitigation would only apply to a NAS; the Proxy-State attribute is actually used by RADIUS server proxies and thus difficult to remove without breaking functionality.

Even if NAS clients rejected unexpected Proxy-State attributes, it would be possible to craft colliding packets where the Access-Accept has the collision gibberish in a different attribute such as Vendor-Specific or Reply-Message that is likely to be accepted; the client does not need to support or attempt to interpret the garbage attribute to be vulnerable.

The colliding Access-Reject packet would still use Proxy-State attributes, as the server is guaranteed to include Proxy-State attributes unchanged in an Access-Reject. For simplicity our implementation uses Proxy-States in both colliding packets, as no RADIUS client we tested complained about the unexpected Proxy-State.

Replacing MD5

It is tempting to think that simply replacing MD5 in the Response Authenticator with a secure hash function like SHA-2 or SHA-3 might be a short-term mitigation against our attacks. However, since the RADIUS protocol does not provide for any cryptographic agility, such a change would be incompatible with all existing implementations, and thus be equivalent to requiring a new protocol. Given the other security and privacy concerns with the rest of RADIUS, it would be better at that point to redesign the entire protocol or transport.

EAP-TLS is not the same as RADIUS/TLS. EAP-TLS uses a TLS handshake to carry out certificate-based authentication, but does not use TLS to encrypt the RADIUS access request and response packets, which are still transmitted over UDP in the clear. This is different from RADIUS/TLS, which transmits all RADIUS packets inside of an encrypted TLS session.

In more detail, when EAP (Extensible Authentication Protocol) is used for authentication within RADIUS, the client NAS sends a RADIUS Access-Request packet to the RADIUS server that contains a RADIUS attribute called EAP-Message. For RADIUS/UDP, this Access-Request is sent in the clear via UDP. The authenticating peer and server then authenticate using the requested EAP method: for EAP-TLS, they use certificates to complete a TLS handshake. After the end of the EAP authentication process, the server completes the RADIUS conversation by sending a RADIUS Access-Accept or Access-Reject packet; for RADIUS/UDP this packet is again sent in the clear over UDP.

Our attack targets RADIUS access requests and responses. However, EAP-TLS does not appear to be practically exploitable by our attack because all packets containing EAP-Message attributes must contain a MD5-HMAC Message-Authenticator attribute that we cannot forge. However, a theoretical protocol attack may still be possible against RADIUS even when clients make an EAP-TLS (or other EAP) authentication request. The details and the impact of such an attack would be implementation-dependent and we have not found a practically exploitable implementation.

A more detailed explanation is in Section 5.6 of our paper.

We reduced the online running time for our MD5 chosen-prefix attack from hours down to minutes. However, this should be interpreted as a generous upper bound for the true cost of such collisions, because of the limits on our computational resources. Newer CPUs than the seven to ten year old machines we have access to would likely provide minutes of improvement, as would optimizing cache locality.

Access to more and faster GPUs for the chosen-prefix attack would reduce the time for the birthday stage and/or reduce the number of near-collision blocks, reducing time for the near-collision stage.

Reimplementing hashclash in hardware, for example on FPGAs (Field Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits) would likely improve the running time by a factor of ten to a hundred.

It would be eminently feasible to run this attack on cloud resources. Amazon EC2 lists the on-demand price of a c7a.48xlarge instance with 192 vCPUs at $9.85/hour, and the price of a g6.48xlarge instance with 192 vCPUs and 8 NVIDIA L4 GPUs at $13.35/hour. It would cost around $50/hour to exceed our computing capacity, and in principle one could scale to many more machines.

Unfortunately, we are not able to use network scanning to provide a representative picture of RADIUS deployments. Many RADIUS servers will be on internal networks. Even for external-facing servers, RADIUS hosts are identified by IP address and servers only accept packets from allowed addresses. The RADIUS RFC specifies that servers should drop requests for hosts that they have not been pre-configured to have a shared secret with. Our scanning host would not be whitelisted by properly configured servers, so an internet-wide scan would thus only turn up misconfigured servers. Additionally, since it is a UDP-based protocol with no handshake before a login request, we cannot do TCP SYN scanning and would need to scan using a well-formed UDP Access-Request, which would appear as an attack to network administrators.

This does not affect the adversary in our attack model, who intercepts traffic between a legitimate client and server.

However, since this vulnerability is in the protocol, nearly all RADIUS/UDP implementations are vulnerable to our attack when using non-EAP authentication methods.

Of course! Various versions with transparent, white, and black background are available here.