CVE-2024-3596: PAN-OS: CHAP and PAP When Used with RADIUS Authentication Lead to Privilege Escalation (Severity: MEDIUM)

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.

— Red Hat

CERT/CC: CVE-2024-3596 RADIUS Protocol Spoofing Vulnerability

— Microsoft

RADIUS Protocol under RFC 2865 is susceptible to forgery attacks by a local attacker who can modify any valid Response (Access-Accept, Access-Reject, or Access-Challenge) to any other response using a chosen-prefix collision attack against MD5 Response Authenticator signature.

— Debian

This vulnerability allows an attacker performing a meddler-in-the-middle attack between Palo Alto Networks PAN-OS firewall and a RADIUS server to bypass authentication and escalate privileges to ‘superuser’ when RADIUS authentication is in use and either CHAP or PAP is selected in the RADIUS server profile.

CHAP and PAP are protocols with no Transport Layer Security (TLS), and hence vulnerable to meddler-in-the-middle attacks. Neither protocol should be used unless they are encapsulated by an encrypted tunnel. If they are in use, but are encapsulated within a TLS tunnel, they are not vulnerable to this attack.

For additional information regarding this vulnerability, please see https://blastradius.fail.

— Palo Alto Networks