Skip to content

IDOR in project with Jira integration leaks project owner's other projects Jira issues

HackerOne report #1538068 by joaxcar on 2022-04-11, assigned to GitLab Team:

Report | How To Reproduce

Report

Summary

Maintainers of projects with a premium subscription have the option to enable "View Jira Issues" (documentation) as part of a Jira integration. This enables users with access to the project to view a list of project issues synced from a connected Jira project by visiting https://gitlab.com/GROUPNAME/PROJECTNAME/-/integrations/jira/issues . And issue details by visiting https://gitlab.com/GROUPNAME/PROJECTNAME/-/integrations/jira/issues/ISSUE_KEY

When configuring this feature, the information states:

Warning: All GitLab users with access to this GitLab project can view all issues from the Jira project you select.

The maintainer of the project enters a Jira project key corresponding to the project that is to be connected.

The way GitLab handles this functionality is by requesting the maintainer to enter three things other than the project key

  1. Jira instance URL
  2. Username
  3. Password or API key (Api key for Jira cloud on atlassian)

GitLab uses the username and password/Api-key when requesting information from the Jira API. This is also the source of the IDOR issue. The Jira project key is used to request the list of issues when visiting /-/integrations/jira/issues. The GitLab backend uses the key in a request like this one

https://username.atlassian.net/rest/api/2/search?jql=project%20%3D%20%22PROJECTKEY%22%20AND%20statusCategory%20%21%3D%20Done%20order%20by%20created%20DESC&startAt=0&maxResults=20&fields=assignee%2Ccreated%2Ccreator%2Cid%2Cissuetype%2Ckey%2Clabels%2Cpriority%2Cproject%2Creporter%2Cresolutiondate%2Cstatus%2Cstatuscategorychangeddate%2Csummary%2Cupdated

note ?jql=project%20%3D%20%22PROJECTKEY%22%20 and is thus "hard-coded" from the project settings. But when visiting a detail page for a single issue /-/integrations/jira/issues/KEY-1 the backend makes a request like

https://username.atlassian.net/rest/api/2/issue/KEY-1?&expand=renderedFields

here GitLab use the KEY directly from the URL without checking it against the configured project key. This allows for all users that have access to the project to request details from ANY issue on ANY project where the maintainer (who have entered his/her username/password) have access. By changing the KEY part of the URL like

/-/integrations/jira/issues/ANYKEY-1

This will fetch information on the issue from project ANYKEY instead of the configured project.

Furthermore the "attacker" can also impact the private Jira issues by referencing them in commits and merge requests. In this way the attacker can add data into private Jira projects of the victim user. See https://docs.gitlab.com/ee/integration/jira/issues.html#reference-jira-issues for more info.

Steps to reproduce
  1. Create a user to use as the victim
  2. Create a new public project (with minimum premium access to gitlab)
  3. Register a new account on atlassian.net and activate Jira
  4. Create two separate projects in Jira, one with project key PUBLIC and one with PRIVATE
  5. Create an issue in both Jira projects.
  6. Go to https://id.atlassian.com/manage-profile/security/api-tokens and create an API token
  7. Go back to GitLab and go to the new project settings 
    https://gitlab.com/GROUPNAME/PROJECTNAME/-/integrations/jira/edit
  8. Fill out the form with Jira URL, username and API token (as password)
  9. Also activate Jira Issues and enter the project key PUBLIC
  10. Log in to GitLab as another user (the attacker)
  11. Visit 
    https://gitlab.com/GROUPNAME/PROJECTNAME/-/integrations/jira/issues/PRIVATE-1
  12. You should see information of the private issue from the victim users other Jira project
Impact

Jira integration leaks issues from victims private Jira projects

Examples

Visit my public project at

https://gitlab.com/ultimate_joaxcar_2/kk/-/integrations/jira/issues

This page should list a public issue. Click the issue to go to

https://gitlab.com/ultimate_joaxcar_2/kk/-/integrations/jira/issues/PUBLIC-2

This is the details page of the public issue. Now change the key to PRIVATE-1

https://gitlab.com/ultimate_joaxcar_2/kk/-/integrations/jira/issues/PRIVATE-1

Note that you now see information on a private project!

What is the current bug behavior?

GitLab uses Jira issue key directly from attacker supplied URL without matching it to the configured project key.

What is the expected correct behavior?

A project should only fetch keys that match the configured key base

Output of checks

This bug happens on GitLab.com

Impact

Jira integration leak sensitive data from private issues to other users of GitLab. Other users can also add data to private issues by referencing them in MRs and commits.

How To Reproduce

Please add reproducibility information to this section: