Full Report
OAuth (Open Authorization) is a standard authorization protocol. It is used all over the place with SSO providers to allow for a trusted entity, like Google or Facebook, to authenticate you to other sites. However, there are many footguns with this. The flow for OAuth is as follows: User tries to login to some site. It wants proof of their identity via an SSO provider, like Facebook. So, a redirect is made there. Upon redirecting with a logged in SSO provider user, a secret is passed to the user. They are then redirected back to the main website. The website will take the secret and communicate with the website on who they are. Now, the identity can be made to get information like their email and other things from the SSO provider. On Vidio, there was an issue with the verification of the access token for the redirect back to the main website. When Vidio would make a request to Facebook (the SSO provider in this case), there is an app identifier (AppID) for each app. However, it is the responsibility of the website (not Facebook) to ensure that the token belongs to their app. So, by providing a token from another Facebook app that the user controlled, they can return an arbitrary email, which results in an account takeover. This same attack method worked on bukalapak as well. In the case of Grammarly, they used an auth flow that was not vulnerable to this issue by default. By brute forcing parameters they were able to find a flow that was vulnerable to the method mentioned above. The SSO providers have custom attacks, which is super interesting. To me, it makes sense to force the app developer to specify the AppID instead of requiring manual verification; this is done on one of the Facebook flows already. Considering this, I'm sure many other providers and websites are vulnerable to this attack. Good vulnerability description!
Analysis Summary
# Vulnerability: OAuth Access Token Verification Bypass Leading to Account Takeover
## CVE Details
- CVE ID: Not explicitly assigned in the provided text. (Often specific implementation flaws like this receive CVEs based on the affected vendor/product, but none is listed here.)
- CVSS Score: Not explicitly calculated, but based on the impact (Account Takeover), this warrants a **High to Critical** score.
- CWE: CWE-287 (Improper Authentication) or CWE-613 (Broken Authorization) likely applies.
## Affected Systems
- Products: Web services utilizing the described OAuth redirection/verification flow, including **Vidio**, **Bukalapak**, and **Grammarly** (which was vulnerable via brute-forced specific auth flow).
- Versions: Any version/configuration where the application, not the SSO provider (like Facebook), is solely responsible for verifying that the returned access token unambiguously belongs to the originating application's AppID during the redirect callback.
- Configurations: OAuth implementations where the verification step fails to strictly enforce the expected AppID (Client ID) tied to the session/redirect state.
## Vulnerability Description
The vulnerability lies in the implementation of the OAuth callback *after* the user is redirected back from the SSO provider (e.g., Facebook). During the standard flow, after the SSO provider authenticates the user, it issues a secret/token which the application redeems for user identity information. The flaw occurs because the victim application failed to adequately verify that the access token returned belonged specifically to *their* registered application (AppID).
By controlling an arbitrary, legitimate Facebook application (AppID), an attacker could supply a valid token associated with that *different* app to the vulnerable service. The service would incorrectly trust this token, retrieve user data associated with the *victim's* SSO account but authorized under the *attacker's* AppID token, and subsequently grant the attacker control over the victim’s account counterpart on the target service (Account Takeover).
## Exploitation
- Status: **Exploited in the wild** (Confirmed against Vidio, Bukalapak, and Grammarly).
- Complexity: **Low to Medium**. The description implies that once the vulnerability pattern is understood, exploiting it involves crafting specific token requests.
- Attack Vector: **Network**.
## Impact
- Confidentiality: **High**. Access to sensitive user information retrieved via the OAuth exchange (email, profile data).
- Integrity: **High**. Ability to perform actions as the compromised user, leading to full Account Takeover (ATO).
- Availability: **Low to Medium**. Services remain available, but user accounts are compromised.
## Remediation
### Patches
- The article states that the fixes were implemented swiftly by the affected vendors. The suggested architectural fix mentioned is to **force the application developer to specify the `AppID`** (Client ID) explicitly, which should be internally verified *before* processing the returned token/identity, mirroring how some existing Facebook flows already handle verification.
### Workarounds
- **Strictly validate the application identifier (AppID/Client ID)** included in the authorization request/state against the credentials used to validate the incoming access token on the callback endpoint. The application must ensure token validation is scoped to its own Client ID, not accepting tokens blindly from external Apps.
## Detection
- **Indicators of Compromise (IOCs):** Increased server-side requests to the token introspection endpoint from the vulnerable application that present access tokens belonging to Client IDs/AppIDs that do not match the expected registered Client ID for that specific authorization session.
- **Detection Methods and Tools:** Implementing runtime application self-protection (RASP) or API security platforms configured to monitor and alert on mismatches between session state parameters (like expected Client ID) and validated token claims during the OAuth handshake.
## References
- Salt Labs Blog (Research Summary): [Defanged link regarding the general topic: hxxps://salt[.]security/blog/a-new-oauth-vulnerability-that-may-impact-hundreds-of-online-services]
- Salt Labs Speaking Engagement: [Defanged link regarding SecTor presentation: hxxps://www[.]blackhat[.]com/sector/2023/briefings/schedule/index.html#uh-oauth---breaking-and-fixing-oauth-implementations-34545]