CVE-2022-3331: IDOR in Zentao integration leaks details of issues from a users other "products" (#360372) · Issues · GitLab.org / GitLab · GitLab

HackerOne report #1542834 by joaxcar on 2022-04-16, assigned to @ngeorge1:

Report | How To Reproduce

Report****Summary

Maintainers of projects with a premium subscription have the option to enable “Zentao product integration” (documentation).

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

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 #338178 (closed)

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: