RADIUS networking protocol blasted into submission through MD5-based flaw

Cybersecurity experts at universities and Big Tech have disclosed a vulnerability in a common client-server networking protocol that allows snoops to potentially bypass user authentication via man-in-the-middle (MITM) attacks.

If the vulnerability, rated 7.5 out of 10 on the CVSS severity scale and tracked as CVE-2024-3596, is exploited – and it’s not that easy to pull off – attackers could theoretically access to network devices and services without needing to obtain any credentials. It does require, on a practical level, MITM’ing someone’s network traffic and performing some rapid hash cracking.

Dubbed Blast RADIUS by researchers at Cloudflare, Microsoft, UC San Diego, CWI Amsterdam, and BastionZero, you can probably guess it affects the RADIUS networking protocol. Essentially, the flaw allows someone to log into a client device that relies on a remote RADIUS server to perform the authentication check – without the correct credentials.

If you’re wondering how this affects you, the team notes that:

They go on to say it’s not all plain sailing, though: “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.

“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.”

Background

The Remote Authentication Dial-In User Service (RADIUS) protocol was drummed up in the 1990s and is still used in networks today. The Blast RADIUS flaw is understood to affect RADIUS deployments that use PAP, CHAP, MS-CHAPv2, and other non-EAP authentication methods. IPSec, TLS, 802.1x, Eduroam, and OpenRoaming are all considered safe.

“The RADIUS protocol is a foundational element of most network access systems worldwide. As of July 9, nearly all of these systems are no longer secure,” Alan DeKok, CEO of InkBridge Networks, claimed. 

“The discovery of the Blast RADIUS issue means that network technicians must install firmware upgrades on every device involved in network security, identity, and authentication. We believe that internet service providers, enterprises, and most cloud identity providers are likely to be affected by this issue.”

Blast RADIUS hinges on the way RADIUS clients and servers handle authentication requests, and involves performing collision attacks against the MD5 hashing function. MD5 has been demonstrably broken since the 2000s, though the Blast RADIUS team say their abuse of the algorithm to exploit the RADIUS protocol vulnerability “is more complex than simply applying an old MD5 collision attack.” They say their approach is better in terms of speed and scale.

As we indicated, a successful Blast RADIUS attack involves someone manipulating a victim’s client-server RADIUS traffic to authenticate themselves to one of the target’s clients – such as a router – to cause further mischief and mayhem, all without the need for a valid password. Given the hurdles involved, this sort of attack is largely of use to someone who already has a presence in a network and wants to drill in deeper.

How Blast RADIUS works

This will be a simplified explanation, and for those who want the full story, a technical paper [PDF] is available from the vulnerability’s branded website.

Blast RADIUS exploitation begins with an attacker trying to authenticate themselves to a client using whatever username and password combo they want – it doesn’t matter, it doesn’t need to work.

The client then contacts its RADIUS server over the network to perform the actual authentication using an Access-Request message. If the server determines the presented credentials are correct, it sends back an Access-Accept packet to the client, signaling the user should be allowed to login. Of course, in this instance, the server won’t do so because the creds are wrong – it will instead return an Access-Denied packet.

To somewhat protect the communications between the client and server from impersonation, they have a shared secret. When the client sends its Access-Request to the server, the client includes a 16-byte random value called the Request Authenticator, and when the server responds, the server includes a Response Authenticator value that is computed using the client’s random Request Authenticator, the shared secret, and other data in the reply.

Thus when the client receives the server’s response, the client can use its Request Authenticator value and the shared secret and data in the reply to check that the server computed and sent the correct Response Authenticator with its response. If someone tries to impersonate the server and doesn’t know the secret, they can’t send the right response, and the client can ignore it. This should ideally undermine MITM attacks.

Let’s rewind to the client trying to authenticate someone who doesn’t know the correct credentials. Here’s where the Blast RADIUS MITM happens.

The snoop can intercept the client’s Access-Request and its random Request Authenticator value and manipulate its data so that when this altered message is sent by the attacker to the server, the server replies with an Access-Denied message that the attacker can again intercept and tamper with to convert the server response into a valid forged Access-Accept message for the client.

This is done using an MD5 chosen-prefix hash collision attack based on earlier work by Marc Stevens et al, and exploiting the fact that carefully crafted garbage data added to a proxy configuration attribute in the Access-Request message to the server by the attacker is included in the server’s Access-Denied reply. With a little cryptographic dance, it’s possible to create a forged Access-Accept response that is valid for the client’s Request Authenticator value but without knowing the shared secret.

This double interception and manipulation is needed because the attacker doesn’t know the secret but can control the contents of the message payloads and thus, through the collision attack, the hashes so that what the attacker sends the client matches the client’s expectations.

As far as the client is concerned, it receives a valid Access-Accept response from its server, and grants access to the attacker.

According to Cloudflare’s write-up, typically the attack has to be carried out in under five minutes to work on most RADIUS kit in the field, accounting for the standard client timeout tolerance. Most devices tolerate timeouts of between 30 and 60 seconds, and theoretically, well-resourced attackers could make use of cloud computing platforms to speed up exploitation.

Mitigation strategies

We’re told by the team behind the research that the makers of RADIUS authentication stacks have developed updates to thwart exploitation of this protocol-level weakness – which was apparently uncovered in February though folks have known for a while the security pitfalls of Access-Request exchanges.

Judging by the boffins’ note as follows, you should look out for and install updates for your deployments:

The best mitigation for client-server RADIUS deployments, we’re told, is to implement RADIUS over TLS (RadSec) to protect RADIUS packets in a strongly encrypted stream from miscreants. See the vuln’s website for more details and mitigations. ®