Researchers at the University of California, San Diego have published an exploit for the RADIUS protocol. While attacks on MD5 have been known for a while, people only suspected that those attacks could be used against RADIUS. Their paper, or is the first time that a practical attack has been demonstrated.

The attack is due to a fundamental design flaw of the RADIUS protocol. It is not a flaw in any particular implementation or product. All standards compliant RADIUS clients and servers are likely vulnerable to this attack, even if they correctly implement all aspects of the RADIUS protocol.

We have worked with Nadia Heninger and her team to characterise the issue. We have written an engineering white paper which is available on our InkBridge Networks corporate site. This paper was used as the guide by all RADIUS vendors for how to fix the problem. The updates to the RADIUS standards. are mandating these changes in all future implementations of RADIUS.

For vendors, we strongly suggest reading that paper before implementing any solution. Our paper has been reviewed by the researchers, and they agree that the attack is not possible when our recommendations are followed. If a vendor implements any other solution, they are likely to remain vulnerable to the attack

There is also have a high-level FAQ available, along with upgrade documentation and tools available on InkBrigeNetworks.com web site. That company is the new name for Network RADIUS, which is the company behind FreeRADIUS.

The truly sad thing is that we’ve been trying to fix this issue since 1998. The first public record we can find of anyone complaining about this issue is by Alan DeKok (FreeRADIUS founder) in 1998. Alan further tried to fix it in RFC 5080, Section 2.2.2, in 2007.

FreeRADIUS has implemented those suggestions since 2005. If everyone had followed these suggestions, then this issue would not exist.

The big question for network administrators, then, is what to do.

What to do

In short, don’t panic. Even if you don’t upgrade your NAS equipment, the attack is expensive, and hard to perform. The odds of you being attacked in the next little while are small, but non-zero. You will need to upgrade, but you don’t want to upgrade in a panic, get something wrong, and take your entire network down. Take your time, plan the upgrade carefully, test the upgrade, and be sure that your network both works, and is safe.

The attack is hard, because it is a “man in the middle” attack, which means that the attacker has to be able to both see, and modify Access-Request packets. If the attacker can do that, then your network is already compromised.

Even better, the attack requires substantial CPU resources to do i.e. $1000 of CPU power per packet being attacked, and the attack isn’t even guaranteed. There is also no public exploit available for “script kiddies” to run. It is extremely unlikely that anyone other than nation-states have the capability to perform the attack at this time.

However, if you are running PAP / CHAP / MS-CHAP and RADIUS/UDP over the Internet, then your users have likely been compromised for decades. There is little more we can say about that.

In order to fully protect your systems from the attack, you must update all RADIUS servers, and all RADIUS clients. The attack relies on a design flaw in the protocol. Fixing it requires updating all RADIUS implementations to the new behavior. In many cases, you do not need to panic and upgrade everything immediately. See below for more details.

Even considering the limited nature of the attack, everyone should plan on installing all firmware updates for each NAS device (including switches, routers, firewalls, VPN concentrators, etc.) which uses RADIUS. The important thing in the short term is to upgrade the RADIUS servers, determine if your network is still vulnerable, and then take action to address those vulnerabilities.

Pre-built packages of FreeRADIUS are available on the corporate site at packages.networkradius.com.

How this attack impacts FreeRADIUS.

The biggest recommendation we have is to not panic and try to upgrade all of the NAS equipment. There is a high likelihood that something will go wrong. Instead, concentrate on upgrading the RADIUS servers first.

The simple checklist for testing your local vulnerability status is as follows:

  • Is all RADIUS traffic accounting, and only accounting? The attack doesn’t affect you. You still need to upgrade everything, but you can take your time.

  • Are all Access-Request packets sent over RADIUS/TLS (RadSec)? The attack doesn’t affect you. You still need to upgrade everything, but you can take your time.

  • Are the RADIUS servers only doing EAP authentication, and no other kinds of authentication? The attack doesn’t affect you. You still need to upgrade everything, but you can take your time.

  • Are the RADIUS servers only handling local requests? I.e. none of the RADIUS servers in your network are doing proxying? Upgrade FreeRADIUS, and then you are protected. You still need to upgrade the NAS equipment, but you can take your time.

Otherwise, if your system uses PAP, CHAP, or MS-CHAP over RADIUS/UDP, you need to upgrade FreeRADIUS, and then reconfigure it with the new configuration flags. In many cases, you can take your time to upgrade the NAS equipment.

New Configuration Options

In order to prevent the attach while still not breaking things, we have added two new configuration options to the security subsection of the radiusd.conf file. Simply upgrading will not set these flags, and upgrading will not affect production networks.

