New Blast-RADIUS attack breaks 30-year-old protocol used in networks everywhere

One of the most widely used network protocols is vulnerable to a newly discovered attack that can allow adversaries to gain control over a range of environments, including industrial controllers, telecommunications services, ISPs, and all manner of enterprise networks.

 

Short for Remote Authentication Dial-In User Service, RADIUS harkens back to the days of dial-in Internet and network access through public switched telephone networks. It has remained the de facto standard for lightweight authentication ever since and is supported in virtually all switches, routers, access points, and VPN concentrators shipped in the past two decades. Despite its early origins, RADIUS remains an essential staple for managing client-server interactions for:

 

• VPN access
• DSL and Fiber to the Home connections offered by ISPs,
• Wi-Fi and 802.1X authentication
• 2G and 3G cellular roaming
• 5G Data Network Name authentication
• Mobile data offloading
• Authentication over private APNs for connecting mobile devices to enterprise networks
• Authentication to critical infrastructure management devices
• Eduroam and OpenRoaming Wi-Fi

 

RADIUS provides seamless interaction between clients—typically routers, switches, or other appliances providing network access—and a central RADIUS server, which acts as the gatekeeper for user authentication and access policies. The purpose of RADIUS is to provide centralized authentication, authorization, and accounting management for remote logins.

 

The protocol was developed in 1991 by a company known as Livingston Enterprises. In 1997 the Internet Engineering Task Force made it an official standard, which was updated three years later. Although there is a draft proposal for sending RADIUS traffic inside of a TLS-encrypted session that's supported by some vendors, many devices using the protocol only send packets in clear text through UDP (User Datagram Protocol).

 

Roll-your-own authentication with MD5? For real?

Since 1994, RADIUS has relied on an improvised, home-grown use of the MD5 hash function. First created in 1991 and adopted by the IETF in 1992, MD5 was at the time a popular hash function for creating what are known as “message digests” that map an arbitrary input like a number, text, or binary file to a fixed-length 16-byte output.

 

For a cryptographic hash function, it should be computationally impossible for an attacker to find two inputs that map to the same output. Unfortunately, MD5 proved to be based on a weak design: Within a few years, there were signs that the function might be more susceptible than originally thought to attacker-induced collisions, a fatal flaw that allows the attacker to generate two distinct inputs that produce identical outputs. These suspicions were formally verified in a paper published in 2004 by researchers Xiaoyun Wang and Hongbo Yu and further refined in a research paper published three years later.

 

The latter paper—published in 2007 by researchers Marc Stevens, Arjen Lenstra, and Benne de Weger—described what’s known as a chosen-prefix collision, a type of collision that results from two messages chosen by an attacker that, when combined with two additional messages, create the same hash. That is, the adversary freely chooses two distinct input prefixes 𝑃 and 𝑃′ of arbitrary content that, when combined with carefully corresponding suffixes 𝑆 and 𝑆′ that resemble random gibberish, generate the same hash. In mathematical notation, such a chosen-prefix collision would be written as 𝐻(𝑃‖𝑆)=𝐻(𝑃′‖𝑆′). This type of collision attack is much more powerful because it allows the attacker the freedom to create highly customized forgeries.

 

To illustrate the practicality and devastating consequences of the attack, Stevens, Lenstra, and de Weger used it to create two cryptographic X.509 certificates that generated the same MD5 signature but different public keys and different Distinguished Name fields. Such a collision could induce a certificate authority intending to sign a certificate for one domain to unknowingly sign a certificate for an entirely different, malicious domain.

 

In 2008, a team of researchers that included Stevens, Lenstra, and de Weger demonstrated how a chosen prefix attack on MD5 allowed them to create a rogue certificate authority that could generate TLS certificates that would be trusted by all major browsers. A key ingredient for the attack is software named hashclash, developed by the researchers. Hashclash has since been made publicly available.

 

Despite the undisputed demise of MD5, the function remained in widespread use for years. Deprecation of MD5 didn’t start in earnest until 2012 after malware known as Flame, reportedly created jointly by the governments of Israel and the US, was found to have used a chosen prefix attack to spoof MD5-based code signing by Microsoft’s Windows update mechanism. Flame used the collision-enabled spoofing to hijack the update mechanism so the malware could spread from device to device inside an infected network.

 

More than 12 years after Flame's devastating damage was discovered and two decades after collision susceptibility was confirmed, MD5 has felled yet another widely deployed technology that has resisted common wisdom to move away from the hashing scheme—the RADIUS protocol, which is supported in hardware or software provided by at least 86 distinct vendors. The result is “Blast RADIUS,” a complex attack that allows an attacker with an active adversary-in-the-middle position to gain administrator access to devices that use RADIUS to authenticate themselves to a server.

 

