Recipient Arrangement Revocation Endpoint exposed to Mixup Attack

[biza-io]

Description

The Arrangement Revocation endpoint accepts a cdr_arrangement_id which is not cryptographically bound to the client assertion generated by the Holder.

Ie. From the current Standards

  client_id=s6BhdRkqt3&
  client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
  client_assertion=eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyNDU2In0.ey ...&
  cdr_arrangement_id=5a1bf696-ee03-408b-b315-97955415d1f0

In addition the Arrangement Revocation endpoint hosted by Recipients does not require MTLS and the expiry of the JWT is not prescribed (in fact it is referenced as "ID Token").

As a consequence, should an outbound client assertion be collected or retrieved along the way it is possible to issue, potentially forever, revocation requests to Data Recipients for any number of cdr_arrangement_id's from any source location for as long as the collected JWT (from either form or header parameters depending on the reading of the Standards) has not expired.

This particular vector is explicitly covered in FAPI 1 Part 2 5.2.2(10) with respect to the authorisation endpoint:

10. shall only use the parameters included in the signed request object passed via the request or request_uri parameter;

As far as we can see this vulnerability has not been identified or noted at any point and indeed this endpoint may not have existed at the time of the last independent security review.

Area Affected

ADR hosted Recipient Revocation Endpoint.

Change Proposed

Armouring the arrangement id in its current state will likely have a high implementation difficulty as the Standards utilise a bespoke interpretation of RFC6750 whereby the Bearer token is designated as a JWT with customised fields leveraging Register specific details (Holder Brand ID) for the iss. The Standards are even more ambiguous because the non-normative example appears to simulate a private_key_jwt like method - this has resulted in Holder implementations actually shipping both a Bearer token and the client assertion as form fields exacerbating the exposure of this attack vector. Nonetheless, the prescribed JWT structure is such that it is somewhat challenging to align with RFC7523 (which would mandate client_id inside the JWT).

Regardless, the following options are outlined:

1. Include cdr_arrangement_id in the Bearer Authorization header and require that the form posted arrangement identifier and the JWT included one match
2. Replace the cdr_arrangement_id parameter with cdr_arrangement_jwt and include the cdr_arrangement_id within a freshly signed JWT containing CDR specific attributes while continuing to segregate authentication logic from business logic.

[CDR-API-Stream]

Thanks @biza-io, given the issue, this change request will be brought into the current maintenance iteration for consultation at next Wednesday's maintenance call.

1. Whilst there is a possibility of mixup attack, what do you consider as the key security risks and threat vectors to achieve this where the confidential ADR client is authenticated with the DH, the cdr_arrangement_id must be matched to the authenticating client and trust is managed through the Register?
2. Is @biza-io recommending one of the options presented?
3. Which option is considered the simplest to adopt for existing implementations?

[biza-io]

Hi @CDR-API-Stream,

Firstly, the term client assertion and self-signed jwt are used somewhat interchangeably in our response because the Recipient hosted revocation endpoint is effectively a JWT client assertion being delivered via a Bearer token (although examples indicate via form parameters).

Secondly, we wish to note there is no documented Responsible Disclosure guidance for any part of the CDR. Guidance and public documentation on this more broadly for the Standards and Participants would be appreciated.

Thanks @biza-io, given the issue, this change request will be brought into the current maintenance iteration for consultation at next Wednesday's maintenance call.
1. Whilst there is a possibility of mixup attack, what do you consider as the key security risks and threat vectors to achieve

This is a lateral movement vulnerability utilising a JWT version of the venerable "pass the ticket" method in Kerberos environments.

this where the confidential ADR client is authenticated with the DH

As stated in the original issue should an outbound client assertion be collected or retrieved along the way.

The:

1. delivery pattern prescribed (inside a header) coupled with;
2. likely delivery path via potentially many internet exposed endpoints (proxies, firewalls, WAFs, acceleration devices etc) and pathways (CDNs, logging devices etc) on both sides delivered to;
3. internet based targets using Public CA trust chains and;
4. optionally combinedwith no mandated requirement for Recipients to utilise DNS spoofing protections (ie. DNSSEC)

Means that this communication path is possibly the most exposed to interception in the CDR. Even the authorisation endpoint is headed towards needing to be "port knocked" via a PAR request before being functional.

In FAPI comms such exposure is countered by the combination of mandating MTLS to sender constrain tokens and parameters are armoured by virtue of the content being signed. In essence while the JWT itself is intended to be protected there are a variety of other mechanism in play so that even if it is disclosed the call remains secure - these mechanisms do not apply to the Recipient hosted endpoint.

the cdr_arrangement_id must be matched to the authenticating client

CDR Arrangement Identifier is not considered a secret and, as such, is available in consumer dashboards on both sides either explicitly (displayed to the user) or implicitly (used as a handle in API calls). This significantly increases the likelihood that arrangement identifiers can be collected en-masse using client side attacks of various types via Consumer devices.

