From hvn at open.com.au  Tue Jul  9 14:53:25 2024
From: hvn at open.com.au (Heikki Vatiainen)
Date: Tue, 9 Jul 2024 17:53:25 +0300
Subject: [RADIATOR-ANNOUNCE] Security Notice: BlastRADIUS protocol,
 vulnerability (CVE-2024-3596) fixed in Radiator v4.29
Message-ID: <27284a51-11fa-4cd9-a190-ee17a6a9557c@open.com.au>

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

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
---------------------------------------------

Requiring Message-Authenticator from RADIUS clients
---------------------------------------------------

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 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. This server configuration directive also does not work
alone as the RADIUS clients should be configured to use, require and
verify the Message-Authenticator as well.

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.


Requiring Message-Authenticator from RADIUS proxies or servers
--------------------------------------------------------------

Radiator v4.29 (2024) adds RequireMessageAuthenticator configuration
directive for RADIUS based AuthBys such as AuthBy RADIUS, ROUNDROBIN
and HASHBALANCE. With RequireMessageAuthenticator enabled, the AuthBy
only accepts requests with Message-Authenticator in the RADIUS
replies. Radiator by default adds Message-Authenticator to outgoing
messages.

<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>


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 neve(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 from
RADIUS client and servers 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.

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 at 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 at 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 at 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
Radiator revision history (v4.29):
https://radiatorsoftware.com/products/radiator/history/
This security notice:
https://radiatorsoftware.com/blastradius-vulnerability-fixed-in-radiator-v4-29/


-- 
Heikki Vatiainen
Radiator Software, makers of Radiator
Visit radiatorsoftware.com for Radiator AAA server software

From hvn at open.com.au  Tue Jul  9 14:54:49 2024
From: hvn at open.com.au (Heikki Vatiainen)
Date: Tue, 9 Jul 2024 17:54:49 +0300
Subject: [RADIATOR-ANNOUNCE] Radiator Version 4.29 released - major Radius
 protocol security fix, minor features, enhancements and bug fixes
Message-ID: <444d10e9-ef1f-4f7c-a28a-c9904a94e3a6@open.com.au>

We are pleased to announce the release of Radiator version 4.29
This version contains a major Radius protocol security fix, some new 
features, enhancements and bug fixes. See below for the details.

As usual, the new version is available to current licensees
and evaluators from:
https://radiatorsoftware.com/downloads/

Licensees with expired access contracts can renew at:
https://radiatorsoftware.com/renewal-order/

An extract from the history file
https://radiatorsoftware.com/products/radiator/history/ is below:

-----------------------------

Revision 4.29 (2024-07-09) major Radius protocol security fix, some new 
features, enhancements and bug fixes


       Selected compatibility notes, enhancements and fixes

Updates to address CVE-2024-3596 BlastRADIUS vulnerability in the RADIUS 
protocol. For the vulnerability details, see https://www.blastradius.fail

Support Ubuntu 24.04.


       Known caveats and other notes

TLSv1.3 remains disabled by default for TLS based EAP methods and Stream 
based classes, such as RadSec. TLSv1.3 testing reports are welcome.

EAP-FAST needs Net::SSLeay 1.94 or later to function correctly with 
OpenSSL 1.1.1 and later.


       Detailed changes

Add a new flag parameter LimitProxyState to Client clauses. This 
parameter allows dropping those requests from non-proxy clients that 
contain Proxy-State but do not contain Message-Authenticator. Ensure 
that ServeRADSEC drops requests with bad Message-Authenticator instead 
of just logging them. The upcoming Radius transport update by IETF's 
radext working group will remove the redundant signatures but keep them 
for the current transport profile. LimitProxyState addresses CVE-2024-3596.

Update RADIUS Message-Authenticator attribute handling. 
Message-Authenticator is always added as the first attribute in Radius 
messages. Message-Authenticator is now added automatically to replies to 
Access-Request messages and to Access-Request messages when they are 
proxied. New parameter RequireMessageAuthenticator is now available for 
AuthBy RADIUS and its subclasses. It can be set for all hosts in an 
AuthBy or host-by-host basis. This parameter requires a valid 
Message-Authenticator in proxy replies. A new configuration flag 
-no_message_authenticator is available in radpwtst to skip 
Message-Authenticator in Access-Requests. Most of the updates are based 
on the work currently done in the IETF's radext working group. Addresses 
CVE-2024-3596.

Discard unknown Diameter answers earlier in DiaPeer.pm. Simplify request 
sending in DiaPeer.pm.

Add new hooks in goodies: addresspool-statshook.pl for monitoring IP 
address allocator pool utilisation, and client-nas-identifier.pl and 
client-nas-identifier-2.pl to use together with a new configuration 
sample file client-nas-identifier.cfg. This file shows how to define 
Client clauses for clients behind NAT that are identified only by 
NAS-Identifier attribute.

Ansible playbooks in goodies updated to use FQCN. Minimum Ansible core 
version updated to README for Ubuntu 24.04 usage.

Add support for configuring SIGTRAN statistics clauses. SIGTRAN is 
supported by Radiator's SIM pack.

Test with Ubuntu 24.04. Add new VENDOR 6027 Force10 in the default 
Radius dictionary with attribute Force10-avpair. Also add VENDOR 674 
Dell (also known DellEMC) attribute Dell-AVpair.

Add VENDOR 12148 ELTEK attribute ELTEK-SP-UserID to the default RADIUS 
dictionary. Add values for ELTEK-SP-AdminLevel. The other ELTEK 
attributes were already present in the dictionary. Update VENDOR 30065 
Arista and VENDOR 16901 Mojo, also Arista, attributes.

Fix CEF AuthLog and AcctLog header format broken in releases 4.27 and 
4.28. Authentication log formatting in LogFormat.pm incorrectly logged 
ignored requests as rejected requests with CEF and JSON formats.

Add VENDOR 2007 Teldat attribute Teldat-Access-Level to Radius dictionary.

AuthBy LDAP2 now properly closes LDAP connection when group search 
experiences an LDAP error. This avoids errors in subsequent LDAP 
queries. Add similar checks to LDAP NMAS functions.


-- 
Heikki Vatiainen
Radiator Software, makers of Radiator
Visit radiatorsoftware.com for Radiator AAA server software