The “secure enough” RADIUS/UDP authentication protocol may have finally met its match, and organizations that have continued to rely on RADIUS to authenticate networked devices over UDP and TCP despite its reliance on outdated cryptography are urged to take immediate action to secure their networks.
The protocol, which dates back to the early 1990s, remains widely used for network access control and authentication to switches, routers, and other networked devices. It is also used for authentication on Wi-Fi networks as well as by some ISPs to authenticate clients for DSL and fiber-to-the-home (FTTH) connections. And now, as has been proved by a team of researchers, attackers can exploit an inherent vulnerability in RADIUS to spoof authentication to network devices and potentially gain administrative control over them.
The practical attack, dubbed Blast-RADIUS (CVE-2024-3596) and developed by researchers from the University of California San Diego, Cloudflare, CWI Amsterdam, Microsoft, and BastionZero, exploits the MD5 hash function used by the decades-old protocol to protect passwords. MD5 has been considered cryptographically broken since at least 2008 because it was proven vulnerable to hash collisions attacks — two distinct pieces of data having the same MD5 hash — but the practical application of MD5 collisions to break RADIUS security has remained unproven until this week.
“Prior to our work, there was no publicly-known attack exploiting MD5 to violate the integrity of the RADIUS/UDP traffic,” the researchers wrote in a blog post. “However, attacks continue to get faster, cheaper, become more widely available, and become more practical against real protocols. Protocols that we thought might be ‘secure enough,’ in spite of their reliance on outdated cryptography, tend to crack as attacks continue to improve over time.”
How Blast-RADIUS works
The RADIUS authentication, authorization, and accounting (AAA) protocol operates using a client-server model. When a user or machine tries to access a resource in a RADIUS-deployed network, they send a request with their credentials to that resource, which uses a RADIUS client to forward them to a RADIUS server for validation and authorization.
The message between the RADIUS client and server, known as an Access-Request, contains the user’s obfuscated username and password along with various other information. The server responds with Access-Reject or Access-Accept messages that contain a message authentication code (MAC) called Response Authenticator whose goal is to prove that the response came from the server and was not tampered with.
The problem is that the Response Authenticator comprises hashed-together information from the response packet, a code from the Access-Request packet, and a secret known by the client and server. That hashing is performed with MD5, making it vulnerable to chosen-prefix collisions.
Such an attack can be described as MD5 (P1 || G1 || S) = MD5 (P2 || G2 || S), where P1 and P2 are different, freely chosen meaningful messages, G1 and G2 are meaningless gibberish, and S is a meaningful message.
“Roughly speaking, in our attack, P1 will correspond to a RADIUS Access-Reject, and P2 will correspond to a RADIUS Access-Accept, thus allowing us to break the security of the protocol by letting an unauthorized user log into a networking device running a RADIUS client,” the researchers wrote.
In other words, the researchers need to find G1 and G2 that collide. With a man-in-the-middle (MitM) position between client and server, they send a request to the resource to authenticate as administrator with an incorrect password, and the RADIUS client will generate an Access-Request message that will result in an Access-Reject from the server due to incorrect credentials.
But, due to their MitM position, the attackers will modify the Access-Request to include G1 in a message attribute called Proxy-State, which according to the standard must be echoed back by the server to the client. When the server responds with Access-Reject, the message is again intercepted by the attackers and changed into an Access-Accept with the precomputed G2 message. The client will accept this message and allow authentication because the MD5 hash of both constructions together with the shared secret S will be the same. The attacker doesn’t need to know S. They just need to control the prefix P1+G1 and P2+G2.
But there’s a catch: Computing the prefixes needs to be done on the fly and relatively fast because the connection between the RADIUS client and server has a timeout maximum of 5 minutes and existing MD5 chosen-prefix collision attacks have taken longer than that.
“Our team improved existing chosen-prefix collision attacks on MD5 and optimized them for speed and space (in addition to figuring out how to make our collision gibberish fit into RADIUS Proxy-State attributes),” the researchers wrote. “We demonstrated an improved attack that can run in minutes on an aging cluster of about 2000 CPU cores ranging from 7 to 10 years old, plus four newer low-end GPUs at UCSD. Less than two months after we started this project, we could execute the attack in under five minutes, and validate (in a lab setting) that it works on popular commercial RADIUS implementations.”
According to the team, a resourceful attacker with access to cloud computing clusters and GPUs could further parallelize the attack and would be able to defeat even shorter timeouts.
What implementations are vulnerable?
The RADIUS protocol can technically use both UDP and TCP for transporting messages over a network. The researchers targeted RADIUS/UDP because it’s often the default and most popular implementation. RADIUS/TCP is still considered an experimental standard, as is RADIUS over TLS, also known as RADSEC, which is not vulnerable to this attack and is a recommended mitigation.
RADIUS also supports multiple authentication modes: Password Authentication Protocol (PAP),
Challenge-Handshake Authentication Protocol (CHAP), a variation of CHAP called MS-CHAP, and Extensible Authentication Protocol (EAP). The EAP implementations, such as EAP-TLS, which uses a TLS handshake, are not vulnerable to this attack due to their design, but the researchers cannot rule out the possibility that they could be vulnerable to a variation of the attack in the future.
Furthermore, since 2000, RADIUS/UDP received support for a new message attribute called Message-Authenticator that is based on HMAC-MD5 instead of just MD5. Collision attacks like the one devised by the team do not work on HMAC-MD5, but this attribute is optional for all modes of RADIUS/UDP aside from EAP ones where it’s mandatory.
Mitigation
“Our recommended short-term mitigation for implementers and vendors is to mandate that clients and servers always send and require Message-Authenticator attributes for all requests and responses,” the researchers wrote. “For Access-Accept or Access-Reject responses, the Message-Authenticator should be included as the first attribute. Patches implementing this mitigation have been implemented by all RADIUS implementations that we are aware of. This guidance is being put into an upcoming RADIUS RFC.”
Users are advised to deploy the patches from their device vendors as soon as possible. However, in the longer term, the better option is for the industry to adopt RADIUS/(D)TLS based on TLS 1.3 with forward secrecy. Alan DeKok, the creator and maintainer of FreeRADIUS, the most popular open-source RADIUS server, has already submitted a proposal to the Internet Engineering Task Force (IETF) to deprecate RADIUS over UDP and TCP where he explains in detail all the security risks associated with them.