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
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
- Jira instance URL
- Username
- 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
- Create a user to use as the victim
- Create a new public project (with minimum premium access to gitlab)
- Register a new account on atlassian.net and activate Jira
- Create two separate projects in Jira, one with project key
PUBLIC
and one withPRIVATE
- Create an issue in both Jira projects.
- Go to https://id.atlassian.com/manage-profile/security/api-tokens and create an API token
- Go back to GitLab and go to the new project settings
https://gitlab.com/GROUPNAME/PROJECTNAME/-/integrations/jira/edit
- Fill out the form with Jira URL, username and API token (as password)
- Also activate Jira Issues and enter the project key
PUBLIC
- Log in to GitLab as another user (the attacker)
- Visit
https://gitlab.com/GROUPNAME/PROJECTNAME/-/integrations/jira/issues/PRIVATE-1
- 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: