Sentry is a popular platform for tracking errors and monitoring application performance. But in its journey from version 10.. through 23.7.1, a critical security issue crept in, now marked as CVE-2023-39531. This vulnerability could let a skilled attacker grab a valid access token for another user during an OAuth token exchange, all because of a hole in how Sentry validated credentials in its OAuth implementation.

Let’s break down what this means in plain English, see how the exploit works, and learn how to keep your stuff safe.

What Is CVE-2023-39531?

At a high level, OAuth lets users securely grant third-party applications access to their data without handing over login passwords. Sentry supports OAuth for this reason. But from version 10.. and before 23.7.2, the OAuth process failed to check credentials the right way during token exchanges. That made it possible for an attacker, given a few conditions, to snatch someone else’s access token.

The vulnerable API application must already be authorized by the targeted user.

Not every Sentry deployment is at risk! Sentry's own SaaS customers are safe since the flaw was swiftly patched. But if you run Sentry yourself (self-hosted), you need to upgrade.

Eve manages to perform a client-side exploit—maybe hijacking Alice’s session or tricking her.

3. When Eve requests a token exchange with the Sentry OAuth endpoint, insufficient credential checks allow Eve to receive an OAuth token that belongs to Alice, not herself.

This represents a classic *privilege escalation*, all because the OAuth flow trusted the client ID and the authorized app status, without verifying *who* was making the request.

Simplified Exploit Illustration

import requests

sentry_oauth_token_url = "https://sentry.yourdomain.com/api//oauth/token/";
client_id = "KNOWN_CLIENT_ID"  # Attacker knows this
client_secret = "KNOWN_CLIENT_SECRET"  # Can be obtained via other means
redirect_uri = "known-authorized-redirect-url"
victim_code = "stolen_or_obtained_auth_code"  # Acquired by attacker

data = {
    "client_id": client_id,
    "client_secret": client_secret,
    "grant_type": "authorization_code",
    "code": victim_code,
    "redirect_uri": redirect_uri,
}

response = requests.post(sentry_oauth_token_url, data=data)
access_token = response.json()['access_token']

print(f"Obtained access token: {access_token}")

In this scenario, if victim_code comes from Alice and the validation is broken, Eve gets Alice's data!

Data Exposure: Attackers can get access to your project’s critical error and performance data.

- Potential Escalation: With these tokens, attackers might integrate new apps or even change settings.
- Silent Abuse: Since API app tokens are normal to see in logs, exploitation may stay under the radar.

Sentry SaaS Users: No action needed.

- Self-Hosted Sentry Users: Upgrade to version 23.7.2 or later immediately. (Release here)

No Workarounds: There is no safe way to patch this other than upgrading.

- Review OAuth Applications: Check which OAuth apps are authorized for each user, and remove anything unrecognized or unused.

References

- GitHub security advisory for CVE-2023-39531
- Sentry Release Notes (v23.7.2)
- OAuth 2. Spec (RFC 6749)

Review and prune authorized API apps as good hygiene.

Stay vigilant and keep your Sentry instance patched! If you have questions, check the official Sentry Security Documentation or the GitHub advisory.

Timeline

Published on: 08/09/2023 17:15:00 UTC
Last modified on: 08/16/2023 17:55:00 UTC