I decided to post a short write-up on this MSRC case as this case was first one I worked with co-contributor @KimJamia
Consent hack timeline
- Initial submission Q1 2022
- Microsoft proactively addressed this issue and a fix for this issue was released on 3/17
Bypass consent framework for multi-tenant apps.
- Get user attributes with access token, and refresh-token for scopes of the application
I discovered this originally in end of 2021 by accident, but thought it was misconfiguration on my side, as I was requesting later additional scopes, which would ”fix” the behavior.
In early 2022 Kim Jämiä had discovered the same behavior independently, and thought also, that it is publicly known quirky behavior. We confirmed both, that this should not be desired behavior, as it allows bypassing the consent, and does not result in any service principal in the victim tenant, thus we decided that we should submit this as a case to MSRC
Combination of knownClientApplications and preAuthorizedApplications attribute allowed bypassing consent for 3rd party scopes that are defined using two of these attributes (and two app registrations)
- Text from initial submission: If we look at the explanation (links below 📑) this seems by design, but results in edge case, where multi-tenant applications can get user tokens without any consent being initiated.
”preAuthorizedApplications do not require the user to consent to the requested permissions. Permissions listed in preAuthorizedApplications do not require user consent. However, any additional requested permissions not listed in preAuthorizedApplications require user consent”
Login parameters example
resource:"41f71e46-cf85-474b-8c6d-09e5b653592a", scope:"https://api-26965.thx.dewi.red/hacked offline_access profile openid email", client_id:"41f71e46-cf85-474b-8c6d-09e5b653592a", redirect_uri, response_mode:"query", response_type:"code", endpoint:2, tenantId:"common",
Be sure to follow MSRC on twitter, and stay tuned for more security research on my blog!