Security Tracking Issue

Flaw:

forgery attack
https://bugzilla.redhat.com/show_bug.cgi?id=2263240

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@cs.ucsd.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.

~~~