The first, and most important step is to upgrade FreeRADIUS. If the checks above show that your system is vulnerable, then upgrade immediately.

Once the system is upgraded, you can set the new configuration flags. See the security { ... } subsection of radiusd.conf. The default configuration on new systems (not your current radiusd.conf) has documentation on these flags.

The simplest and easiest thing for administrators to do is to edit the security section, and add the following two entries:

security {
    ...
    require_message_authenticator = auto
    limit_proxy_state = auto
}

Setting these flags will automatically protect most systems from the attack. The only systems which are not protected are ones where there are multiple different pieces of NAS equipment behind a NAT. In that case, the only solution is to upgrade all of those pieces of NAS equipment.

Setting these flags to auto will protect the overwhelming majority of systems. The worst outcome of setting these flags is that on some unusual network configurations, packets from real clients may be discarded, or packets from some clients may still be vulnerable to the attack.

Most regular RADIUS clients do not send Proxy-State attributes for Access-Request packets thatwhich they originate. However some aggregators (e.g. Wireless LAN Controllers) may act as a RADIUS proxy for requests from their cohort of managed devices, and in such cases they will provide a Proxy-State attribute. For those systems, you must look at the actual packets to determine what to do. It may be that the only way to fix the vulnerability is to upgrade the WLC, and set require_message_authenticator=true.

This article cannot provide a full description of how to upgrade all possible networks. There are simply too many different possible network architectures for a short guide to be helpful to everyone. We believe hat the above comments will help the vast majority of organizations to upgrade quickly, easily, and with minimal risk.

There is commercial BlastRADIUS help and tools available from InkBridge Networks (previously Network RADIUS). That page provides vendor-neutral upgrade documentation and test tools, which can be used on Windows, OSX, and Linux. The documentation and test tools will work with any RADIUS client or server.

If You Cannot Update

If you cannot update FreeRADIUS immediately, there are still changes you can make which should help to protect your systems. These changes will work in all versions of FreeRADIUS from 2.0.0 to the latest 3.2.4. Unfortunately, earlier versions of the server are unsupported, and should not be used.

These changes should ONLY be made for systems which cannot be updated.

If the RADIUS client is a proxy server, and the client is another copy of FreeRADIUS 3.0.0 or later, then there are simple steps you can take. You should be able to set the require_message_authenticator flag in the client definition for of the server which receives the Access-Requests. This flag is available in all versions of FreeRADIUS from 3.0.0 onwards, and has the same functionality as mandated by the updated RFCs.

If it is possible to set this flag for all clients, then your system is safe, and there is nothing more for you to do right now.

For systems accepting packets from a NAS, edit each virtual server which handles Access-Request packets, and look for the authorize section, and add the following “if” and “update” text at the top of that section:

authorize {
	if (!EAP-Message) {
		update reply {
			Message-Authenticator := 0x00
		}
	}
...

Then restart the server for the configuration change to take effect. This change will cause the server to include a Message-Authenticator in all responses to Access-Request packets. Depending on the rest of the local policies, the Message-Authenticator should then be the first attribute in Access-Accept, Access-Reject, and Access-Challenge responses. This change is safe to make, and will not affect any other behavior.

If the system is proxying Access-Request packets, then you need to make another change.

Look for the pre-proxy section, and add the following “if” and “update” text at the top of that section. Note that the “if” statement must appear all on one line, and should not be split across multiple lines.

pre-proxy {
	if ((Packet-Type == Access-Request) && !EAP-Message) {
		update proxy-request {
			Message-Authenticator := 0x00
		}
	}
	...

Then restart the server for the configuration change to take effect. This change will cause the server to include a Message-Authenticator in all proxied Access-Request packets. Depending on the rest of the local policies, the Message-Authenticator should then be the first attribute in those packets. This change is safe to make, and will not affect any other behavior.

The only way to add further protection is to upgrade the RADIUS server to the most recent version, and to follow the instructions above for setting require_message_authenticator and limit_proxy_state.

Further FreeRADIUS Documentation

The default radiusd.conf file contains comments which document these options, and describe how they work. Please consult that file for a more complete explanation.

Vulnerable Versions

As this is a vulnerability in the protocol, all versions of FreeRADIUS are vulnerable. We have supplied pre-built packages for 3.0.27, and 3.2.5.

There are no patches availalbe for version 2, version 1, or earlier versions of the server. Those products have been deprecated for over a decade, and are all marked “end of life”.

If you are still running an older version, the short-term fix is to update the configuration to add Message-Authenticator as the first attribute in all Access-Accept, Access-Reject, and Access-Challenge packets. We do not describe how to do that here.

The correct long-term fix for people running deprecated versions of the server is to upgrade to a supported version.