Skip to content

Maintainer can leak sentry token by changing the configured URL

HackerOne report #1792626 by joaxcar on 2022-12-04, assigned to @cmaxim:

Report | Attachments | How To Reproduce

Report

Summary

At the same time as other fixes regarding integration tokens leakage by modifying the configured URL, there were also a fix for the same behaviour in the error tracking Sentry configuration. All fixes were part of the patch
https://about.gitlab.com/releases/2022/07/28/security-release-gitlab-15-2-1-released/#maintainer-can-leak-packagist-and-other-integration-access-tokens-by-changing-integration-url

This made the following change to Sentry token configuration: When a user tries to modify the current sentry URL, the token field will be reset and the user needs to enter a new token. This fix is in place and trying to modify the existing token and clicking save will throw an error telling us the token field can not be empty.

This is made to block other maintainers to leak the configured token.

But revisiting the settings page for Sentry error tracking made me realize that there is another way to leak the token. If the attacker modifies the configured URL and click the connect button (to retrieve the sentry projects) without first clicking save, a call will be issued to the new URL together with the old token.

click_this.jpg

colab.jpg

CVSS

The documentation for adding Sentry tokens to GitLab states

Make sure to give the token at least the following scopes: project:read, event:read, and event:write (for resolving events).

The last time I reported an issue regarding these tokens this was enough to give the impact of confidentiality High and Integrity Low as the token will have both read and write access. As well as scope changed. The fact that the user needs to be a maintainer makes access required High but is still a leak as previous patches show.

Steps to reproduce

  1. Log in to Gitlab.com
  2. Create a project
  3. Go to https://gitlab.com/GROUPNAME/PROJECTNAME/-/settings/operations
  4. Expand ´Error trackin` and click Sentry
  5. Configure with the server https://joaxcar.com (this is a fake server that will let you add it with any token)
  6. Add a random token, and click connect. My server will respond with a projectyou can pick in the dropdown. Do it and click save
  7. Now the token should be hidden. The next step should be made by an attacker. But doing it with the same user still proves the point.
  8. Now change the URL to a catch server. Burp collaborator for example.
  9. Click "save" to get a message telling you you need to add a new token (DONT change the token) this step is to show that the patch is in place and a leak can not be made like this).
  10. instead click "connect"
  11. Check your server and you should see a request containing the token

Impact

Other users can leak the configured Sentry token, getting access to the sentry server. The token gives read and write access to the Sentry instance

What is the current bug behavior?

The old token is sent with a connect request even if the URL has changed

What is the expected correct behavior?

Changing the URL should require adding a new token even for connect requests

Output of checks

This bug happens on GitLab.com

Impact

Other users can leak the configured Sentry token, getting access to the sentry server. The token gives read and write access to the Sentry instance

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

How To Reproduce

Please add reproducibility information to this section: