Lack of authorization for integrated error tracking

HackerOne report #1748522 by 0xn3va on 2022-10-24, assigned to GitLab Team:

Report | How To Reproduce

Report

Summary

In the latest release Gitlab provided integrated error tracking that implements a lightweight alternative to Sentry backend. It allows developers to use Gitlab backend as a collector for errors. You can find the docs here. In gitlab.com DSN URL looks like:

https://glet_<token>[@]observe.gitlab.com:443/errortracking/api/v1/projects/<project_id>

So, you can use this URL for working with a Sentry-like API that allows you to perform at least the following actions:

  • GET /projects/{projectId}/errors/{fingerprint} Get information about the error
  • GET /projects/{projectId}/errors List of errors
  • GET /projects/{projectId}/errors/{fingerprint}/events Get information about the events related to the error
  • PUT /projects/{projectId}/errors/{fingerprint} Update the status of the error
  • GET /projects/{projectId}/errors/{fingerprint}/events Get information about the events related to the error
  • POST /projects/api/{projectId}/envelope Ingestion endpoint for error events sent from client SDKs
  • POST /projects/api/{projectId}/store Ingestion endpoint for error events sent from client SDKs
  • DELETE /projects/{id} Deletes all project related data. Mostly for testing purposes and later for production to clean updeleted projects.

The problem is that these endpoints do not require authentication. As a result, it is possible to gain unauthorized access to the errors and even update/delete them.

Steps to reproduce

  1. Clone the following files on your laptop https://gitlab.com/gitlab-org/opstrace/opstrace/-/tree/main/docs/guides/user/error_tracking_examples/python

  2. Create a virtualenv:

    virtualenv -p python3 venv  
source venv/bin/activate

  3. Install dependencies:

    pip install -r requirements.txt

  4. Create a private repo

  5. Go to Settings > Monitor > Error tracking

  6. Enable error tracking and set Gitlab as error tracking backend

  7. Save changes and reload the page

  8. Catch the DSN token

  9. Export the DSN token to environment variables:

    export SENTRY_DSN="https://glet_<token>[@]observe.gitlab.com:443/errortracking/api/v1/projects/<project_id>"

  10. Run the python script:

    python send_exception.py

  11. The script uploads an error to the backend; you can find this error on the Monitor > Error Tracking page

  12. Send the following request to retrieve errors for the your project:

    curl  "https://observe.gitlab.com:443/errortracking/api/v1/projects/<PROJECT_ID>/errors"

  13. Send the following request to delete all errors in the your project:

    curl -XDELETE  "https://observe.gitlab.com:443/errortracking/api/v1/projects/<PROJECT_ID>"
Impact

According to the docs user must have at least Reporter role to access errors and Maintainer to manage them. This vulnerability allows an attacker to bypass these restrictions and gain unauthorized access to errors.

What is the current bug behavior?

Integrated error tracking does not implement authorization for accessing and managing errors.

What is the expected correct behavior?

Integrated error tracking requires a token for making requests and provides access to errors according to the permission policy.

Output of checks

This bug happens on GitLab.com

Impact

According to the docs user must have at least Reporter role to access errors and Maintainer to manage them. This vulnerability allows an attacker to bypass these restrictions and gain unauthorized access to errors.

How To Reproduce

Please add reproducibility information to this section: