Summary

In February 2024 University of California San Diego researchers and their partners reported a vulnerability discovered in the RADIUS protocol to the CERT and IETF. The RADIUS protocol vulnerability was later named BlastRADIUS. The vulnerability allows the attacker to alter RADIUS messages between the RADIUS server and client so that for example a rejected authentication can be turned into accepted authentication. Utilising the vulnerability requires that the attacker is able replace the original requests and replies between RADIUS client and server with the attacker’s content. Only the RADIUS messages, which do not contain message authenticator, or where the RADIUS client or server is not verifying message authenticator properly, are vulnerable.

Radiator Software has been working since February together with the researchers and other RADIUS server implementers to implement the identified fixes for RADIUS protocol in Radiator. This work and fixes have been under embargo until July 9th 2024 12:00am UTC. The fixes for RADIUS protocol have been implemented in the Radiator v4.29 released now after the embargo has ended.

Affected Radiator versions

Since this is a recently discovered RADIUS protocol vulnerability, all Radiator versions up until version 4.29 are affected.

Affected Radiator configurations and deployments

The RADIUS server deployments, which send and receive RADIUS requests without message authenticator or RadSec (RADIUS over TLS) over untrusted networks, are the most vulnerable for abuse. Enterprise Wi-Fi (EAP) authentication is using message authenticator in all messages by default so in those networks, the effect of the vulnerability depends if the RADIUS client implementation (e.g. in a Wi-Fi controller) is verifying the message authenticator properly. In addition to the RADIUS server updates, also RADIUS clients and client software may need to be updated.

As Radiator implements the RADIUS protocol all Radiator configurations and deployments using RADIUS protocol without requiring Message Authenticator or RadSec (RADIUS over TLS) are affected by this vulnerability.

Mitigation

Radiator Software strongly recommends upgrading Radiator to the latest version to get all the improvements and fixes to the vulnerability. In addition to upgrading Radiator, the Message-Authenticator requirement instructions should also be followed.

Configuring Message-Authenticator requirement

Radiator version 4.10 (2012) or newer can be configured to require a Message-Authenticator from a RADIUS client by adding RequireMessageAuthenticator to the Client configuration. For example:

<Client 192.0.2.42>
     Identifier CLIENT-IPV4-192.0.2.42
     Secret 6m9TXQTjLdH5BbgT
     RequireMessageAuthenticator
</Client>

Please note that configuring RequireMessageAuthenticator will require the Message-Authenticator to be present in the Access-Request and does not accept requests without it.

A legacy RADIUS client, which is not able, or configured, to send Message-Authenticator is not able to connect with Radiator after this requirement. The RADIUS client should be configured to send Message-Authenticator in its requests and require Message-Authenticator in the replies. If only Radiator is configured to use Message-Authenticator but RADIUS client does not require it, an attacker can drop the Message-Authenticator from the reply to Access-Request and modify the contents of the reply.

By default Radiator proxies and responds with Message-Authenticator to all messages with Message-Authenticator already present in them, but accepts also requests without the Message-Authenticator for compatibility and interoperability reasons.

If your configuration uses SQL database to specify clients in addition to (or instead of) the Radiator configuration by utilising the ClientListSQL, please see ClientListSQL part of Radiator AAA reference manual. See documentation subsections GetClientQuery and ClientColumnDef for more detailed instructions.

Requiring Message-Authenticator from RADIUS proxies or servers

Radiator v4.29 adds RequireMessageAuthenticator configuration directive for RADIUS based AuthBys such as AuthBy RADIUS, ROUNDROBIN and HASHBALANCE. With RequireMessageAuthenticator enabled, the AuthBy only accepts responses to Access-Requests that have a Message-Authenticator attribute. Radiator by default adds Message-Authenticator to outgoing Access-Requests.

<AuthBy RADIUS>
     Identifier AUTHBY-RADIUS-PROXIES
     Secret 9iLeKAnBP8e8oMhb
     Asynchronous
     Retries 1
     RetryTimeout 3
     FailureBackoffTime 5
     # Requires Message-Authenticator from all RADIUS proxies/servers in this AuthBy
     RequireMessageAuthenticator

     <Host 192.0.2.111>
          # RequireMessageAuthenticator can also be required per host
          #RequireMessageAuthenticator
          AuthPort 1812
          AcctPort 1813
     </Host>

     <Host 192.0.2.112>
          # RequireMessageAuthenticator can also be required per host
          #RequireMessageAuthenticator
          AuthPort 1812
          AcctPort 1813
     </Host>       
</AuthBy>

Requiring Message-Authenticator in requests with Proxy-State attribute

Radiator v4.29 introduces an additional configuration directive, LimitProxyState, which can be added to NAS RADIUS client definitions to require a valid Message-Authenticator in all requests, which contain the Proxy-State attribute used in the BlastRADIUS attack. This allows requests without Message-Authenticator (e.g. RADIUS client does not support it) to be received, but prevents the BlastRADIUS attack by not accepting requests with Proxy-State included in them. This configuration directive should only be used for NAS RADIUS clients, e.g network equipment such as switches, Wi-Fi controllers etc. It should not be used for clients, which are RADIUS servers or proxies. An example of the configuration is below:

<Client 192.0.2.42>
     Identifier CLIENT-IPV4-192.0.2.42
     Secret 6m9TXQTjLdH5BbgT
     LimitProxyState
</Client>

Please note that RequireMessageAuthenticator should not be set together with LimitProxyState because RequireMessageAuthenticator will prevent requests without Message-Authenticator altogether. LimitProxyState is intended for use cases where client can not be configured to send Message-Authenticator.

