Hardening RADIUS Against the Blast RADIUS Attack (CVE-2024-3596)

Problem

RADIUS (Remote Authentication Dial-In User Service) has been the authentication backbone of enterprise networks for 30 years. It handles 802.1X port authentication, VPN authentication, Wi-Fi Enterprise (WPA2-Enterprise), network device management login, and dial-up access. Despite its age, RADIUS remains deeply embedded: virtually every managed switch, wireless access point, VPN concentrator, and network device supports it, and most enterprise networks still rely on it.

CVE-2024-3596, disclosed in July 2024 under the name “Blast RADIUS,” demonstrated that the core authentication security of RADIUS/UDP is broken. The vulnerability is in the fundamental protocol design, not an implementation bug:

RADIUS authenticates responses using an MD5-based Message Authenticator attribute that is keyed with the shared secret. Researchers demonstrated a chosen-prefix collision attack on MD5 that, when combined with the structure of RADIUS messages, allows a network attacker positioned between a RADIUS client (a switch or access point) and a RADIUS server to forge an Access-Accept response to any authentication attempt.

The attack works as follows:

1. An attacker intercepts a RADIUS Access-Request packet from a network device.
2. The attacker uses a chosen-prefix MD5 collision to craft a forged Access-Accept response with a valid authenticator.
3. The RADIUS client (the switch or AP) accepts the forged response as legitimate.
4. The user is granted access without the RADIUS server ever making an authentication decision.

The practical implication: an attacker on the network path between a managed switch and the RADIUS server — achievable via ARP spoofing, BGP injection on the management network, or compromise of intermediate network equipment — can bypass all RADIUS-based authentication entirely. Every 802.1X port, every VPN, every Wi-Fi network, every network device login that uses RADIUS/UDP is affected.

The fix requires either:

1. Enabling Message-Authenticator attribute on all packets — makes MD5 collision much harder by covering additional packet fields, but is a partial mitigation, not a complete fix
2. Migrating to RADIUS over TLS (RadSec, RFC 6614) — wraps RADIUS in a TLS session, eliminating the MD5 exposure entirely

The challenge is deployment scale. RADIUS is used everywhere and many devices support it only via legacy UDP. A complete migration requires assessing every RADIUS client and upgrading or replacing those that cannot support RadSec. The process is complex but necessary.

Target systems: any network using RADIUS for 802.1X, VPN, Wi-Fi Enterprise, or network device management; FreeRADIUS, Cisco ISE, Microsoft NPS, Aruba ClearPass, and all other RADIUS server implementations; all network devices that authenticate against RADIUS.

Threat Model

Adversary 1 — On-path attacker on management network. Access level: ARP spoofing or network device compromise on the management VLAN where RADIUS traffic flows. Objective: intercept 802.1X authentication attempts, forge Access-Accept responses, allow unauthorised devices onto the network without credentials.

Adversary 2 — Compromised intermediate network device. Access level: control of a managed switch, router, or VPN concentrator on the path between a RADIUS client and server. Objective: replay or forge RADIUS authentication responses to bypass network access control.

Adversary 3 — VPN authentication bypass. Access level: network position between VPN concentrators and the RADIUS server. Objective: forge Access-Accept for VPN connection attempts, allowing attacker-controlled endpoints to authenticate to the corporate VPN without valid credentials.

Adversary 4 — Network device management bypass. Access level: same network segment as managed switches/routers that use RADIUS for administrator login. Objective: forge RADIUS Accept for admin login attempts to gain management access to network infrastructure.

Without patching: any on-path attacker can forge RADIUS authentication. With RadSec: TLS protects the entire RADIUS session; MD5 collision attacks are irrelevant.

Configuration / Implementation

Step 1 — Assess your RADIUS exposure

# Identify RADIUS servers and clients in your environment
# Check which RADIUS implementations are deployed
freeradius -v 2>/dev/null | head -3
radiusd -v 2>/dev/null | head -3

# Check if Message-Authenticator is being sent/required
# In FreeRADIUS, grep the configuration
grep -r "require_message_authenticator\|Message-Authenticator" \
  /etc/freeradius/ /etc/raddb/ 2>/dev/null

