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/radiusandmd5collisions.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 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 () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

A fundamental design flaw within the RADIUS protocol has been proven to be exploitable, compromising the integrity in the RADIUS Access-Request process. The attack allows a malicious user to modify packets in a way that would be indistinguishable to a RADIUS client or server. To be successful, the attacker must have the ability to inject themselves between the client and server.

In freeradius, the EAP-PWD function computepasswordelement() leaks information about the password which allows an attacker to substantially reduce the size of an offline dictionary attack.

In freeradius, when an EAP-SIM supplicant sends an unknown SIM option, the server will try to look that option up in the internal dictionaries. This lookup will fail, but the SIM code will not check for that failure. Instead, it will dereference a NULL pointer, and cause the server to crash.

A flaw was found in freeradius. A malicious RADIUS client or home server can send a malformed abinary attribute which can cause the server to crash.

In FreeRADIUS 3.0.x before 3.0.20, the EAP-pwd module used a global OpenSSL BNCTX instance to handle all handshakes. This mean multiple threads use the same BNCTX instance concurrently, resulting in crashes when concurrent EAP-pwd handshakes are initiated. This can be abused by an adversary as a Denial-of-Service (DoS) attack.

A flaw was found in the implementation of EAP-pwd in FreeRADIUS. An attacker could initiate several EAP-pwd handshakes to leak information, which can then be used to recover the user's WiFi password by performing dictionary and brute-force attacks.

References:

https://wpa3.mathyvanhoef.com/#new

A flaw was found in the implementation of EAP-pwd in FreeRADIUS. An attacker could initiate several EAP-pwd handshakes to leak information, which can then be used to recover the user's WiFi password by performing dictionary and brute-force attacks.

References:

https://wpa3.mathyvanhoef.com/#new

DISPUTED It was discovered freeradius up to and including version 3.0.19 does not correctly configure logrotate, allowing a local attacker who already has control of the radiusd user to escalate his privileges to root, by tricking logrotate into writing a radiusd-writable file to a directory normally inaccessible by the radiusd user. NOTE: the upstream software maintainer has stated "there is simply no way for anyone to gain privileges through this alleged issue."

A vulnerability was found in FreeRadius. An attacker can reflect the received scalar and element from the server in it's own commit message, and subsequently reflect the confirm value as well. This causes the adversary to successfully authenticate as the victim. Fortunately, the adversary will not posses the negotiated session key, meaning the adversary cannot actually perform any actions as this user.

A vulnerability was found in FreeRadius. An invalid curve attack allows an attacker to authenticate as any user (without knowing the password). The problem is that on the reception of an EAP-PWD Commit frame, FreeRADIUS doesn't verify whether the received elliptic curve point is valid.

A vulnerability was found in pamradius : the password length check was done incorrectly in the addpassword() function, resulting in a stack based buffer overflow.

This could be used to crash (DoS) an application using the PAM stack for authentication.

An FR-GV-304 issue in FreeRADIUS 3.x before 3.0.15 allows "DHCP - Buffer over-read in frdhcpdecodesuboptions()" and a denial of service.

An FR-GV-303 issue in FreeRADIUS 3.x before 3.0.15 allows "DHCP - Infinite read in dhcpattr2vp()" and a denial of service.

An FR-GV-302 issue in FreeRADIUS 3.x before 3.0.15 allows "Infinite loop and memory exhaustion with 'concat' attributes" and a denial of service.

An FR-GV-301 issue in FreeRADIUS 3.x before 3.0.15 allows "Write overflow in data2vpwimax()" - this allows remote attackers to cause a denial of service (daemon crash) or possibly execute arbitrary code.

An FR-GV-206 issue in FreeRADIUS 2.x before 2.2.10 and 3.x before 3.0.15 allows "DHCP - Read overflow when decoding option 63" and a denial of service.

An FR-GV-205 issue in FreeRADIUS 2.x before 2.2.10 allows "DHCP - Buffer over-read in frdhcpdecodeoptions()" and a denial of service.

An FR-GV-204 issue in FreeRADIUS 2.x before 2.2.10 allows "DHCP - Memory leak in frdhcpdecode()" and a denial of service.

An FR-GV-203 issue in FreeRADIUS 2.x before 2.2.10 allows "DHCP - Memory leak in decodetlv()" and a denial of service.

An FR-GV-202 issue in FreeRADIUS 2.x before 2.2.10 allows "Write overflow in radcoalesce()" - this allows remote attackers to cause a denial of service (daemon crash) or possibly execute arbitrary code.

An FR-GV-201 issue in FreeRADIUS 2.x before 2.2.10 and 3.x before 3.0.15 allows "Read / write overflow in makesecret()" and a denial of service.

The TLS session cache in FreeRADIUS 2.1.1 through 2.1.7, 3.0.x before 3.0.14, 3.1.x before 2017-02-04, and 4.0.x before 2017-02-04 fails to reliably prevent resumption of an unauthenticated session, which allows remote attackers (such as malicious 802.1X supplicants) to bypass authentication via PEAP or TTLS.

The EAP-PWD module in FreeRADIUS 3.0 through 3.0.8 allows remote attackers to have unspecified impact via a crafted (1) commit or (2) confirm message, which triggers an out-of-bounds read.

Off-by-one error in the EAP-PWD module in FreeRADIUS 3.0 through 3.0.8, which triggers a buffer overflow.

The EAP-PWD module in FreeRADIUS 3.0 through 3.0.8 allows remote attackers to cause a denial of service (NULL pointer dereference and server crash) via a zero-length EAP-PWD packet.

FreeRADIUS 2.2.x before 2.2.8 and 3.0.x before 3.0.9 does not properly check revocation of intermediate CA certificates.

Pierre Carrier reported a stack-based buffer overflow flaw in the FreeRADIUS rlmpap module. An authenticated user could trigger this issue by creating a large password, causing FreeRADIUS to crash. The stack protector and SSP variable re-ordering protections should help prevent this issue from being used to execute arbitrary code.

Upstream fixes: 2.x: https://github.com/FreeRADIUS/freeradius-server/commit/0d606cfc29a 3.x: https://github.com/FreeRADIUS/freeradius-server/commit/ff5147c9e5088c7 master: https://github.com/FreeRADIUS/freeradius-server/commit/f610864d4c8f51d

References: http://lists.freebsd.org/pipermail/freebsd-bugbusters/2014-February/000610.html

Pierre Carrier reported a stack-based buffer overflow flaw in the FreeRADIUS rlmpap module. An authenticated user could trigger this issue by creating a large password, causing FreeRADIUS to crash. The stack protector and SSP variable re-ordering protections should help prevent this issue from being used to execute arbitrary code.

Upstream fixes: 2.x: https://github.com/FreeRADIUS/freeradius-server/commit/0d606cfc29a 3.x: https://github.com/FreeRADIUS/freeradius-server/commit/ff5147c9e5088c7 master: https://github.com/FreeRADIUS/freeradius-server/commit/f610864d4c8f51d

References: http://lists.freebsd.org/pipermail/freebsd-bugbusters/2014-February/000610.html

modules/rlmunix/rlmunix.c in FreeRADIUS before 2.2.0, when unix mode is enabled for user authentication, does not properly check the password expiration in /etc/shadow, which allows remote authenticated users to authenticate using an expired password.