“Surprisingly, in the two decades since Wang et al. demonstrated an MD5 hash collision in 2004, RADIUS has not been updated to remove MD5,” the research team behind Blast RADIUS wrote in a paper published Tuesday and titled RADIUS/UDP Considered Harmful. “In fact, RADIUS appears to have received notably little security analysis given its ubiquity in modern networks.”

 

The paper's publication is being coordinated with security bulletins from at least 90 vendors whose wares are vulnerable. Many of the bulletins are accompanied by patches implementing short-term fixes, while a working group of engineers across the industry drafts longer-term solutions. Anyone who uses hardware or software that incorporates RADIUS should read the technical details provided later in this post and check with the manufacturer for security guidance.

From hours to minutes

Key to making Blast-RADIUS practical is a series of optimizations made to hashclash that radically reduce the time required to complete a chosen prefix attack. The 2008 attack used to create the rogue certificate authority, for instance, required about 2,800 core-days, a measurement of computational time equivalent to running one CPU for 2,800 days. The optimization devised for Blast-RADIUS whittles that time down to just 39 core hours. Distributing the load to a cluster of roughly 2,000 CPU cores ranging from 7 to 10 years old, plus four newer low-end GPUs—the modest resources available to the academic researchers—the wall time required for Blast-RADIUS to complete is about five minutes.

 

This version of Blast-RADIUS isn’t practical for attacking RADIUS because logins typically time out after 30 to 60 seconds. The researchers say the five minutes they required is the result of them using commodity old hardware. They say they’re convinced their attack is sufficient when carried out on hardware better suited for hash collisions. They explained:

 

While we have been able to reduce the online running time for our MD5 chosen-prefix attack from hours down to minutes, this should be interpreted as a generous upper bound for the true cost of such collisions, because of the limits on our computational resources. Newer CPUs than the seven to ten year old machines we have access to would likely provide minutes of improvement, as would optimizing cache locality.

 

Access to more and faster GPUs would reduce the time for the birthday stage and/or reduce the number of near-collision blocks, reducing time for the near-collision stage. Reimplementing hashclash in hardware, for example on FPGAs (Field Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits) would likely improve the running time by a factor of ten to a hundred.

 

It would be eminently feasible to run this attack on cloud resources. Amazon EC2 lists the on-demand price of a c7a.48xlarge instance with 192 vCPUs at $9.85/hour, and the price of a g6.48xlarge instance with 192 vCPUs and 8 NVIDIA L4 GPUs at $13.35/hour. It would cost around $50/hour to exceed our computing capacity, and in principle one could scale to many more machines.

 

We did not pursue this avenue further for two reasons. First, based on previous experience the cost of simply implementing and debugging an attack in the cloud that requires launching hundreds of dollars an hour of computing instances can quickly reach tens of thousands of dollars. Second, achieving further gains would require us to more substantially re-architect hashclash. We hope that the reader is already convinced that MD5 is exploitable.

The improvements also allow the attacker to split the gibberish block as multiple properly formatted small protocol attribute fields that get appended to the chosen prefix. This allows the Blast-RADIUS attacker to carry out the attack efficiently, within the RADIUS timeout limits of 30 to 60 seconds, and to squeeze the required data into the RADIUS protocol format. Blast-RADIUS affects all authentication modes of RADIUS/UDP apart from those that use EAP (Extensible Authentication Protocol).

Threat model

Blast-RADIUS requires the adversary to have the network access needed to act as an active adversary-in-the-middle attacker, meaning the adversary has the ability to read, intercept, block, and modify all data passing between the victim device’s RADIUS client and RADIUS server. When there are proxies between the two endpoints, the attack can occur between any hop.

 

This access to RADIUS traffic can happen when RADIUS/UDP packets travel over the open Internet, a practice that’s discouraged but still known to happen. When traffic is restricted to an internal network, the attacker might first compromise a part of that network, another common occurrence. In the event RADIUS traffic is restricted to a protected part of an internal network, it may still be exposed as a result of configuration or routing errors. An attacker with partial network access might also be able to access RADIUS traffic by exploiting mechanisms such as DHCP to induce victim devices to send traffic outside of a dedicated VPN

 

In one document accompanying Tuesday’s paper, the authors provided the following graphic illustrating the flow of a Blast-RADIUS attack along with seven key steps:

 

1. The adversary enters the username of a privileged user and an arbitrary incorrect password.

 

2. This causes the RADIUS client of a victim’s network device to generate a RADIUS Access-Request, which includes a 16-byte random value called Request Authenticator.

 

3. The man-in-the-middle adversary intercepts this request and uses the Access-Request (including the random Request Authenticator) to predict the format of the server response (which will be an Access-Reject as the entered password is incorrect). Then the adversary computes an MD5 collision between the predicted Access-Reject and an Access-Accept response that it would like to forge. This results in binary gibberish strings RejectGibberish and AcceptGibberish such that MD5(Access-Reject||RejectGibberish) equals MD5(Access-Accept||AcceptGibberish).

 

