Blast-RADIUS Vulnerability: What is it and am I affected?
What is Blast-RADIUS?
As the name suggests it’s a vulnerability targeting the age-old and widely used RADIUS protocol. With CVE code 2024-3596, this new vulnerability aims to abuse the MD5 hash to modify a valid Access-Reject response to Access-Accept, thus, granting network access to an illegitimate user.
The vulnerability is still awaiting a detailed analysis from NIST as of the date of publishing this article. The recent updates can be found on the NIST website.
Let’s delve deeper into the facts by aligning with the basics and then moving onto the actual specifics of the attack with the first-hand information available.
What is RADIUS?
RADIUS is an acronym for Remote Authentication Dial-in User Service, a network protocol initially used to authenticate users of modem-based dial services. Today this is used to authenticate users to several applications that use the same authentication source.
The RFC specifications for the RADIUS protocol dictate that RADIUS:
- Is a UDP-based connectionless protocol that doesn’t use direct connections (opposite of TCP which guarantees proper delivery)
- Uses a hop-by-hop security model
- Is stateless
- Uses MD5 to keep up message integrity
- Provides over 50 attribute/value pairs with the ability to create vendor-specific pairs
- Supports the authentication-authorization-accounting model
Shortcomings of the RADIUS Protocol
Though RADIUS has been in use for more than thirty years there are a few hiccups one has to deal with.
- It uses UDP (User Datagram Protocol)
- RADIUS by default works on UDP which is a connection-less protocol that doesn’t guarantee delivery of all the packets in a transaction. For this reason it’s recommended to have supportive means to ensure proper delivery. RADIUS was designed with UDP to choose speed over quality delivery.
- The entire communication is not encrypted
- Only passwords are encrypted while the rest of the transactions are in clear text.
- Uses MD5 to protect message integrity which is collision-prone
- Most of the transactions are unencrypted which leads to severe integrity concerns. Though this issue could easily be sorted out with MD5 hashing algorithm, it is known to have its problems – collisions.
- Easy to crack shared secret that has 10 or fewer characters
- Shared secret should be sent by RADIUS client when it has to establish a connection with the RADIUS server. The secret is sent over as an MD5 hash. As MD5 already is weak it is easy for an attacker to crack it with a few trails.
What is the use of MD5 in RADIUS?
As touched upon in the previous section, MD5 maintains message integrity and password secrecy. Though there could be several scenarios in which MD5 is used in RADIUS, this section aims to explain only the below as it is important to know them to understand Blast-RADIUS vulnerability.
- To hash the response authenticator packet
- In Message-Authenticator attribute to hash the entire Access-Request packet
Hashing the Response Authenticator Packet
A RADIUS packet has the below structure:
As our discussion is around the Blast-RADIUS vulnerability it would be useful to concentrate on Authenticator value and keep the rest out of scope.
Authenticator has two types of values – Request authenticator and Response authenticator.
While request value has “Access-Request” and “Accounting Request” the response value has “Access-Accept”, “Access-Reject” and “Access-Challenge”. Request authenticator is any random value protected by a password, the Response authenticator is MD5 hash value of the parameters as shown below:
The Importance of the Message-Authenticator Attribute
Though access requests to a RADIUS server could be limited to certain IP ranges, it is easy for anybody to spoof. There could be problems if the IPs are dynamic as well. To alleviate this issue, it is recommended that the attribute Message-Authenticator be used when sending out Access-Request. Message-Authenticator is the MD5 hash value of Access-Request packet with shared secret as the key. This enables RADIUS server to accept Access-Request packets only from genuine clients that have proper Message-Authenticator value.
Why is MD5 Weak?
Every hashing attempt should produce a different output for every other input. If two different inputs produce the same output, it is said to be in collision.
The phenomenon of collision undermines a hashing algorithm and brings down its usage. MD5 is one such hashing algorithm.
Why is MD5 Still Used in RADIUS Though it is Considered Weak?
RADIUS still uses MD5 because hundreds of thousands of devices have implemented this protocol into their network since time immemorial. It is difficult and expensive to upgrade all of these devices to use a new protocol. Even though RadSec is a decade old, it is still not widely supported in NAS equipment!
How does EAP help RADIUS?
802.1X also known as Extensible Authentication Protocol is an authentication framework that’s mostly used by wireless networks. This protocol’s main purpose is to extend wired networks’ authentication to their wireless counterparts.
EAP secures RADIUS more than the simple PPP protocol. All the interactions to and from RADIUS server until the end user are encapsulated, which means it aids the RADIUS being a little more secretive.
Blast RADIUS vulnerability: what exactly happens here?
- Attacker enters a privileged username and incorrect password.
- The victim’s RADIUS client creates an Access-Request packet out of this network access request.
- Access-Request packets have Request-Authenticator attribute, which is a 16-byte random number protected by password. The password is hashed with MD5.
- The MITM adversary intercepts this request and calculates the MD5 collision data. This results in binary gibberish strings Reject-Gibberish and Accept-Gibberish such that MD5 (Access-Reject || Reject-Gibberish) is equal to MD5 (Access-Accept || Accept-Gibberish).
- The MD5 collision value is added to Access-Request with malicious intention as ‘Proxy-State’ attribute.
- The RADIUS server will reject the request as the password is incorrect by sending Access-Reject packet. The server response would be MD5(Access-Reject || Reject-Gibberish || SharedSecret). The attacker cannot verify the shared secret as they don’t have this information.
- When the response packet format matches the already predicted MD5(Access-Reject || Reject-Gibberish), the adversary replaces this with MD5 (Access-Accept || Accept-Gibberish) and the attacker has access to your network.
Should organizations be concerned about this?
In our opinion, most organizations do not need to be concerned, and here is why we feel that way.
Most RADIUS Authentications are not a target
Blast-RADIUS works because the Message-Authenticator attribute is missing in certain RADIUS workflows. EAP-TLS is not one of those workflows, so devices authenticating with this are not affected. However, RADIUS workflows that do not use the EAP protocol (Mac Authentication, Token-Based VPN Authentication, PPSK) are vulnerable to Blast-RADIUS.
The vast majority of RADIUS workflows are EAP-based, so it’s not likely that Blast RADIUS will apply to most of the devices using RADIUS authentication on your network. This is combined with the fact that it’s very difficult to perform the attack, which we will get into more below.
It’s difficult to perform the MITM
To be the MITM you have to intercept the traffic somewhere. You will have to either unplug your target’s router and put your own in between or just break into an ISP or any other data center. These things are quite hard to perform and seem to be nearly impossible.
If you were successful in putting yourself between the communication channel the next you need is a supercomputing power that can calculate MD5 hash used in Acess-Request/Access-Reject in a few seconds and then change it to an Access-Accept message by putting in the correct hash. This would need a bunch of GPU-accelerated cloud servers that if rented for 20 minutes would cost tens of thousands of dollars.
The attack seems quite possible if a piece of network equipment has a known remote code execution vulnerability. Another possibility is to mess around with low-level IP packets so the RADIUS client starts routing its traffic to you instead of the internet gateway/router.
The above scenarios will work if you are already in their network, either physically or virtually, but won’t your Incident Detection and Response swing into action?
Once you perform the MITM, it’s very hard to pull off MD5 abuse
The response time of RADIUS varies. It can be 10 seconds,24 seconds or up to the max of 30 seconds. You should be able to crack the MD5 collision within this time limit, which is luck-based, if you are unlucky you just wasted a bunch of money for nothing.
In our opinion, going to that length just so you can send a specific Access-Accept back to a wired/wireless controller/VPN doesn’t seem like something that would happen in the real world.
Final thoughts:
RADIUS has been in play from the initial phases of the Internet and still finds its usage in various networks. Thus, the user-friendliness of RADIUS should be well appreciated while calculating its weaknesses. A few supporting measures,as mentioned below, if implemented correctly can make the protocol sturdy.
Use EAP-TLS
EAP-TLS uses digital certificates for both the client and server authentication. Digital certificates work on the principle of asymmetric encryption and are the most phishing-resistant authentication method. By using this you have one less worry on the RADIUS requirement of having your passwords hashed with MD5!
Mandate Message-Authenticator attribute
For end-points not compatible with EAP-TLS (such as IoT devices) mandate that the Access-Request packets must contain Message-Authenticator attribute without which the RADIUS authentication fails. Doing this will ensure that only authorized devices send the access request.
Go for RadSec
RadSec sends RADIUS/TCP packets over TLS. As already known RADIUS in its inception form is with unreliable UDP, RadSec aims to concrete delivery with TCP in place over a secured TLS tunnel. Also, encapsulation with TLS covers for the insecurities of MD5 collision, this happens as a result of the entire RADIUS communication being done over TLS. The previous version of RADIUS without encryption (except for the passwords) made any MITM effort to be successful.
To get more information on RadSec visit our detailed blog.
