Status page integration renders arbitrary GFM references to private/confidential ressorces
HackerOne report #843151 by xanbanx
on 2020-04-08, assigned to @cmaxim:
Hi GitLab Security Team,
Summary
GitLab recently added a status page integration (btw, a cool feature). In a status page, the content of issues is exportet to an external site hosting a status page. GitLab currently supports AWS as the external site. In this setting, GitLab's issue tracker acts as an incident list for the status page. When creating a new issue in this project, this issue is populated to the external status page, which is publically visible.
Here comes the problem now. When having a reference to a private or confidential ressource in the issue, then the status page automatically renders this and includes the title of that ressource in the resulting status page.
- An attacker can simply use that to scan arbitrary project for confidential issues, e.g., for the
gitlab
repository - It can be used to scan issues of private projects
- It can be used to scan issues of projects with restricted access
This does not only apply to issues. It also renders every other markdown reference, e.g., MRs, Epics, Snippets...
Steps to reproduce
As a normal user:
- Create public project and then create a confidential issue inside. It's GFM reference is now
namespace/public-project#1
As an attacker:
- Setup an AWS bucket and deploy the status page. I used !26751 (diffs) for the documentation.
- Create a private status page project, e.g., named
status-page
- Enable the status page integration and connect it to an AWS S3 account
- Create a new issue on the
status-page
issue tracker and reference the issue from above. Just includenamespace/public-project#1
in the issue body.
This now gets published to the status page. Visit the status page deployed on the AWS page. This now renders the GFM ressource to that confidential issue and thus leaking the title of the confidential issue.
Impact
The status page integration renders all GFM references, even if the user does not have any access to that.
An attacker can simply set up the status page integration and thus get access to all private issue titles including confidential issues for every project. Even if the user does not have access to that project (private project).
As an attacker, I could for example set up a status page project on gitlab.com and then scan through all issues of the gitlab-org/gitlab
project and thus leaking their titles!
Examples
I tested this on gitlab.com. I integrated the status page and then used to scan one oy my previous H1 reports.
See the screenshot below, which is referencing the confidential issue of #824773
Here you see in the tooltip the title of that confidential issue.
What is the current bug behavior?
The status page integration renders arbitrary markdown. This includes references to ressources where the user does not have access to.
What is the expected correct behavior?
The user cannot add references to private ressources and those then get rendered.
Output of checks
This bug happens on GitLab.com
Best regards,
Xanbanx
Impact
See above
Attachments
Warning: Attachments received through HackerOne, please exercise caution!