**[HackerOne report #1542834](https://hackerone.com/reports/1542834)** by `joaxcar` on 2022-04-16, assigned to @ngeorge1: [Report](#report) | [How To Reproduce](#how-to-reproduce) ## Report #### Summary Maintainers of projects with a premium subscription have the option to enable "Zentao product integration" ([documentation](https://docs.gitlab.com/ee/user/project/integrations/zentao.html)). This enables users with access to the project to view a list of `product` issues synced from a connected Zentao `product` by visiting https://gitlab.com/GROUPNAME/PROJECTNAME/-/integrations/zentao/issues . And issue details by visiting https://gitlab.com/GROUPNAME/PROJECTNAME/-/integrations/zentao/issues/ISSUE-KEY When configuring this feature, the maintainer is made to enter a `product ID` > ZenTao Product ID: To display issues from a single ZenTao product in a given GitLab project. The Product ID can be found in the ZenTao product page under Settings > Overview. This is to connect the current `GitLab project` with the target `Zentao product` The way GitLab handles this functionality is by requesting the maintainer to enter two things other than the project key 1. Zentao instance URL 2. Zentao API key When a user visits the `/-/integrations/zentao/issues` page the GitLab backend makes a request towards Zentao like so ``` https://username.zentao.net/api.php/v1/products/3/issues ``` Which returns a list of all issues related to `product` with ID 3. When clicking on one of these issues in the UI the user is redirected to `/-/integrations/zentao/issues/issue-1` and the backend will make a request like so ``` https://jihudemo.zentao.net/api.php/v1/issues/issue-1 ``` This request does not contain any check as to which `product` this issue is related. So by enumerating issue titles such as `task-ID`, `bug-ID`, `story-ID` and so on an attacker can enumerate all issues from all `products` the maintainer controls in its Zentao instance. #### A small discussion on CVSS I am not completely sure on how this is intended to work, and Zentao's English documentation is a bit sparse. But from what I have gathered in the GitLab documentation, and issues surrounding this, the intention is to connect ONE GitLab project with ONE Zentao `product`. So any issues not related to this given `product` should not be accessible to other users. My understanding of Zentao is that the user can organize issues in `products`, but all issues share names with incrementing values. So two `products` with two `bug` issues will create the four `bug` IDs ``` bug-1 bug-2 bug-3 bug-4 ``` This is the same for issue types of `task` and `story`. This makes it extremely easy to enumerate these issues. Hence, the complexity scoring of `Low`. There is also no restriction for this feature being used as the issue tracker for a `public` project. If this is done, the attacker can perform the attack unauthenticated. I will report this with a CVSS which is the "highest possible impact" as nothing I have described above is outside "normal workflow". But as usual I understand that the scoring can be subject to change :) #### Steps to reproduce I will use the test account that is used in GitLab issues regarding Zentao. `Zentao demo account` from https://gitlab.com/gitlab-org/gitlab/-/issues/338178 > Zentao Web URL: https://jihudemo.zentao.net > Zentao API token: a70fe861f1e60a3bfd857133798f2f1f > Zentao Product ID: 4 1. Create a user to use as the victim 2. Create a new public project (with minimum premium access to GitLab) 3. In the project page go to https://gitlab.com/GROUPNAME/PROJECTNAME/-/integrations/zentao/edit 4. Fill in the test credentials from above (use product ID 4 as this one only contains one issue) 5. Click save 6. Log out 7. Go to https://gitlab.com/GROUPNAME/PROJECTNAME/-/integrations/zentao/issues 8. The page will list all issues related to the Product. In this case ONE bug issue 9. Click the issue (bug-8) and you will go to https://gitlab.com/GROUPNAME/PROJECTNAME/-/integrations/zentao/issues/bug-8 10. Now change `bug-8` to `bug-1` 11. Details of another `product` is shown 12. Start enumerating #### Impact Zentao integration leaks a user's ALL issues from ALL `products` even if the documentation states that it will show issues from ONE `product` #### Examples Visit my public project at https://gitlab.com/ultimate_joaxcar_2/kk/-/integrations/zentao/issues This is accessible as an unauthenticated user. Try to enumerate issues with names such as `bug-1`, `task-1` and `story-1` #### What is the current *bug* behavior? GitLab uses Zentao issue key directly from attacker supplied URL without matching it to the configured product 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 Zentao integration leaks a user's ALL issues from ALL `products` even if the documentation states that it will show issues from ONE `product` ## 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