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

...

...

This non-normative companion to the security extension specification has not yet been reviewed.

 

Table of Contents

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.

...

1.  Eve begins the transaction by requesting the photo.
2. 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.
3. 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 The attacker must know the victim and successfully trick him . Further, UMA can sometimes be used in an alternate way for this attack to be successful. Also, some authorization services could choose other ways to let Bob be identified automatically, without having to visit the authorization service, and this alternate way these others ways is not susceptible to the vulnerability.Therefore, the attack. 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 that authorization services have the option to implement if they determine this level of enhanced 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?)for their circumstances.

Thanks to Sarah Squire for contributing this writeup!

...

Discussion 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

...

See the complete attack sequence in the extension specification (add link).

The attack relies on the attacker initiating the resource access attempt, phishing the legitimate requesting party into completing one or more claims-gathering flows at the authorization server, and then taking over the session once again to accept an RPT that contains the desired authorization data that allows inappropriate access to the resource.

Because the victim's client already has an AAT, the victim will notice nothing wrong; it will look 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 even be provided to the

...

authorization server automatically through single sign-on.

...

In the case of the attacker controlling the victim's network access,

...

the client will not even see a spurious/failed request

...

.

...

The reason the attacker is able to construct a successful RPT request after the victim has completed the necessary one or more claims-gathering cycles is that every parameter – state, authorization_state, and ticket

...

Discussion

 – is known in advance. Analyzing which could help distinguish the context:

• The state parameter provides no support to distinguish the attacker's transaction context and the victim's context

...

• . 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

...

• provides no support to distinguish the two contexts because UMA V1.0 and V1.0.1 (and possible future minor versions) 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 returns a need_info response with no error_details block or no specific redirect_user hint 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 the redirection cycle to be repeated multiple times before the victim is finally returned to the client. In other words, in Step 7 described above, the "post-claims-gathering actions" may include additional claims-gathering.

...

Discussion of the Provided Mitigation and Others Considered

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 receiveda new requesting party claims endpoint at the authorization server that behaves differently from the original one, in that it returns a ticket parameter value that is unguessable and securely random rather than the same value it was given originally; the authorization server also invalidates the original ticket. 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 request for an RPT and authorization data in step 7 in the attack sequence.

The extension specification has been designed to sit alongside the versions of UMA extant at the time of the extension's writing (UMA V1.0 and UMA V1.0.1) and to be usable with authorization servers using these versions and any similar version susceptible to the identical attack. The specification is a true extension in that its requirements supersede several requirements in the original specification. As the Work Group works on its 2016 roadmap items, it will take into consideration how to fold this and any other extension specifications into future versions of the main UMA specifications.

Discussion

Other technically suitable solutions were examined and rejected.

Unsuitable Proposals

The following mitigation proposals were analyzed and found technically unsuitable.

• Gathering additional claims that strongly authenticate or identify the legitimate requesting party: Since the victim completes any claims-gathering under his own session ID before the attacker takes over again, the seemingly strongest of protections at the claims-gathering level make no difference.
  
• Warning the victim what the client has redirected him to the authorization server for: It is already good practice for the authorization server to give cues in interactive flows as to the client's purpose, but this is known to be insufficient as a mitigation in current potential phishing situations.

Other Proposals Not Chosen

The following mitigation proposals were found unsuitable for the Work Group to specify formally for various reasons.

• Adding a new query parameter to the AS authorization server response URI: It  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 s design principle 10 prefers for complexity to be borne by the AS authorization server 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 Combining trust elevation methods: As the extension specification notes, only the requesting party claims endpoint is susceptible to the session fixation attack. It is possible for the authorization server to combine 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 situationsauthentication context-based trust elevation in a single overall UMA flow (through a sequence of need_info responses) as a method of sufficiently distinguishing attacker and victim transaction context to mitigate the session fixation attack. For example, if the authorization server needed requesting party Bob to meet two policy conditions, one regarding his strongly authenticated identity which could be met through knowledge of AAT session context, and another regarding his current professional certification status which could only be met through an interactive claims-gathering flow at a certifying body, this combination could be apropos. However, not every UMA ecosystem will find such combinations fit for their trust elevation purposes, and even in those cases, no formal specification seems warranted.

To read about other types of attacks for which strong authentication through authentication context-based trust elevation may apply, see this section of the UMA Security Considerations.