# Check if RadSec (TLS) is configured
grep -r "tls\|radsec\|RadSec" \
  /etc/freeradius/ /etc/raddb/ 2>/dev/null | grep -v "^#"

# List active RADIUS clients that might be vulnerable
grep -r "client\s" /etc/freeradius/clients.conf /etc/raddb/clients.conf 2>/dev/null | \
  grep -v "^#"

Scan for RADIUS/UDP traffic on your management network:

# Capture RADIUS UDP traffic (ports 1812, 1813, 1645, 1646)
tcpdump -i any -n 'udp and (port 1812 or port 1813 or port 1645 or port 1646)' -c 100 -w /tmp/radius-capture.pcap

# Analyse captured traffic — check for Message-Authenticator attribute
# RADIUS attribute 80 = Message-Authenticator
tshark -r /tmp/radius-capture.pcap -Y "radius" -T fields \
  -e radius.code -e radius.id -e frame.time \
  -e radius.message_authenticator 2>/dev/null | head -20

Step 2 — Immediate mitigation: enforce Message-Authenticator

Before full RadSec migration, enforce Message-Authenticator on all packets. This raises the attack cost significantly:

FreeRADIUS:

# /etc/freeradius/3.0/radiusd.conf or sites-enabled/default

# Require Message-Authenticator on ALL Access-Request packets
# This is the primary short-term mitigation for Blast RADIUS
server default {
    listen {
        require_message_authenticator = yes
    }
}

# In clients.conf — require it from each client
client switch-01 {
    ipaddr = 10.0.1.10
    secret = "strong-shared-secret-here"
    require_message_authenticator = yes  # FreeRADIUS 3.2.3+
    # Or in FreeRADIUS 3.0.x:
    # limit { require_message_authenticator = yes }
}

# Apply and test
systemctl reload freeradius

# Verify the change takes effect
freeradius -X 2>&1 | grep -i "message.authenticator"

Microsoft NPS (Network Policy Server):

# PowerShell — configure NPS to require Message-Authenticator
# This requires Windows Server 2019 patch KB5040438 or later
Set-NpsRadiusClient -Name "Switch01" -RequireMessageAuthenticator $true

# Or via registry (check NPS vendor docs for current registry path)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\IAS" `
  -Name "RequireMessageAuthenticator" -Value 1

Step 3 — Deploy RADIUS over TLS (RadSec)

RadSec (RFC 6614) wraps RADIUS in TLS, completely eliminating the MD5 vulnerability. This requires both server and client support:

FreeRADIUS RadSec server configuration:

# /etc/freeradius/3.0/sites-enabled/tls

listen {
    type = auth+acct
    proto = tcp
    port = 2083    # Standard RadSec port
    
    tls {
        # Server certificate
        private_key_file = /etc/ssl/private/radius-server.key
        certificate_file = /etc/ssl/certs/radius-server.crt
        ca_file = /etc/ssl/certs/radius-ca.crt
        
        # Require valid client certificates
        require_client_cert = yes
        ca_path = /etc/ssl/certs/
        
        # TLS 1.2+ only
        tls_min_version = "1.2"
        
        # Strong cipher suites
        cipher_list = "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256"
        
        # Verify client certificate against CRL
        check_crl = yes
    }
}

# Accept RadSec clients
client radsec-client {
    ipaddr = 10.0.0.0/8
    proto = tls
    secret = "radsec"   # Shared secret is unused when using TLS
    shortname = radsec-clients
}

Network device configuration (example: Cisco IOS XE):

! Configure RadSec on Cisco IOS XE
! Requires IOS XE 17.3+

radius server RADSEC-SERVER
 address ipv4 10.0.0.10 auth-port 2083 acct-port 2083
 tls connectiontimeout 5
 tls watchdoginterval 30
 tls trustpoint radius-client-cert  ! Local certificate
 tls server-name radius.internal    ! Expected server cert CN
 key 0 radsec

