Mitigating RADIUS Vulnerabilities: A Security Hardening Guide

MITIGATING RADIUS VULNERABILITIES: A SECURITY HARDENING GUIDE A Purple WiFi Intelligence Briefing [INTRODUCTION — approx. 1 minute] Welcome. I'm your host for today's briefing, and over the next ten minutes we're going to cut straight to the core of something that keeps a lot of network architects and IT managers up at night: RADIUS server security. If you're running enterprise WiFi across a hotel estate, a retail chain, a stadium, or a public-sector building, your RADIUS infrastructure is one of the most critical - and most frequently overlooked - components in your security posture. Let's get into it. [CONTEXT — approx. 1 minute] RADIUS - Remote Authentication Dial-In User Service - has been the backbone of network access control since the mid-nineties. It's the protocol that sits between your access points and your identity directory, deciding who gets on the network and who doesn't. IEEE 802.1X, which underpins virtually every enterprise WiFi and wired authentication deployment, relies on RADIUS to function. The problem is that RADIUS was designed in an era when the threat landscape looked very different. The protocol uses UDP, which is connectionless and therefore harder to secure. Its core authentication mechanism has historically relied on MD5 hashing - a cryptographic algorithm that has been demonstrably broken since 2004. And shared secrets, the pre-shared keys that authenticate your access points to your RADIUS server, are often set once and never rotated. In 2024, researchers published a practical attack against RADIUS called BlastRADIUS - a man-in-the-middle attack that exploits the MD5 vulnerability to forge authentication responses. This isn't theoretical. It's a real, documented attack vector that affects deployments running unpatched FreeRADIUS, Cisco ISE, and Microsoft NPS. If you haven't patched since mid-2024, you're exposed. The business stakes are significant. A compromised RADIUS server doesn't just mean unauthorized WiFi access. It means an attacker can authenticate as any user on your network, bypass network segmentation, and potentially access payment systems, patient records, or operational technology. For retail environments processing card payments, that's a direct PCI-DSS breach. For healthcare, it's a CCPA/CPRA and clinical governance issue. For hospitality, it's brand damage and potential regulatory fines. [TECHNICAL DEEP-DIVE — approx. 5 minutes] Let's walk through the attack surface systematically. The first vulnerability class is the MD5 collision risk. RADIUS uses MD5 to protect the User-Password attribute and to generate the Response Authenticator field. MD5 produces a 128-bit hash, and collision attacks - where two different inputs produce the same hash - have been feasible since 2004. The BlastRADIUS attack specifically exploits the lack of integrity protection on Access-Request packets. An attacker positioned between your NAS device - that's your network access server, typically your access point or switch - and your RADIUS server can inject a crafted attribute into the packet and force the server to return an Access-Accept, even for an invalid credential. The fix here is twofold: patch your RADIUS server to the latest version, and enforce Message-Authenticator on all Access-Request packets. FreeRADIUS 3.2.5 and later require this by default. The second vulnerability class is weak or static shared secrets. The shared secret is the pre-shared key between your NAS and your RADIUS server. If it's short, dictionary-attackable, or hasn't been rotated in years, it's a liability. RADIUS uses this secret to encrypt the User-Password attribute and to generate the Response Authenticator. A weak shared secret means an attacker who captures RADIUS traffic - which is trivial on a network they've already partially compromised - can brute-force the password offline. Best practice is a minimum of 32 characters, randomly generated, and rotated at least annually. Automate this rotation; doing it manually across a large estate is error-prone. The third vulnerability class is unencrypted transport. Standard RADIUS runs over UDP on port 1812 for authentication and 1813 for accounting. UDP provides no transport-layer encryption, no integrity checking, and no replay protection beyond what RADIUS implements itself - which, as we've established, is insufficient. RadSec, formally defined in RFC 6614, wraps RADIUS in TLS 1.2 or 1.3 over TCP port 2083. This provides mutual authentication via certificates, full encryption of the RADIUS payload, and replay protection. If you're running RADIUS across any untrusted network segment - including across a WAN link between a remote venue and a central RADIUS server - RadSec is not optional. It's a requirement. The fourth vulnerability class is the EAP method selection. Not all EAP methods are equal. EAP-MD5 should be considered deprecated - it provides no mutual authentication and no encryption of the authentication exchange. PEAP and EAP-TTLS are acceptable for most enterprise deployments, as they establish a TLS tunnel before transmitting credentials, and they support mutual authentication via server certificates. EAP-TLS is the gold standard: it requires both the server and the client to present certificates, eliminating the password entirely from the authentication exchange. This makes it immune to credential phishing and brute-force attacks. The operational overhead of deploying a PKI to issue client certificates is real, but for high-security environments - healthcare networks, payment-processing zones, back-of-house retail systems - it's the right call. The fifth vulnerability class is insufficient logging and monitoring. RADIUS accounting data is a goldmine for threat detection, and most organizations aren't using it. Every authentication attempt, successful or failed, generates an accounting record. Patterns of failed authentications, authentications from unexpected MAC addresses, or authentications at unusual times are all indicators of compromise. Integrate your RADIUS accounting stream into your SIEM. Set alerts for more than five failed authentications from a single MAC address within sixty seconds. Monitor for Access-Reject storms, which can indicate a credential-stuffing attack in progress. [IMPLEMENTATION RECOMMENDATIONS AND PITFALLS - approx. 2 minutes] Let me give you a practical sequencing for a hardening project. Start with patching. This is non-negotiable and should be done within your next change window. FreeRADIUS, Cisco ISE, and Microsoft NPS all released patches for BlastRADIUS in July 2024. Check your version, apply the patch, and verify that Message-Authenticator enforcement is active. Next, audit your shared secrets. Pull the list of every NAS device registered to your RADIUS server. For each one, check the shared secret length and age. Anything under 20 characters or over two years old should be rotated immediately. Use a password manager or secrets vault - HashiCorp Vault works well here - to store and rotate these programmatically. Third, evaluate your EAP method. If you're running EAP-MD5 anywhere, migrate away from it now. PEAP-MSCHAPv2 is a reasonable interim position for most enterprise environments. If you have the PKI infrastructure, EAP-TLS is the target state. Fourth, implement RadSec for any RADIUS traffic traversing untrusted network segments. This is particularly relevant for multi-site deployments where a central RADIUS server serves remote venues over the internet or a shared WAN. Fifth, enable multi-factor authentication for privileged access to the RADIUS server itself. The server's management interface is a high-value target. Enforce MFA for all administrative logins, and restrict management access to a dedicated out-of-band management network. Now, the pitfalls. The most common mistake I see is organizations patching the RADIUS server but leaving the NAS devices on old firmware that doesn't support Message-Authenticator. The patch is only effective if both ends enforce it. Audit your access point and switch firmware as part of the same project. The second common pitfall is certificate expiration. If you're running EAP-TLS or RadSec, you have certificates in play. A RADIUS server certificate that expires silently will cause every authentication on your network to fail simultaneously. Build certificate expiration monitoring into your operational runbook. Set alerts at 90, 30, and 7 days before expiration. The third pitfall is over-reliance on network segmentation as a compensating control. Segmentation is important, but it doesn't protect against an attacker who has already authenticated via a compromised RADIUS server. Defense in depth means you need the RADIUS hardening as well as the segmentation. [RAPID-FIRE Q&A - approx. 1 minute] Question: Do I need RadSec if my RADIUS server is on the same LAN as my access points? Answer: If they're on the same trusted, segmented management VLAN with no untrusted devices, standard RADIUS over UDP is acceptable for the NAS-to-server leg. But if there's any possibility of lateral movement from a compromised device reaching that VLAN, RadSec adds meaningful protection at low cost. Question: We're running Microsoft NPS. Are we affected by BlastRADIUS? Answer: Yes. Microsoft released a patch in July 2024. Apply it. Also enforce the RequireMessageAuthenticator registry key on your NPS server. Question: How do I handle guest WiFi? Guests don't have certificates. Answer: Guest WiFi typically uses a Captive Portal model rather than 802.1X, so RADIUS is used differently - often just for MAC authentication bypass or accounting. The same patching and shared secret hygiene applies, but EAP-TLS isn't relevant for unauthenticated guest access. Focus on isolating the guest RADIUS instance from your corporate RADIUS infrastructure. Question: What's the ROI case for a full EAP-TLS migration? Answer: Quantify it against your breach risk. A single PCI-DSS breach costs an average of four million dollars in fines, remediation, and reputational damage. A PKI deployment for a 500-device estate costs roughly $15,000 to $30,000 in tooling and professional services. The math is straightforward. [SUMMARY AND NEXT STEPS - approx. 1 minute] Let me leave you with five things to do this quarter. One: Patch your RADIUS server and all NAS devices for BlastRADIUS. Do this first. Two: Audit and rotate all shared secrets. Automate rotation going forward. Three: Enforce Message-Authenticator on all Access-Request packets. Four: Implement RadSec for any RADIUS traffic crossing untrusted network boundaries. Five: Integrate RADIUS accounting logs into your SIEM and set anomaly alerts. RADIUS security isn't glamorous, but it's foundational. Get these five things right, and you've closed the most significant attack vectors against your network access control infrastructure. Thanks for listening. For more on enterprise WiFi security architecture, visit purple.ai. This has been a Purple WiFi Intelligence Briefing.