[<prev] [next>] [day] [month] [year] [list]
Message-ID: <047e2b26-5287-4c32-aac8-224292b1b284@oracle.com>
Date: Tue, 9 Jul 2024 13:03:28 -0700
From: Alan Coopersmith <alan.coopersmith@...cle.com>
To: oss-security@...ts.openwall.com
Subject: CVE-2024-3596: RADIUS/UDP vulnerable to improved MD5 collision attack
https://kb.cert.org/vuls/id/456537 discloses the new Blast-RADIUS attack:
> 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
> --------
> RADIUS-compliant software and hardware manufacturers should adopt the
> recommendations from the
> https://networkradius.com/assets/pdf/radius_and_md5_collisions.pdf
> 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.
>
> 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.
https://blog.cloudflare.com/radius-udp-vulnerable-md5-attack/ provides
additional detail, including:
> The IETF is an important venue for standardizing network protocols
> like RADIUS. The IETF’s radext working group is currently considering
> an initiative to deprecate RADIUS/UDP and create a “standards track”
> specification of RADIUS over TLS or DTLS, that should help accelerate
> the deployment of RADIUS/TLS in the field. We hope that our work will
> accelerate the community’s ongoing efforts to secure RADIUS and reduce
> its reliance on MD5.
https://www.blastradius.fail/ has further details from the researchers.
https://www.freeradius.org/security/ provides a lengthy response from the
FreeRADIUS maintainers.
--
-Alan Coopersmith- alan.coopersmith@...cle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
