Getty Images
One of the most widely used network protocols is vulnerable to a newly discovered attack that can allow adversaries to take control of 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 harks back to the days of dial-up Internet and network access over public switched telephone networks. It has remained the de facto standard for lightweight authentication ever since, and is supported by virtually every switch, router, access point, and VPN concentrator shipped in the last two decades. Despite its ancient origins, RADIUS remains a critical part of managing client-server interactions for:
- VPN Access
- DSL and fiber optic connections to the home offered by ISPs,
- Wi-Fi and 802.1X Authentication
- 2G and 3G cellular roaming
- 5G Data Network Name Authentication
- Mobile data download
- Authentication via private APNs to connect mobile devices to corporate networks
- Authentication to critical infrastructure management devices
- Wi-Fi Eduroam and OpenRoaming
RADIUS enables seamless interaction between clients (typically routers, switches, or other devices providing network access) and a central RADIUS server, which acts as the guardian of user access and authentication policies. The goal of RADIUS is to provide centralized authentication, authorization, and accounting for remote connections.
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. While there is a draft proposal for sending RADIUS traffic in an encrypted TLS session that is supported by some vendors, many devices using the protocol only send cleartext packets over UDP (User Datagram Protocol).
XKCD
Goldberg et al.
Create your own authentication with MD5? Really?
Since 1994, RADIUS has relied on an improvised, home-grown use of the MD5 hash function. Created in 1991 and adopted by the IETF in 1992, MD5 was at the time a popular hash function for creating so-called “message digests” that map an arbitrary input such as 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 correspond to the same output. Unfortunately, MD5 was shown to be based on a weak design: within a few years, there were indications that the function might be more susceptible than expected to attacker-induced collisions, a fatal flaw that allows an attacker to generate two distinct inputs that produce identical outputs. These suspicions were formally verified in a 2004 paper by researchers Xiaoyun Wang and Hongbo Yu and refined in a research paper published three years later.
This latter paper, published in 2007 by researchers Marc Stevens, Arjen Lenstra, and Benne de Weger, describes what is called 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. In other words, the adversary freely chooses two distinct input prefixes 𝑃 and 𝑃’ of arbitrary content that, when combined with carefully matching suffixes 𝑆 and 𝑆’ that look like 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 gives the attacker the freedom to create highly customized counterfeits.
To illustrate the practicality and devastating consequences of the attack, Stevens, Lenstra, and de Weger used it to create two X.509 cryptographic certificates that generated the same MD5 signature but different public keys and distinguished name fields. Such a collision could prompt a certificate authority that wanted to sign a certificate for one domain to unknowingly sign a certificate for an entirely different, malicious domain.
In 2008, a team of researchers including Stevens, Lenstra, and Weger demonstrated how a chosen-prefix attack on MD5 allowed them to create a malicious certificate authority capable of generating TLS certificates that all major browsers would trust. One of the key ingredients in the attack was a piece of software called hashclash, developed by the researchers. Hashclash has since been released to the public.
Despite MD5’s undisputed demise, the feature remained in widespread use for years. MD5’s deprecation only began to be felt in 2012, after a malware known as Flame, believed to have been jointly created by the governments of Israel and the United States, was discovered using a chosen-prefix attack to spoof MD5-based code signing by Microsoft’s Windows update mechanism. Flame used collision-enabled spoofing to hijack the update mechanism so that the malware could spread from device to device within an infected network.
More than 12 years after Flame’s devastating damage was discovered and two decades after the collision vulnerability was confirmed, MD5 has put an end to another widely deployed technology that has resisted the conventional wisdom of moving away from the hash scheme: the RADIUS protocol, which is supported by hardware or software from at least 86 different vendors. The result is “RADIUS Blast,” a sophisticated attack that allows an attacker with an active adversary-in-the-middle position to gain administrative access to devices that use RADIUS to authenticate 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 titled RADIUS/UDP considered dangerous“In fact, RADIUS appears to have received very little security analysis given its ubiquity in modern networks.”
The release of this document is coordinated with security bulletins from at least 90 vendors whose products are vulnerable. Many bulletins are accompanied by patches implementing short-term workarounds, while a working group of industry engineers is developing longer-term workarounds. Anyone using hardware or software that incorporates RADIUS should read the technical details provided later in this article and consult the manufacturer for security advice.