trust is managed through the Register?

There is no Register trust involved as the call is done via TLS to the Data Recipient such that no transport level validation is possible (nor possible without ADRs mandating MTLS) and assumes the client assertion is collected and still valid (which it may be, forever, as no expiry time is specified).

2. Is @biza-io recommending one of the options presented?

It is difficult to provide a recommendation as this endpoint has no underpinning international standards or prescribed security best practice applied nor does it appear to have had formal analysis done. While Biza.io are specialists in the CDR, members of OpenID Foundation and participants in the FAPI Working Group, we are not CREST certified and consequently penetration testing is not our primary objective, we effectively identified this issue during standard secure coding review related to work associated with #128. We recommend the DSB secure a suitably qualified professional opinion.

Our general advice would be to separate authentication logic from business logic which would be option (2) but this means that a Recipient will need to perform two validations, potentially doubling the exposure to acknowledged and accepted DDOS exposure.

With reference to the somewhat prescient issue 196, a third option may be to mandate MTLS at the ADR endpoint however this may force a significant change in architecture for both Holders and Recipients. Such a requirement would likely require an additional attribute within the Register to facilitate the advertisement of an MTLS endpoint for Data Recipients coupled with integration by Holders to utilise such information.

3. Which option is considered the simplest to adopt for existing implementations?

As stated Armouring the arrangement id in its current state will likely have a high implementation difficulty not least of which because it involves the alteration of a live endpoint carrying a legal obligation. Option 2 would allow for Data Recipients to implement both methods concurrently and for Data Holders to migrate to the new target state in line with a likely FDO.

[CDR-API-Stream]

Thanks for the feedback @biza-io. After reviewing this issue further there are a few things that would be worth clarifying that may impact the recommended solution.

The use of client assertion is only expected for an ADR calling the DH hosted version of the arrangement revocation endpoint. The non-normative example in the standards shows the DH exposed version of the endpoint. This highlights that adding a non-normative example for the ADR hosted version would be a good addition to the standards and may help reduce confusion.

The ADR hosted version of this endpoint uses the self-signed JWT pattern which includes a requirement to prevent token reuse. This limits the risk somewhat as a captured token could only be used once and cannot be reused in a playback style attack.

The DH version uses client assertion (called private key jwt in the standards). This is protected by MTLS as required by FAPI and also includes a requirement to prevent token reuse.

This may ameliorate the risk somehwat but the core issue still remains that the arrangement ID is not cryptographically tied to a party and, unlike tokens, may be able to scraped from other sources such as CDR Receipts.

It does potentially influence the preferred solution, however. If option 1 was adopted it would require not only that the arrangement ID is added to the client assertion for the DH hosted endpoint but also to the self-signed JWT for the ADR hosted version. Option 2 would be able to applied consistently to both the DH and ADR endpoints. It would also have the advantage that it would allow for easier phase in as, if the suggested cdr_arrangement_jwt is present it would be checked but if it isn’t then current behaviour would prevail.

Does this align with your understanding @biza-io?

[CDR-API-Stream]

After discussion with the community throughout the maintenance iteration meetings on this issue, the proposed solution for feedback and discussion in the call today, is as follows:

1. We would add a note to the standards indicating that token reuse is not allowed.
2. We would adopt option 2 in the change proposed by @biza-io:

Replace the cdr_arrangement_id parameter with cdr_arrangement_jwt and include the cdr_arrangement_id within a freshly signed JWT containing CDR specific attributes while continuing to segregate authentication logic from business logic.

A strategic long-term consultation on secure event messaging and notifications will be consulted on in 2022.

[brett-frollo]

Hello, Brett here from Frollo. We would like to note that the client_assertion sent along with a DH initiation revocation request must contain a jti claim, and that jti claim cannot be reused and must be validated by the DR in order to stop replay attacks. So the client_assertion is already not able to be used more than once.

Having said that, we are happy to support Option 2 and the implementation difficulty on DRs is very minor.

[perlboy]

@brett-frollo jti reuse was discussed in the implementation call. There is no explicit statement that it cannot be reused. The Standards state it can be used to prevent reuse (RFC7519 says the same thing) and that it MUST be used only once (by Holders). It does not state that Recipients MUST enforce such things. The discussion in the call revolved around how long Recipients are storing observed jti's as Holders are required to keep sending them until a Recipient returns from an outage (which currently has no maximum allowance and therefore is effectively "infinite"). Case in point is that issue 428 now involves some revocation notifications being backlogged for >30 days.

Footnote: This relates to self-signed authentication versus private key jwt client assertions. I'm dubious about calling self-signed authentication a "client assertion" because it's easily confused with JWT client assertions (which it really isn't).

[CDR-API-Stream]

This change was incorporated into release v1.15.0. Refer to Decision 212 for further details.