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.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
