9 - VU#456537

Overview

A vulnerability in the RADIUS protocol allows an attacker allows an attacker to forge an authentication response in cases where a Message-Authenticator attribute is not required or enforced. This vulnerability results from a cryptographically insecure integrity check when validating authentication responses from a RADIUS server.

Description

RADIUS is a popular lightweight authentication protocol used for networking devices specified in IETF 2058 as early as 1997 (obsoleted by RFC 2138 and then RFC 2865. There have been several other IETF standards (RADIUS/TCP, RADIUS/TLS and RADIUS/DTLS) that cover and enhance various parts of the specification for the use of RADIUS in authentication. RADIUS is widely used to authenticate both users and devices and widely supported by networking devices, from basic network switches to more complex VPN solutions. Recently, RADIUS has also been adopted in much of the cloud services that provide tiered, role-based access-control to resources. As a client-server protocol, RADIUS uses a Request-Response model to verify authentication requests and further provide any role-based access using Groups. RADIUS can also be proxied to support multi-tenant roaming access services.

A vulnerability in the verification of RADIUS Response from a RADIUS server has been disclosed by a team of researchers from UC San Diego and their partners. An attacker, with access to the network where the RADIUS protocol is being transmitted, can spoof a UDP-based RADIUS Response packet to modify any valid Response (Access-Accept, Access-Reject, or Access-Challenge) to any other response, with almost any content, completely under the attackers control. This allows the attacker to transform a Reject into an Accept without knowledge of the shared secret between the RADIUS client and server. The attack is possible due to a basic flaw in the RADIUS protocol specification that uses a MD5 hash to verify the response, along with the fact that part of the hashed text is predictable allowing for a chosen-prefix collision. The attack, demonstrated by UCSD team, takes advantage of the chosen-prefix collision of the MD5 message in a novel way. The widespread use of RADIUS and its adoption into the cloud allows for such attacks to pose a reasonable threat to the authentication verification process that relies on RADIUS.

RADIUS servers that only perform Extensible Authentication Protocol (EAP), as specified in RFC 3579, are unaffected by this attack. The EAP authentication messages require the Message-Authenticator attribute, which will prevent these attacks from succeeding. The use of TLS (or DTLS) encryption can also prevent such attacks from succeeding. However, RADIUS over TCP itself can still be susceptible to this attack, with more advanced man-in-the-middle scenarios, to successfully attack the TCP connection.

Finally as explained by Alan Dekok, developer of FreeRadius open source software -

The key to the attack is that in many cases, Access-Request packets have no authentication or integrity checks. An attacker can then perform a chosen prefix attack, which allows modifying the Access-Request in order to replace a valid response with one chosen by the attacker. Even though the response is authenticated and integrity checked, the chosen prefix vulnerability allows the attacker to modify the response packet, almost at will.

Impact

An attacker with access to the network where RADIUS Access-Request is transported can craft a response to the RADIUS server irrespective of the type of response (Access-Accept, Access-Reject, Access-Challenge, or Protocol-Error) to modify the response to any of the valid responses. This can allow an attacker to change the Reject response to an Accept or vice versa. The attack can also potentially intercept an Access-Challenge, typically used in Multi-Factor Authentication (MFA), and modify it to an Access-Accept, thus bypassing the MFA used within RADIUS. Due to the flexible, proxied nature of the RADIUS protocol, any server in the chain of proxied RADIUS servers can be targeted to succeed in the attack.

Solution

Device Manufacturers

RADIUS-compliant software and hardware manufacturers should adopt the recommendations from the Article document to mitigate the risk of the RADIUS protocol limitations identified in this attack. Manufacturers who bundle the open-source RADIUS implementations, such as FreeRadius, should update to the latest available software for both clients and servers and, at a minimum, require the use of the Message-Authenticator for RADIUS authentication.

Operators

Network operators who rely on the RADIUS-based protocol for device and/or user authentication should update their software and configuration to a secure form of the protocol for both clients and servers. This can be done by enforcing TLS or DTLS encryption to secure the communications between the RADIUS client and server. Where possible, network isolation and secure VPN tunnel communications should be enforced for the RADIUS protocol to restrict access to these network resources from untrusted sources.

Acknowledgements

Thanks to Sharon Goldberg, Miro Haller, Nadia Heninger, Mike Milano, Dan Shumow, Marc Stevens, and Adam Suhl who collaborated for this research and supported coordinated vulnerability disclosure to reach multiple vendors and stakeholders. Thanks to Alan Dekok for spearheading the IETF proposal and recommendations. This document was written by Vijay Sarvepalli and Timur Snoke.