Cybersecurity experts from universities and major technology companies have discovered a vulnerability in a widely used client-server network protocol that could allow hackers to 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, were exploited—and that’s not easy—attackers could theoretically gain access to network devices and services without having to obtain credentials. In practice, all it would require is MITMing someone’s network traffic and doing some quick hash cracking.
Dubbed Blast RADIUS by researchers from Cloudflare, Microsoft, UC San Diego, CWI Amsterdam, and BastionZero, you can probably guess that it affects the RADIUS networking protocol. Essentially, the flaw allows someone to log in to a client device that relies on a third-party RADIUS server to perform its authentication check – without the proper credentials.
If you’re wondering how this will affect you, the team notes the following:
They go on to say that it’s not all plain sailing: “Such access to RADIUS traffic can occur via several mechanisms. While sending RADIUS/UDP over the open Internet is discouraged, it has been known to still happen in practice. For internal network traffic, the attacker may initially compromise part of a corporate network.
“Even if RADIUS traffic is restricted to a protected portion of an internal network, configuration or routing errors can inadvertently expose this traffic. An attacker with partial network access could abuse DHCP or other mechanisms to force victim devices to send traffic outside a dedicated VPN.”
Background
The Remote Authentication Dial-In User Service (RADIUS) protocol was invented in the 1990s and is still in use in networks today. The Blast RADIUS vulnerability would affect RADIUS implementations that use PAP, CHAP, MS-CHAPv2, and other non-EAP authentication methods. IPSec, TLS, 802.1x, Eduroam, and OpenRoaming are all considered secure.
“The RADIUS protocol is a fundamental element of most network access systems worldwide. As of July 9, nearly all of these systems will no longer be secure,” said Alan DeKok, CEO of InkBridge Networks.
“The discovery of the Blast RADIUS vulnerability means that network engineers need to install firmware upgrades on every device involved in network security, identity, and authentication. We believe that ISPs, enterprises, and most cloud identity providers are likely to be affected by this issue.”
Blast RADIUS refactors how RADIUS clients and servers process authentication requests, and involves performing collision attacks on the MD5 hash function. MD5 has been demonstrably broken since the 2000s, though the Blast RADIUS team says their abuse of the algorithm to exploit the vulnerability in the RADIUS protocol is “more complex than simply running a legacy MD5 collision attack.” They say their approach is superior in terms of speed and scale.
As we’ve mentioned, 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 – in order to cause even more havoc and chaos, all without needing a valid password. Given the obstacles involved, this type of attack is most useful to someone who is already present in a network and wants to dig deeper.
How Blast RADIUS Works
This will be a simplified explanation, and for those who want the full story, a technical document [PDF] is available on the vulnerability website.
Exploitation of Blast RADIUS starts with an attacker trying to authenticate to a client using a random username and password combination. It doesn’t matter, it doesn’t have 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, indicating that the user is allowed to log in. In this case, of course, the server does not do so because the credentials are incorrect. Instead, it sends back an Access-Denied packet.
To protect the communication between the client and server somewhat from impersonation, they have a shared secret. When the client sends its Access-Request to the server, the client adds a random 16-byte value, the Request Authenticator, and when the server responds, the server adds 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, the client can use its Request Authenticator value and the shared secret and data in the response 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 won’t be able to send the correct response and the client can ignore it. Ideally, this should undermine MITM attacks.
From the technical document… Illustrated Guide to Exploitation. Click to enlarge
Let’s go back to the client trying to authenticate someone who doesn’t have the right credentials. This is where the Blast RADIUS MITM happens.
The snooper can intercept the client’s Access-Request and the arbitrary Request Authenticator value and manipulate the data so that when this modified message is sent by the attacker to the server, the server responds with an Access-Denied message. The attacker can then intercept this message again and manipulate it 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 previous work by Marc Stevens and alland exploit the fact that carefully crafted garbage data added by the attacker to a proxy configuration attribute in the Access-Request message to the server 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 contents of the message payloads and thus, via the collision attack, the hashes, so that what the attacker sends to the client matches what the client expects.
The client receives a valid Access-Accept response from its server and grants the attacker access.
According to Cloudflare’s write-up, the attack would typically need to be executed in less than five minutes to work on most RADIUS kits in the field, taking into account standard client timeout tolerance. Most devices tolerate timeouts of between 30 and 60 seconds, and attackers with sufficient resources could theoretically leverage cloud computing platforms to accelerate exploitation.
Mitigation Strategies
The research team told us that the RADIUS authentication stack authors have developed updates to prevent exploitation of this protocol-level vulnerability. This vulnerability was apparently discovered in February, but people have been aware of the security risks of Access-Request exchanges for some time.
Judging from the scientists’ comment below, you should pay attention to and install updates for your deployments:
The best mitigation for client-server RADIUS implementations, we are told, is to implement RADIUS over TLS (RadSec) to protect RADIUS packets in a strongly encrypted stream from attackers. See the vulnerability website for more details and mitigations. ®