Understanding the Session Fixation Attack on UMA Claims-Gathering and the Provided Mitigation

On January 27, 2016, an issue was reported that identified a vulnerability in the UMA protocol. The UMA Work Group immediately set about analyzing the attack, possible mitigations under consideration, and similar cases; choosing an optimal mitigation; and developing specification text (add link) defining that mitigation. This companion non-normative document provides additional background information.

Familiarity with UMA terms and concepts is recommended for reading this document.

Many thanks to the submitters of the issue and the Work Group for its quick action!

High-Level Introduction

Here is a high-level description of the problem and the solution, suitable for end-users of online services. (You don't need familiarity with UMA terms and concepts to read this section.)

Alice wants to share a photo with Bob, and only Bob. Eve would like to see the photo, but she is not allowed. Alice stores the photo on her resource server and protects it with her authorization server. She sets a policy stating that only Bob should have access to the photo.

In order for Bob to get access to the photo, the following three steps would be completed:

Bob begins his transaction by requesting the photo.
Bob identifies himself within the context of his transaction by visiting Alice's authorization service.
The authorization service grants access to the photo within the context of his transaction.

Eve would like to access the photo as well. She completes the following steps:

Eve begins the transaction by requesting the photo.
Rather than identifying herself, Eve phishes Bob and convinces him to identify himself within the context of her transaction by visiting Alice's authorization service.
The authorization server grants access to the photo within the context of Eve's transaction.

Because Eve’s attack involves a successful phishing event, this scenario is not considered a vulnerability in the classic sense. [true?] The attacker must know the victim and successfully trick him. Further, UMA can sometimes be used in an alternate way to let Bob be identified automatically, without having to visit the authorization service, and this alternate way is not susceptible to the vulnerability.

Therefore, the UMA Work Group has not made normative changes to the UMA Core specification at this time, but has developed an UMA extension specification to be used in contexts where a higher level of security is appropriate. (rather say: to be used only in contexts where visiting the authorization service to complete the process of seeking access is required?)

Thanks to Sarah Squire for contributing this writeup!

Technical Description of the Attack

Preconditions

The attacker (malicious requesting party) and the victim (innocent requesting party) both use an UMA client with the same client ID. it could be the same client instance or different client instances. The client is legitimate and uncompromised.
Both the attacker and the victim have AATs.
The victim is a human end-user.

Attack Sequence

The attacker attempts access to an UMA-protected resource at an RS that she should not be able to access.
The RS registers a requested permission; the AS returns a permission ticket; the RS returns a permission ticket (along with other data) to the client.
The client asks for authorization data and RPT at the AS; the AS returns a need_info response with redirect_user (or the client otherwise infers the requirement to redirect the victim's browser to the requesting party claims endpoint).
The client attempts to redirect the victim's browser to the requesting party claims endpoint, but the attacker prevents this redirection, and instead copies the redirect URL (optionally stripping off the state parameter), including a permission ticket query parameter, and passes it to the victim.
After being phished with the URL, the victim assists the AS in completing the claims-gathering process, for example, proving his identity and providing any other required claims in order to allow access to the desired resource. The victim notices nothing wrong; it looks like he's supplying claims to help launch a client he knows and trusts. In the case of long-lived cookies for, say, social networks, the victim’s claims could be provided to the AS automatically through single sign-on.
The AS redirects the victim back to the client. No relevant session is found in the client because either no state value or an incorrect state value is present on the request [correct?]. Therefore, the POST-redirect request fails. Alternatively, if an attacker controls the victim's network access, she can prevent all communication between victim and client, so the client doesn't see a spurious/failed request at all.
After the right amount of time has elapsed, the attacker simulates the post-claims-gathering actions in her client, ultimately receiving an RPT with sufficient authorization data, because every parameter of the post-claims-gathering endpoint (state, authorization_state, ticket) is known to the attacker.
The attacker gains access to the protected resource.

Discussion

The state parameter provides no support to distinguish the attacker's transaction context and the victim's context, as noted in the attack sequence. The victim's client simply fails when attempting to continue seeking access because the session was initiated by the attacker. The transaction context of record is the attacker's.

The ticket parameter also provides no support to distinguish the two contexts because UMA V1.0 and V1.0.1 require its value to be the same across the entire process of claims-gathering when a requesting party is seeking access to a particular resource. It could be said that the root problem of the session fixation is in the "fixed" nature of permission tickets in the cycle of 1) requesting party claims endpoint usage with a ticket parameter and 2) the response from the AS with the same ticket parameter repeated.

The attack is possible even if the AS does not return need_info with any particular hints to the client. Out-of-band agreements are possible between these two entities that can indicate that redirection is the next expected action.

It is possible for various types of claims-gathering flows to be repeated, or even for claims-gathering and other methods of trust elevation to be conducted in some "chain" prescribed by the AS. In other words, in Step 7 described above, the "post-claims-gathering actions may include additional claims-gathering and/or other trust elevation methods; in the former case, the same attack could be applied repeatedly.

No evidence was found, in our analysis, of other methods of trust elevation present in the UMA Core V1.0 or V1.0.1 specifications (pushed claims or step-up authentication) being susceptible to this attack.

The Provided Mitigation

The UMA Work Group has provided a mitigation of this attack in the form of an extension specification (add link).

The mitigation involves requiring the AS to return a ticket value to the client after completing its claims-gathering interaction with the requesting party (who may be a phishing victim) that is not the same as the ticket value the client originally gave to it, but rather a new securely random value. The mitigation also involves requiring the AS to invalidate the original ticket received. This has the effect of adding entropy to the round-trip permission ticket cycle during the claims-gathering flow, foiling an attacker's ability to know all the information necessary to simulate a true requesting party's post-claims-gathering messages in step 7 in the attack sequence.

Discussion

Other technically suitable solutions were examined and rejected.

Adding a new query parameter to the AS response URI: It is possible to keep the permission ticket value static and add a wholly new query parameter to add the needed entropy. The Work Group rejected this solution because it would add likely complexity to the client. Through implementation testing, it was confirmed that the solution chosen can actually reduce client complexity. UMA's design principle 10 prefers for complexity to be borne by the AS instead of the client.
Refactoring the UMA flow to remove the requesting party claims endpoint: It has been suggested in a different context to remove the requesting party claims endpoint altogether by collapsing it into a "standard OAuth" endpoint, which presents an opportunity to mitigate the attack a different way. Although this idea will be examined at a later date, the work item is sufficiently unrelated and large as to stand in the way of an expeditious mitigation for this attack.

Other technically unsuitable mitigations were examined and rejected.

Further authenticating the legitimate requesting party: Since the victim completes any claims-gathering and even authentication at the AAT level under his own session ID before the attacker takes over again, the strongest of authentication protection makes no difference. (However, for attacks for which strong authentication and similar mitigations apply, see this section of the UMA Security Considerations.)
Warning the victim what the client has redirected him to the AS for: It is already good practice for the AS to give cues as to the client's purpose, but this is weak and known to be insufficient in current potential phishing situations.