University and Big Tech cybersecurity experts have uncovered a vulnerability in a common client-server network protocol that allows spies to potentially bypass user authentication through 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 not so easy to fix — attackers could theoretically gain access to network devices and services, without needing to receive credentials. This really requires, on a practical level, MITM to manage one’s network traffic and perform fast hash cracking.
Dubbed Blast RADIUS by researchers at 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 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 that it’s not all that simple: “Such access to RADIUS traffic can be accomplished through a variety of mechanisms. Although sending RADIUS/UDP over the open Internet is not recommended, it is still known to happen in practice. For internal network traffic, an attacker can initially compromise a portion of a corporate network.
“Even if RADIUS traffic is restricted to a secure part of an internal network, configuration or routing errors can inadvertently expose that traffic. An attacker with partial network access may be able to use 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 introduced in the 1990s and is still used in networks today. The Blast RADIUS flaw is believed to affect RADIUS implementations that use PAP, CHAP, MS-CHAPv2, and other non-EAP authentication methods. IPSec, TLS, 802.1x, Eduroam and OpenRoaming are considered secure.
“The RADIUS protocol is a foundational element of most network access systems around the world. As of July 9, almost all of these systems are no longer secure,” said Alan DeKock, 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 ISPs, enterprises and most cloud identity providers are likely to be affected by this issue.”
Blast RADIUS depends on how RADIUS clients and servers handle authentication requests, and involves performing collision attacks against the MD5 hash function. MD5 has apparently been broken since the 2000s, although the Blast RADIUS team says their abuse of the algorithm to exploit the RADIUS protocol vulnerability “is more sophisticated than just applying an old MD5 collision attack.” They say their approach is superior in terms of speed and scale.
As we pointed out, a successful Blast RADIUS attack involves someone manipulating the victim’s client-server RADIUS traffic to authenticate 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 type of attack is largely useful for someone who already has a network presence and wants to penetrate deeper.
How Blast RADIUS works
This will be a simplified explanation, and for those who want the full story, a white paper [PDF] is available from the vulnerability’s branded website.
The Blast RADIUS exploit starts with an attacker trying to authenticate to a client using whatever username and password combination they want – 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, signaling that the user is allowed to log on. Of course, in this case the server won’t because the credits are wrong – instead it will return an Access Denied packet.
To somewhat protect client-server communications from spoofing, 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, a shared secret, and more data in the response.
That way, when the client receives the server’s response, the client can use its Request Authenticator value and shared secret and data in the response to verify that the server has 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 undermine MITM attacks.
From the technical document … Illustrated instruction manual. 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 Blast RADIUS MITM happens.
Snoop can intercept the client’s access request and its arbitrary authentication request 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 intercept again and forging to convert the server’s response into a valid Forged Access-Accept message for the client.
This is done using a hash collision attack with a chosen MD5 prefix, based on earlier work by Mark Stevens and othersand exploiting the fact that carefully crafted garbage data added to a proxy configuration attribute in the server access request message by the attacker is included in the server’s access denial 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 payload and thus, through the collision attack, the hashes so that what the attacker sends to the client matches expectations to the client.
As for the client, it receives a valid access-accept response from its server and grants access to the attacker.
According to Cloudflare’s commentary, typically the attack should take less than five minutes to work on most RADIUS sets in the field, taking into account the standard client timeout tolerance. Most devices tolerate a wait of between 30 and 60 seconds, and in theory well-resourced hackers could use cloud computing platforms to speed up the exploit.
Mitigation strategies
The team behind the research told us that the makers of RADIUS authentication stacks have developed updates to thwart exploits of this protocol-level weakness—which was apparently disclosed in February, even though people had known about it for some time the security pitfalls of Access-Request exchanges.
Judging by the following boffins note, you should be looking for and installing updates for your deployments:
We’ve been told that the best mitigation for a client-server RADIUS implementation is to implement RADIUS over TLS (RadSec) to protect RADIUS packets in a heavily encrypted stream from abuse. See the vuln website for more details and mitigations. ®
