1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. fapi
  4. Issues

Decide on what to do for A. Cuckoo’s Token Attack

Issue #525 resolved
Nat Sakimura created an issue

See https://arxiv.org/pdf/1901.11520.pdf for Cuckoo’s Token Attack.

See #524 as well.

Comments (20)

  2. Joseph Heenan

    As we require the use of OIDC discovery, I think the attack vector here is that the attacker convinces the client to onboard a malicious AS that the client believes is trusted by the honest RS?

    The other scenarios I can think of would seem to be things that are out of scope, like the attacker comprising an honest AS that is trusted by the RS.

    The suggested mitigation from the FAPI1 analysis is:

    To prevent the use of leaked access tokens, the client should include, in the request to the RS, the identity of the AS the client received the access token from. The client can take this value from the second id token.

    (For FAPI2, instead of ‘value from the second id token’, it would be ‘iss value in the authorization response’ I think - as there may not be an id_token.)

    The client using distinct DPoP (or self-signed MTLS) keys that are unique to each AS would prevent it too, but that doesn’t possible in most Openbanking ecosystems that seem to want to use CA-signed TLS certs.

  3. Tim Würtele

    As we require the use of OIDC discovery

    The FAPI 2.0 Attacker Model actually defines OIDC Discovery/OAuth AS Metadata to be a trusted source of information. However, my understanding of FAPI 2.0 Security Profile is: ASs are required to offer metadata, but clients are not required to retrieve (& use) it.

    In addition, the FAPI 2.0 Attacker Model explicitly gives an attacker the capability to make the client use a wrong endpoint (A5), without going into detail how an attacker could achieve this in practice. If FAPI 2.0 wants to protect against such an attacker, it does not really matter how an attacker would force the client to use the wrong endpoint.

  4. Joseph Heenan

    However, my understanding of FAPI 2.0 Security Profile is: ASs are required to offer metadata, but clients are not required to retrieve (& use) it.

    It does seem that way. I think this is likely an accidental omission that we should fix.

    In addition, the FAPI 2.0 Attacker Model explicitly gives an attacker the capability to make the client use a wrong endpoint (A5), without going into detail how an attacker could achieve this in practice. If FAPI 2.0 wants to protect against such an attacker, it does not really matter how an attacker would force the client to use the wrong endpoint.

    That is a fair point.

    ‌

  5. Torsten Lodderstedt

    To me A5 seems to result in a pretty strong attacker. Do we really think we need to defend against such attackers?

  7. Nat Sakimura reporter

    Call note from July 27 call.

    Add security consideration for this attack. Requires a malicious AS which is unlikely to happen in many regulated ecosystems, but may be a problem for open ecosystems.

    FAPI 1 has text regarding this attack.

    An attacker could try to trick a client under his control to make use of the access token as described in [FAPISEC] ("Cuckoo's Token Attack" and "Access Token Injection with ID Token Replay"), but these attacks additionally require a rogue AS or misconfigured token endpoint.

    Bad AS could advertise endpoints for honest RS. Assumes that the trust anchor for the ecosystem fails.

    Mostly affects clients that support dynamic registration so we should put some security consideration around that.

  8. Joseph Heenan

    As noted on today’s call, there is a slightly easier exploit where the ecosystem hosts a ‘resource endpoint discovery document’ on the AS, as I believe UK OpenBanking did and I believe Daniel commented yes.com also do.

  9. Daniel Fett

    That’s correct, Joseph.

    I think we agreed that this attack should be documented. Key points:

    • Conditions for the attack to work:

      • AS under an attacker’s control (similar to the precondition for mix-up attacks),
      • Attacker can bring a client to use an uncompromised resource endpoint,
      • an access token was leaked that is valid for this client to access this resource endpoint,
      • Client uses the same sender-constraining key material on that resource endpoint both in the interaction from which the access token was leaked as well as in the new, attacker-controlled interaction.

    • When DPoP is used with ‘fresh’ keys for each transaction, or MTLS is used with per-AS/per-Issuer certificates, the latter precondition is not given - attack won’t work.

    • When resource endpoints are closely coupled with the ASs, e.g., through an uncompromised configuration file, the attack won’t work.
    • When there is no way for an attacker to compromise an existing AS or introduce new malicious ASs, the attack won’t work (this is less likely for large ecosystems).
    • Another idea would be to send a header to the resource server containing the issuer URL. Assuming a compromised AS has a different issuer URL than an honest one, the resource server could detect the mismatch.

    For the analysis, we need to find out what the least ‘invasive’ way is to avoid running into this attack.

    Either

    1. Only allow the ‘correct’ resource endpoints for ASs
    2. Assume DPoP with fresh keys and MTLS with per-issuer certificates
    3. Sending the issuer identity to the resource server

    I think (1.) would be better, as (2.) is more likely to hide other potential attacks. (3) is an option if we actually want to introduce this header in the spec, but that would be a not-yet-standardized extension.

    ‌

  10. Pieter Kasselman

    @Daniel Fett what is the trust model for the AS here? Can an attacker just stand up a random AS, or would it need to do some extra work to get the rogue AS accepted into a trust framework or added to some kind of “allow list”? If some trust relation is needed, it is perhaps worth pointing out that the attacker needs to control an AS that the resource server trusts and the mechanism through which the trust is managed and established, makes the attack more difficult?

  11. Joseph Heenan

    Both the rogue AS and the trusted AS need to be ones the OAuth client trusts to issue an access token for the RS endpoint.

    The RS does not need to trust the rogue AS - the access token was created by a trusted AS, then leaked and obtained by the attacker and the rogue AS is used to inject the access token into the OAuth client in a session owned by the attacker (as a way around sender-constraining of the access token).

    ‌

  13. Pieter Kasselman

    Thanks @Daniel Fett and @Joseph Heenan would it be useful to point out that there needs to be a trust relationship between the AS and the client, or is the expectation that the client enters into a trust relationship with AS relatively easily?

  14. Joseph Heenan

    Yes, although it needs a little bit of careful wording. There are alternative variants of the attack where the attacker compromises a “less secure” AS in an ecosystem, and can potentially leverage that to use leaked access tokens issued by a more secure AS. And a few other variants that rely on social engineering someone responsible for managing the client’s configuration. (I’m not sure I can fully describe all the possible vectors.)

    ‌

  15. Pieter Kasselman

    Perhaps somehting like

    “A pre-condition for this exploit requires that the attacker has control of an AS trusted by the client. An attacker may obtain control of an AS by compromising the security of an AS or by acting as an AS and establishing a trust relationship with a client using social engineering or by compromising the client”

  17. Brian Campbell

    Maybe I’m holding on too much to the ‘solution’ that first came to my mind but per-issuer DPoP keys / MTLS certificates would be sufficient and are only needed in the case that a client will use more than one AS to acquire access tokens for use at the same RS. That same RS piece being one more precondition to the considerable list of preconditions.

    ‌

  21. Log in to comment
Assignee
Type
bug
Priority
major
Status
resolved
Component
FAPI2: Security Profile
Milestone
–
Votes
0
Watchers
5
Jira: the preferred issue tracker for Bitbucket. Join the team!