Basics on Blast-RADIUS

Blast-RADIUS is a security vulnerability that affects the RADIUS protocol according to RFC 2865. It allows a man-in-the-middle attacker between the RADIUS client and server to forge a valid access-accept message in response to an authentication request that has actually failed. This forgery allows the attacker to gain access to network devices and services without having to guess or force passwords and shared secrets. The attacker inserts a malicious attribute into a request that causes a collision between the authentication information in the valid server response and the attacker's desired forgery. This allows the attacker to convert a rejection into an acceptance and add arbitrary protocol attributes. However, the attacker does not learn any user credentials. The vulnerability was described in CVE-2024-3596.

Specifically, there is an attack on the MD5 signature of the response authenticator through collision calculation. The attack represents a protocol vulnerability and therefore affects all RADIUS implementations that do not use EAP authentication methods and work unencrypted via UDP. Specifically, the Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP) methods are affected.

Figure 1: Figure 1: Blast-RADIUS attack on a RADIUS authentication with the PAP method.

If transport encryption with TLS or DTLS cannot be used directly, the optional RADIUS attribute "Message-Authenticator" described in RFC 2869 can be used as a workaround.

This calculates an HMAC-MD5 checksum for the entire RADIUS packet. Packets that do not pass this integrity check must be silently discarded. HMAC-MD5 checksums cannot be falsified without the shared secret according to the current status.

The attack would be impossible if valid message authenticator attributes were required in all packets. However, this attribute is only mandatory for the EAP authentication methods, but not for PAP and CHAP. Even RFC 5080 only defines a "SHOULD".

How to check for vulnerabilities?

To check if your implementation is vulnerable, it is possible to capture packets between your RADIUS server and your RADIUS clients and filter them based on affected protocol characteristics. We can capture packets with ProfiShark or IOTA, pre-filter IOTA based on the RADIUS protocol, and analyze them with Wireshark. We need to capture RADIUS packets between RADIUS clients and Servers, for example, in inline mode, as shown here in Figure 2. 

Figure 2: Positioning IOTA or ProfiShark between RADIUS-Client (Switch) and RADIUS-Server.

Capture with ProfiShark

In ProfiShark Manager, we need to set ProfiShark to inline Mode (Span Mode box is unchecked) in Network Ports tab (Figure 3) and integrate it inline into our network (Figure 2).

Figure 3: Disable SPAN Mode in ProfiShark Manager to integrate ProfiShark in-line between RADIUS-Client and RADIUS-Server.

Next, in the Capture tab, we set our capture directory as needed, and start the capture via the Start Capture button, until we get enough data.

Figure 4: Set the capture directory and start capture in ProfiShark Manager.

Capture with IOTA

First, we make sure the IOTA's capture interface is set to in-line mode on the IOTA management interface's Capture > Interface Configuration page.

Figure 5: Set Port Control to Inline Mode.

Then, we integrate IOTA in-line into our production network, and start capturing, either by pressing the physical button on the device, or the Start Capture button on the Capture > Capture Control page.

Figure 6: Start the capture via the "Start Capture" button on the "Capture Control" page.

Now, we can filter on the RADIUS protocol via an application or protocol stack filter. The easiest way to do this is to filter on the “APPLICATION” attribute with the “RADIUS” value, as we can see in Figure 7, to only get RADIUS packets. Another option is to filter by “PROTOCOL_STACK”, with the value “Ethernet | IPv4 | UDP | RADIUS”.

Figure 7: Filter on RADIUS packets.

After filtering on the correct protocol, we can proceed to the bottom of the Overview dashboard until we reach the list of flows. Now, we need to select the flow we would like to analyze further and click the download button on the left side.

Figure 8: List of flows available for downloading

Analyzing for vulnerable implementations

Wireshark, for example, can be used to check whether RADIUS requests contain vulnerable attributes. First, we need to open our PCAPNG files located in the directory we configured earlier in ProfiShark Manager, or in the folder we downloaded them in from IOTA. Now, we need a display filter to get RADIUS Access-Requests (Code 1), Access-Accepts (Code 2), Access-Rejects (Code 3), and Access-Challenges (Code 11) without EAP methods or RADIUS messages with “Message-Authenticator” attribute value pair, because they are not affected by this vulnerability. This leads us to display filter "(radius.code in {1,2,3,11}) and not (radius.Message_Authenticator or eap)", as shown in Figure 9. As a result, we only get RADIUS packets affected by this protocol vulnerability. We can see source IP addresses of products affected.

Figure 9: Screenshot of a display filter in Wireshark for potentially vulnerable RADIUS packets.

As an example of a packet with an implemented workaround with “Message-Authenticator” attribute value pair, we can take a look at Figure 10 which implements it.

Figure 10: Screenshot from Wireshark of a RADIUS access request with message authenticator attribute/value pair. In this case, it is also a non-vulnerable EAP authentication.

Conclusion

IOTA and ProfiShark can help us easily gather packet-level data with high precision from our RADIUS packets and analyze them. Wireshark supports us in analyzing gathered data efficiently by using the display filter shown above to quickly filter on vulnerable RADIUS implementations.
As a workaround for the Blast-RADIUS attack, it is possible to use a “Message-Authenticator” attribute value pair or encrypt RADIUS packets via TLS transport encryption with RadSec or IPSec on the way from the RADIUS client to the RADIUS server.