4. After computing the collision, the man-in-the-middle attacker adds RejectGibberish to the Access-Request packet, disguised as a Proxy-State attribute.

 

5. The server receiving this modified Access-Request checks the user password, decides to reject the request, and responds with an Access-Reject packet. As the RADIUS protocol mandates that the Proxy-State attributes are included in responses, RejectGibberish is attached to the response. In addition, the server computes and sends a Response Authenticator, which is essentially MD5(Access-Reject||RejectGibberish||SharedSecret), for its Access-Reject response, to prevent tampering. The attacker does not know the value of SharedSecret and cannot predict or verify the MD5 hash.

 

6. The adversary intercepts this response and checks that the packet format matches the predicted Access-Reject||RejectGibberish pattern. If it does, the adversary replaces the response by Access-Accept||AcceptGibberish and sends it with the unmodified Response Authenticator to the client.

 

7. Due to the MD5 collision, the Access-Accept sent by the adversary verifies with the Response Authenticator, without the adversary knowing the shared secret. Hence, the RADIUS client believes the server approved this login request and grants the adversary access.

 

This description is simplified. In particular, we had to do cryptographic work to split the MD5 collision gibberish across multiple properly formatted Proxy-State attributes, and to optimize and parallelize the MD5 collision attack to run in minutes instead of hours. Please read our paper (/pdf/radius.pdf) for a comprehensive description.

With that, the attacker has successfully logged in to the device with administrative system rights. The attacker does not need to wait for a real user to attempt to log in to a RADIUS client. Instead, the attacker triggers an authentication request on its own by using any password. From there, Blast-RADIUS changes the authentication outcome from unsuccessful to successful.

Mitigations

Over the long run, the researchers said, the only way to fix RADIUS is to transport it over TLS or DTLS, a move that provides modern security guarantees including confidentiality to the user data in the requests and ensures the integrity of the Access-Accept and Access-Reject responses. A working group within the IETF is drafting a specification update that aims to do just that. These sorts of major renovations take months or even years to complete. Some implementations of RADIUS, namely the one from Microsoft, have yet to support TLS.

 

In the meantime, for those environments that must continue to transport RADIUS over UDP, the researchers recommend that both RADIUS clients and servers always send and require Message-Authenticator attributes for all requests and responses using what's known as HMAC-MD5 for packet authentication. For Access-Accept and Access-Reject responses, the Message-Authenticator should be included as the first attribute. All five of the major RADIUS implementations—available from FreeRADIUS, Radiator, Cisco, Microsoft, and Nokia—have updates available that follow this short-term recommendation.

 

“This measure breaks compatibility with old implementations that may not include Message-Authenticators in requests or responses,” the researchers cautioned. “However, unlike other options, it is not a fundamental change to the protocol and can be adopted as a fairly simple patch to clients and servers.”

 

The researchers continued:

 

Unfortunately, it is not enough for senders to always include a Message-Authenticator if the receiving party does not require its presence. We give two example attacks allowing an attacker to circumvent these incomplete mitigations. For Access-Request packets, the attacker can simply strip a Message-Authenticator sent by a client if it is not required by the server. This is because there is no other authentication of the packet contents. Once the attacker has removed the Message-Authenticator, the request can be modified as desired without being detected.

 

In the other direction for Access-Accept and Access-Reject responses, a man-in-the-middle attacker cannot simply strip this attribute from the packet as for requests, because the Message-Authenticator attribute is included in the Response Authenticator. However, we observed that the Message-Authenticator attribute was typically the last attribute in the packet in implementations we examined. If the Message-Authenticator is not the first attribute in the packet then our man-in-the-middle attacker can hide it in a Proxy-State or other attribute by crafting a malicious prefix to end with a Proxy-State header, and simply copy the bytes of the Message-Authenticator into the Proxy-State after the collision. The receiving client will interpret this packet as a valid packet without a Message-Authenticator.

Alan DeKok, the lead maintainer of FreeRADIUS, the most widely used RADIUS implementation, has additional mitigation guidance here.

The paper authors are:

 

• Sharon Goldberg (as of May, Cloudflare)
• Miro Haller (University of California, San Diego)
• Nadia Heninger (University of California, San Diego)
• Mike Milano (BastionZero)
• Dan Shumow (Microsoft Research)
• Marc Stevens (Centrum Wiskunde & Informatica)
• Adam Suhl (University of California, San Diego)

 

They have assembled an FAQ and technical details on this site. More broadly, the authors hope their research serves as a wake-up call that will prompt those inside organizations that implement or rely on widely used network protocols to review and stress test them to identify weaknesses.

 

“Given the enormous amount of effort put into securing these protocols it is surprising that a protocol as ubiquitous as RADIUS has received so little cryptanalytic attention over the years,” they wrote. “TLS may be the charismatic megafauna of cryptographic protocol research, but in order to actually secure our infrastructure we need to analyze and secure the entire universe of enterprise security that academic cryptographers have little to no visibility into or insight in.”