Cybersecurity experts from universities and major technology companies have revealed a vulnerability in a common client-server network protocol that allows eavesdroppers 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 listed as CVE-2024-3596, is exploited – and it’s not that easy to do – attackers could theoretically gain access to network devices and services without needing to obtain credentials. In practical terms, this requires hijacking a user’s network traffic and performing a quick hash crack.
Dubbed Blast RADIUS by researchers from Cloudflare, Microsoft, UC San Diego, CWI Amsterdam, and BastionZero, you can probably guess that it affects the RADIUS network protocol. Essentially, the flaw allows someone to connect to 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 add, however, that not everything is so simple: “Such access to RADIUS traffic can occur via different mechanisms. Although sending RADIUS/UDP over the open Internet is discouraged, it still happens in practice. For internal network traffic, the attacker can initially compromise part of a corporate network.
“Even if RADIUS traffic is confined to a protected portion of an internal network, configuration or routing errors can unintentionally expose this traffic. An attacker with partial access to the network may be able to exploit DHCP or other mechanisms to trick victim devices into sending traffic outside of a dedicated VPN.”
Background
The Remote Authentication Dial-In User Service (RADIUS) protocol was invented in the 1990s and is still used in networks today. Blast’s RADIUS flaw is believed 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.
“RADIUS is a fundamental part of most network access systems around the world. As of July 9, nearly all of these systems are no longer secure,” said Alan DeKok, CEO of InkBridge Networks.
“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 relies on how RADIUS clients and servers handle authentication requests and involves performing collision attacks against the MD5 hash function. MD5 has been demonstrably broken since the 2000s, though the Blast RADIUS team claims that their abuse of the algorithm to exploit the RADIUS vulnerability “is more complex than simply applying an old MD5 collision attack.” They claim their approach is better in terms of speed and scale.
As we’ve discussed, a successful Blast RADIUS attack involves someone manipulating a victim’s client-server RADIUS traffic to authenticate to one of the target’s clients (a router, for example) in order to cause further damage and chaos, all without requiring a valid password. Given the obstacles involved, this type of attack is most useful to someone who is already on a network and wants to dig deeper.
How Blast RADIUS works
This will be a simplified explanation, and for those who want to know the full story, a technical paper (PDF) is available on the vulnerability website.
Blast RADIUS exploitation begins with an attacker attempting to authenticate to a client using a username and password combination of their choosing. 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 that the credentials presented are correct, it sends an Access-Accept packet back to the client, signaling that the user should be allowed to log in. Of course, in this case, the server will not do this because the credentials are incorrect. Instead, it will send an Access-Denied packet.
To somewhat protect the communications between the client and server from spoofing, they have a shared secret. When the client sends its access request to the server, it includes a random 16-byte value called a request authenticator, and when the server responds, it includes a response authenticator value that is calculated using the client’s random request authenticator, the shared secret, and other data in the response.
So when the client receives the response from the server, it can use its request authenticator value and the shared secret and response data to verify that the server calculated 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 correct response and the client can ignore it. This should ideally thwart MITM attacks.
Excerpt from the technical document … Illustrated operating guide. Click to enlarge
Let’s go back to the client trying to authenticate someone who doesn’t know the correct credentials. This is where the RADIUS MITM Blast occurs.
The eavesdropper can intercept the client’s access request and its random request authenticator value and manipulate its data so that when this modified message is sent by the attacker to the server, the server responds with an access denied message that the attacker can again intercept and forge to convert the server’s response into a valid forged access accept message for the client.
This is done using a chosen-prefix MD5 hash collision attack based on previous work by Marc Stevens and othersand exploiting the fact that carefully crafted junk data added to a proxy configuration attribute in the server access request message by the attacker is included in the server’s access denied response. With a bit of cryptographic dancing, it is 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 necessary because the attacker does not know the secret but can control the content of the message payloads and therefore, thanks to the collision attack, the hashes so that what the attacker sends to the client matches the latter’s expectations.
As for the client, it receives a valid access-accept response from its server and grants access to the attacker.
According to Cloudflare’s paper, the attack typically needs to be completed in less than five minutes to work on most RADIUS kits in the field, taking into account the standard client timeout tolerance. Most devices tolerate timeouts between 30 and 60 seconds, and theoretically, attackers with sufficient resources could use cloud computing platforms to speed up exploitation.
Mitigation strategies
The team behind the research tells us that the creators of the RADIUS authentication stacks have developed updates to thwart exploitation of this protocol weakness – which was apparently discovered in February, although people have known about the security pitfalls of access request exchanges for some time.
Judging by the following note from experts, you should check for and install updates for your deployments:
The best mitigation for client-server RADIUS deployments, we are told, is to implement RADIUS over TLS (RadSec) to protect RADIUS packets in a strongly encrypted stream from malicious actors. See the vulnerability website for more details and mitigations. ®