Blast-RADIUS: How MD5 Collisions Break Enterprise Network Authentication

TLDR: The Blast-RADIUS research exposes a critical vulnerability in the RADIUS protocol that allows a man-in-the-middle attacker to forge an Access-Accept response from an Access-Reject packet without knowing the shared secret. By leveraging MD5 chosen-prefix collisions, an attacker can manipulate the response authenticator field to bypass authentication on enterprise network equipment. Security teams must prioritize migrating from RADIUS over UDP to RADIUS over TLS and ensure the Message-Authenticator attribute is strictly enforced.

Network authentication protocols are often the "set it and forget it" components of enterprise infrastructure. RADIUS has been the backbone of network access control for over two decades, quietly handling authentication for everything from VPN concentrators to industrial control systems. Because it is so deeply embedded, it rarely receives the scrutiny it deserves. The Blast-RADIUS research changes that by demonstrating how a fundamental flaw in the protocol’s reliance on MD5 for integrity checks can be weaponized to bypass authentication entirely.

The Mechanics of the Attack

At its core, RADIUS uses a shared secret between the client (the network device) and the server (the authentication database) to verify the integrity of packets. When a server sends an Access-Accept or Access-Reject message, it includes a response authenticator—a 16-byte hash computed over the packet header, the request nonce, the attributes, and the shared secret.

The vulnerability exists because this hash is computed using MD5. While MD5 is famously broken for collision resistance, the researchers behind Blast-RADIUS took this further by applying chosen-prefix collision techniques. An attacker positioned as a man-in-the-middle can intercept an Access-Reject packet and, without knowing the shared secret, craft a collision that results in an Access-Accept packet with the exact same response authenticator.

The attack flow is precise. The adversary intercepts the initial Access-Request from the client. They then use the information in that request to predict the server’s response. By running an MD5 collision algorithm, they generate a forged Access-Accept packet that matches the authenticator of the expected Access-Reject. When the client receives this forged packet, it validates the authenticator, assumes the authentication was successful, and grants the attacker access to the network.

Technical Hurdles and Optimization

Executing this in the real world is not as simple as running a single script. The primary challenge is the time constraint. RADIUS clients have strict timeouts, often as low as 15 to 60 seconds. A standard MD5 collision attack would take far too long to compute within that window.

The researchers optimized this by moving the bulk of the computation into pre-computation phases that are independent of the specific request nonce. They also utilized GPU-accelerated birthday searches to drastically reduce the time required to find a collision. By parallelizing the computation across multiple machines, they brought the attack time down to under five minutes. While this is still longer than a typical RADIUS timeout, it demonstrates that the barrier to entry for this attack is significantly lower than previously assumed.

For those looking to experiment with the collision logic, the researchers have provided a proof-of-concept repository that illustrates how these packets are constructed. It is a masterclass in protocol manipulation.

Real-World Applicability

During a penetration test, you are likely to find RADIUS running over UDP in legacy environments or internal segments where traffic is assumed to be "trusted." If you can position yourself as a man-in-the-middle—perhaps through ARP spoofing or by compromising a switch—you can target the authentication flow.

The impact is total. If you successfully forge an Access-Accept, you are not just bypassing a login screen; you are potentially gaining administrative access to network infrastructure. This includes Cisco ASA firewalls, VPN concentrators, and even identity providers like Okta if they are configured to use RADIUS in PAP mode for MFA.

The most dangerous aspect of this vulnerability is that it is protocol-level. It does not matter if the vendor implemented the code perfectly; the protocol itself is fundamentally flawed. If you are on an engagement and see RADIUS traffic, check if the Message-Authenticator attribute is present. If it is missing, the device is likely vulnerable to simpler forms of packet manipulation. If it is present, the device is still susceptible to the Blast-RADIUS collision attack unless the implementation is specifically hardened against it.

The Path to Remediation

Defenders have a clear path forward, though it is not an overnight fix. The long-term solution is to move away from RADIUS over UDP entirely. The IETF is currently working on standardizing RADIUS over TLS, which provides the necessary encryption and integrity protections that UDP lacks.

In the short term, ensure that all RADIUS implementations are configured to require the Message-Authenticator attribute. This attribute uses HMAC-MD5, which is not vulnerable to the same collision attacks as the standard MD5 authenticator. However, this is only effective if the client and server are configured to strictly verify the attribute on every packet.

If you are auditing a network, look for the presence of this attribute in your packet captures. If you don't see it, you have found a significant gap in the organization's security posture. The era of trusting RADIUS over UDP is over. It is time to treat internal network authentication with the same level of scrutiny as any other public-facing service.