**[HackerOne report #1792626](https://hackerone.com/reports/1792626)** by `joaxcar` on 2022-12-04, assigned to @cmaxim: [Report](#report) | [Attachments](#attachments) | [How To Reproduce](#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.   ##### 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 `project`you 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! * [click_this.jpg](https://h1.sec.gitlab.net/a/9668aa77-3e33-4ec9-b1a3-c7b4beaef175/click_this.jpg) * [colab.jpg](https://h1.sec.gitlab.net/a/a7e2f217-5fb1-4d01-bc58-6e42f7ca1e30/colab.jpg) ## How To Reproduce Please add [reproducibility information] to this section: 1. 1. 1. [reproducibility information]: https://about.gitlab.com/handbook/engineering/security/#reproducibility-on-security-issues