IDOR in sentry error tracking leaks issues from project maintainers other sentry projects
HackerOne report #1546138 by joaxcar
on 2022-04-20, assigned to @ngeorge1:
Report
Summary
Maintainers of any project can activate "Sentry error tracking" (documentation) by going to
https://gitlab.com/GROUPNAME/PROJECCTNAME/-/settings/operations
and expand the error tracking
tab.
This enables users with access to the project to view a list of error reports
synced from a connected Sentry server project
by visiting
https://gitlab.com/GROUPNAME/PROJECTNAME/-/error_tracking .
And error details
by visiting https://gitlab.com/GROUPNAME/PROJECTNAME/-/error_tracking/ID/details where ID is an integer value (this is important for reproducibility of the attack)
The way GitLab handles this functionality is by requesting the maintainer to enter three values
- Sentry API URL
- Auth Token (to the Sentry server)
- Project (from a list which is polled by the backend from the Sentry server using the above credentials)
The project
name will be of the form username | projectname
When a user visits the /-/error_tracking
page the GitLab backend makes a request towards the Sentry sever like so
https://sentry.example.com/api/0/projects/USER/PROJECT/issues/
where USER
and PROJECT
is filled from the project
configured above.
Which returns a list of all errors
related to the Sentry project
When clicking on one of these errors in the UI the user is redirected to /-/error_tracking/ID/details
where the ID is taken from the clicked error. The backend will make a request like so
https://sentry.example.com/api/0/issues/ID
This request does not contain any check as to which project
this (error)issue is related. This allows an attacker to enumerate all issues that the Sentry user have access to by replacing ID in /-/error_tracking/ID/details
with an incrementing value.
If the Sentry server is a cloud user on sentry.io this will result in a lot of bad requests as the issue ID is an incrementing value shared by all users on the platform. It makes leaking issues a bit harder, but not impossible. A worse scenario is if the configured sentry server is self-hosted (not uncommon). Then the amount of issues on the server will be way fewer and the user will probably have access to a lot higher percentage of the issues.
GitLab will present the attacker with a full detail view of the issue with ID
injected in the URL. More than this, the issue(error) can also be resolved
and/or ignored
by the attacker by clicking resolve
or ignore
in the UI. This will remove the error from the issue list in the project where the issue belongs! Thus, this issue also have an integrity impact.
The attacker needs to be at least a Reporter
in the project to view the Error tracker
. (Resolving and ignoring error is also possible as a Reporter
, is this by design? Seems a bit too strong for a reporter...)
The leaked data contains both information about the issue but also stack traces from source code, one called!
Steps to reproduce
Make sure to have a Sentry sever, or an account on sentry.io (GitLab guide to sentry integration)
Make sure to generate an Auth token here https://sentry.io/settings/account/api/auth-tokens/
- Login to sentry.io and go to
projects
https://sentry.io/organizations/USERNAME/projects/ - Create two projects, one called
private
and one calledpublic
- Go into both projects and click the
generate sample event
button - Click on
issues
in the left menu of sentry.io and click on the event. Take a note of the event ID shown in the URL - Switch to the other project and go to
issues
again and take a note of the other issue ID
You shall now have two event IDs, one in each project. Go over to GitLab
- Login to GitLab as a victim user
- Create a new project and go to https://gitlab.com/GROUPNAME/PROJECTNAME/-/settings/operations
- Expand
error tracking
and fill out the form with https://sentry.io and yourAuth token
- Click
connect
- Pick the project
USERNAME | public
in the project dropdown - Save
- Go to https://gitlab.com/GROUPNAME/PROJECTNAME/-/project_members
- Invite another user as
Reporter
- Log out and log in as the other user
- Now go to https://gitlab.com/GROUPNAME/PROJECTNAME/-/error_tracking
- There should be one event in the list
- Click the event and the event details will be shown
- Now swap the ID number in the URL for the issue from the other project, click enter
- Details for the other issue will be shown. Info leak
- Click the buttons
resolve
andignore
Go back to sentry.io
- Open the private project and go to the issue list
- notice that the private issue is now
resolved
andignored
. Integrity impact
Impact
An attacker can enumerate issues from all sentry project of the maintainer of the project. The attacker can also resolve
and ignore
the issues
What is the current bug behavior?
GitLab uses Sentry issue ID directly from attacker supplied URL without checking which sentry project it belongs to.
What is the expected correct behavior?
Only issues from the configured sentry project should be shown
Output of checks
This bug happens on GitLab.com
Impact
An attacker can enumerate issues from all sentry project of the maintainer of the project. The attacker can also resolve
and ignore
the issues
How To Reproduce
Please add reproducibility information to this section: