Affected Vendor IETF Every vendor who implements a product supporting RADIUS Affected Product RFC 2865 Affected Version RFC 2865 Significant ICS/OT impact? no Reporter Nadia Heninger [nadiah.edu] University of California San Diego Vendor contacted? yes We have reached out to the IETF. This vulnerability will affect a large number of vendors and we have not reached out to any individual vendors yet. Description We have an efficient forgery attack against the Response Authenticator used to authenticate RADIUS server Access-Accept or Access-Reject messages. This is a protocol vulnerability against RFC 2865 and applies to RADIUS/UDP. It allows a man-in-the-middle attacker to forge a valid Access-Accept response to a client request that has been rejected by the RADIUS server, and gain access to the network resources and devices for which the RADIUS client may authorize users. The Response Authenticator is an MD5 hash of values from the RADIUS client request and server response together with a fixed shared secret (unknown to our attacker) that is shared between the RADIUS client and server. The first byte of an Access-Accept and Access-Reject message differ. The attacker executes a so-called chosen-prefix collision attack on MD5 to change the message type in the first byte and any relevant packet attributes while ensuring that the Access-Reject and forged Access-Accept both produce the same Response Authenticator. Once an MD5 chosen-prefix hash collision has been computed, any fixed value appended to the two messages will continue to produce an MD5 hash collision. In particular, the attacker can compute a collision with known values such that when the client or server append the secret to compute the Response Authenticator, it will still produce the same hash value. Computing an MD5 chosen-prefix hash collision requires predicting the Access-Reject message and appending as few as 80 bytes of collision block gibberish to the Access-Request sent to the server. In our attack, the attacker encapsulates this collision-block gibberish in Proxy-State attributes that are required by the RFC to be returned by the server in its response and are hence also present in the Access-Reject produced by the server. These gibberish values ensure the Response Authenticator computed from the Access-Reject and will be a correct Response Authenticator for the forged Access-Accept. Exploit To exploit this vulnerability, an attacker needs man-in-the-middle network access between the RADIUS client and server, and the client and server must be using RADIUS/UDP to communicate. The attacker also needs to be able to trigger a RADIUS client Access-Request, by for example entering a username and (incorrect) password at a login prompt on a victim device. The simplest case is when the client is using PAP authentication. The attacker observes the Access-Request packet (in particular the random ID and Request Authenticator values included in the request) and predicts the attributes that will be returned in the Access-Reject response that is expected to be returned by the server. The attacker then computes an MD5 chosen-prefix collision online, before the client times out its request. With our computing power, we are currently able to compute such a collision in as little as 5 to 6 minutes; we expect to continue to improve this, and a well-resourced attacker with the ability to implement this attack on FPGAs would certainly be able to improve this time to seconds. Once the attacker has computed the MD5 collision, the attacker inserts the corresponding collision blocks into one or more Proxy-State attributes in the request, and removes any Message-Authenticator attributes from the request. (This is allowed and undetectable when using PAP authentication.) The attacker sends this modified client request to the RADIUS server. The attacker then receives the expected Access-Reject response from the RADIUS server, and copies the Response Authenticator value from the Access-Reject to the colliding Access-Accept packet that it forges. This packet will include some Proxy-State attributes containing the collision block gibberish; we have verified that these attributes are accepted by clients. The attacker then forwards its modified Access-Accept response to the client, which should successfully let the attacker log in. We have attached a file poc.md showing logs and values with a sample colliding request. Impact An attacker gains access to any resource for which RADIUS is used for authentication/authorization. RADIUS/UDP appears to be commonly used within enterprise networks and organizations to provide admin access to routing infrastructure, user logins for VPNs, for Wi-Fi access via WPA-enterprise, and as a lightweight authentication mechanism for a variety of networked devices and hardware. RADIUS is supported by cloud authentication services like Duo and Okta as well. Discovery This vulnerability was discovered by Mike Milano, Sharon Goldberg, Nadia Heninger, Dan Shumow, Marc Stevens, Miro Haller, and Adam Suhl. We discovered it by reading the RFC, examining the behavior of the RADIUS client and server implementations we currently have access to (FreeRadius, Okta, a Cisco ASA 5505), and optimizing Marc Stevens's Hashclash MD5 collision software for our particular case. Has been exploited? no Is public? no Disclosure Plans? yes We plan to submit a paper to the Usenix Security conference. The paper will be confidential except to the program committee. The submission deadline is February 8 and the conference takes place August 14-16. We are fine with coordinating the public disclosure deadline with vendors.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support Red Hat Enterprise Linux 8.6 Update Services for SAP Solutions Red Hat Enterprise Linux 8.6 Telecommunications Update Service Via RHSA-2024:4826 https://access.redhat.com/errata/RHSA-2024:4826
This issue has been addressed in the following products: Red Hat Enterprise Linux 9.2 Extended Update Support Via RHSA-2024:4828 https://access.redhat.com/errata/RHSA-2024:4828
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.8 Extended Update Support Via RHSA-2024:4829 https://access.redhat.com/errata/RHSA-2024:4829
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.4 Telecommunications Update Service Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support Via RHSA-2024:4874 https://access.redhat.com/errata/RHSA-2024:4874
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.2 Advanced Update Support Via RHSA-2024:4913 https://access.redhat.com/errata/RHSA-2024:4913
This issue has been addressed in the following products: Red Hat Enterprise Linux 9.0 Update Services for SAP Solutions Via RHSA-2024:4912 https://access.redhat.com/errata/RHSA-2024:4912
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Extended Lifecycle Support Via RHSA-2024:4911 https://access.redhat.com/errata/RHSA-2024:4911
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2024:4936 https://access.redhat.com/errata/RHSA-2024:4936
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2024:4935 https://access.redhat.com/errata/RHSA-2024:4935