Limiting unencrypted RADIUS use only to management networks

To utilise the vulnerability the attacker needs to get in between RADIUS servers or between RADIUS server and RADIUS client. Separating unencrypted RADIUS traffic into a management network and reducing the routing distance between the server and clients makes it more difficult to perform the actual attack.

Unencrypted RADIUS over public networks exposes the RADIUS requests for the well-resourced attackers to abuse and should be avoided.

Securing RADIUS messages with TLS or VPN

The BlastRADIUS attack only works on unencrypted RADIUS traffic over UDP or TCP. The RADIUS traffic can already be secured with RADIUS over TLS (RadSec, RFC 6614) or with VPN solutions if RadSec support is not available.

Radiator is the first RADIUS server ever (v3.12, 2005) to implement RADIUS over TLS (RadSec, RFC 6614), which was an IETF draft originally developed in cooperation between eduroam and Radiator implementers. Radiator Software continues to participate in developing the RADIUS over TLS specification in the IETF as well as implementing the latest features into the Radiator itself.

Radiator Software strongly recommends migrating from unencrypted RADIUS to RADIUS over TLS. While requiring Message-Authenticator mitigates the vulnerability, the effort needed to configure these and test the changes, clients and servers for interoperability may be greater than configuring and deploying RADIUS over TLS to secure both the protocol and privacy of the information transferred in RADIUS request attributes.vulnerability,

Questions and answers

Is my multi-factor authentication (MFA/2FA) affected?

If your multi-factor authentication is using RADIUS, it is likely to be affected. The exposure for the vulnerability depends on the RADIUS clients, servers and the attacker’s access to the network in between them. If your systems are for example doing MFA authentication with unencrypted RADIUS over the public Internet to a multi-factor authentication service provider your authentication is exposed and vulnerable.

Is my enterprise Wi-Fi (WPA2/WPA3 Enterprise) affected?

No. Enterprise Wi-Fi utilises EAP authentication over RADIUS. The EAP authentication already mandates Message-Authenticator in all requests.

Is eduroam or OpenRoaming affected?

No. Both eduroam and OpenRoaming are utilising EAP authentication like enterprise Wi-Fi (WPA2/WPA3) networks. OpenRoaming additionally mandates RadSec (RADIUS over TLS) and it is also supported in eduroam.

Is my VPN solution affected?

Similarly as with multi-factor authentication if your VPN endpoint is using unencrypted RADIUS for authenticating the VPN connection credentials from the RADIUS server or service, this vulnerability could be used in the worst case to allow an attacker to get a successful VPN connection to your network. Those VPN solutions which are using EAP authentication with RADIUS servers are not affected.

Is roam.fi roaming service affected?

The roam.fi roaming service is similar to eduroam and OpenRoaming utilising Enterprise Wi-Fi EAP authentication so it is not affected. Additionally roam.fi roaming service also supports RadSec (RADIUS over TLS) and it is strongly recommended that the roam.fi member organisations would migrate in using RadSec, when they have the RadSec connection capability themselves. The service will be updated to utilise Radiator v4.29 as soon as it becomes generally available.

Is Radiator Auth.Fi RADIUS as a service affected?

The Radiator Auth.Fi EAP authentication including both username-password and client certificate authentication is not affected.

The captive portal and MAC address authentication used for guest network functionality is affected if unencrypted RADIUS connections are used. The Radiator Auth.Fi already supports RadSec client connections for securing the RADIUS traffic and it is strongly recommended that customers who have the ability to use RadSec, will switch to using RadSec instead of unencrypted RADIUS.

The Radiator Auth.Fi Radiator will also be updated to utilise Radiator v4.29 as soon as it is released and that will enable additional options for adjusting Message-Authenticator settings for unencrypted RADIUS.

Is my ISP, fixed line subscriber configuration provisioning or IP address allocation RADIUS solution affected?

As these solutions are usually based on unencrypted RADIUS they are affected, but usually the RADIUS traffic is in these cases separated into management networks. If an attacker has access to a management network, the attacker is more likely to focus on more interesting targets than fabricating RADIUS requests and replies. The mitigation options work also in these networks, but extra attention should be given to testing, because the mitigation requires interoperable functionality from both RADIUS servers and clients.

How can I update Radiator?

If you have an active support contract for Radiator, you can get Radiator updates including the new Radiator v4.29 release from the Radiator download and repository page at https://radiatorsoftware.com/downloads/. If you are not sure or have an older license without a support contract, please contact sales@radiatorsoftware.com to renew your support.

Is my RADIUS configuration affected?

Radiator Software email support is able to answer questions and support you in case you want to evaluate the vulnerability’s effect on your deployment and use case. If you have active support, you can contact Radiator support at support@radiatorsoftware.com. If you are not sure or have an older license without a support contract or want to engage in larger scale configuration evaluation or upgrade, please contact sales@radiatorsoftware.com to renew your support or discuss the scope for Radiator expert services.

For more information about the vulnerability

BlastRADIUS WWW site: https://www.blastradius.fail/

BlastRADIUS paper: https://www.blastradius.fail/pdf/radius.pdf

CERT CVE: https://www.cve.org/CVERecord?id=CVE-2024-3596

CERT Coordination Center: https://kb.cert.org/vuls/id/456537 (vendor status for vulnerability fixes)

Radiator revision history (v4.29): https://radiatorsoftware.com/products/radiator/history/

Security Notice: BlastRADIUS protocol vulnerability (CVE-2024-3596) fixed in Radiator v4.29