! Use the RadSec server for 802.1X
aaa authentication dot1x default group RADSEC-GROUP

FreeRADIUS as a RadSec proxy (for devices that can’t do TLS directly):

If network devices don’t support RadSec, deploy a local RadSec proxy on the management network:

# /etc/freeradius/3.0/proxy.conf
# FreeRADIUS acting as a RadSec proxy
# Devices send standard RADIUS/UDP to this proxy
# Proxy connects to the RADIUS server via TLS

home_server radius_tls_backend {
    type = auth+acct
    ipaddr = 10.0.0.10
    port = 2083
    proto = tcp
    
    tls {
        private_key_file = /etc/ssl/private/proxy.key
        certificate_file = /etc/ssl/certs/proxy.crt
        ca_file = /etc/ssl/certs/radius-ca.crt
        require_client_cert = yes
    }
    
    secret = "radsec"
}

home_server_pool RADSEC_POOL {
    type = fail-over
    home_server = radius_tls_backend
}

realm ALL {
    pool = RADSEC_POOL
    nostrip
}

Step 4 — Generate and manage RADIUS TLS certificates

# Generate a RADIUS CA and server/client certificates using step-ca or openssl

# Create RADIUS CA
openssl genrsa -out radius-ca.key 4096
openssl req -new -x509 -days 3650 -key radius-ca.key \
  -out radius-ca.crt \
  -subj "/CN=RADIUS CA/O=Example Corp/C=US"

# Generate server certificate
openssl genrsa -out radius-server.key 2048
openssl req -new -key radius-server.key \
  -out radius-server.csr \
  -subj "/CN=radius.internal/O=Example Corp/C=US"
openssl x509 -req -days 365 \
  -CA radius-ca.crt -CAkey radius-ca.key \
  -CAcreateserial \
  -in radius-server.csr \
  -out radius-server.crt \
  -extensions v3_req

# Generate client certificate for each network device
for device in switch-01 switch-02 ap-01; do
  openssl genrsa -out "${device}.key" 2048
  openssl req -new -key "${device}.key" \
    -out "${device}.csr" \
    -subj "/CN=${device}/O=Example Corp/C=US"
  openssl x509 -req -days 365 \
    -CA radius-ca.crt -CAkey radius-ca.key \
    -in "${device}.csr" -out "${device}.crt"
  echo "Certificate generated for ${device}"
done

Step 5 — Rotate shared secrets and apply network segmentation

While migrating to RadSec:

# Generate strong shared secrets (use different secret per client)
for client in switch-01 switch-02 vpn-01; do
  secret=$(openssl rand -base64 32)
  echo "${client}: ${secret}"
  # Update in FreeRADIUS clients.conf and on the device
done

# Segment RADIUS traffic to a dedicated management VLAN
# Only RADIUS servers and approved clients should be on this VLAN
# Apply ACLs to restrict who can reach the RADIUS server

Expected Behaviour

Verification:

# Test RadSec connectivity
radtest -t tls \
  -x \
  testuser testpassword \
  radius.internal:2083 \
  0 radsec \
  /etc/ssl/certs/proxy.crt \
  /etc/ssl/private/proxy.key \
  /etc/ssl/certs/radius-ca.crt

# Verify Message-Authenticator is present in RADIUS packets
tshark -r /tmp/radius-test.pcap \
  -Y "radius.code == 1" \
  -T fields \
  -e radius.message_authenticator | \
  grep -c "." | xargs echo "Packets with Message-Authenticator:"

Trade-offs

Failure Modes

Related Articles

• Dot1X Network Access Control — 802.1X port-based authentication that RADIUS backs; Blast RADIUS directly affects this
• Kerberos Security Hardening — Kerberos as an alternative to RADIUS for enterprise authentication in some contexts
• TLS 1.3 Migration and Cipher Hardening — TLS hardening principles applicable to the RadSec TLS session
• Network Segmentation Patterns — segmenting the management network to reduce Blast RADIUS on-path attack opportunities
• SSH Terrapin Attack Hardening — a parallel “fundamental protocol flaw in an authentication protocol” story with similar remediation patterns