Open redirect in pipeline artifacts when generating HTML documents
HackerOne report #1475686 by joaxcar
on 2022-02-09, assigned to @mhenriksen:
Report | Attachments | How To Reproduce
Report
Summary
There exist an open redirect in GitLab CI/CD artifact page. What I can see, open redirects are not out of scope, and I saw that another one got patched in the latest 14.7.1 release.
When a pipeline in a project outputs HTML files as artifacts, these HTML files becomes viable as HTML pages under the project pages
domain Ex. https://xep.gitlab.io/-/x/-/jobs/JOBID/artifacts/hej.html (note the gitlab.io domain not .com). This is by design, as a lot of users use this for viewing build results as webpages. As it is under the pages
domain, I guess that XSS is not a problem here. This is all good, but when viewing the file listing of a job
in https://gitlab.com/GROUP/PROJECT/-/jobs/JOBID/artifacts/browse all HTML files are presented as an external link
, see image. These links do not point directly to the pages
domain, but instead to https://gitlab.com/GROUP/PROJECT/-/jobs/JOBID/artifacts/file/hej.html . Visiting this link returns a 303 redirect to the pages
address.
The issue with this is that a malicious user now have an official gitlab.com link that will redirect to a page at gitlab.io where the user have full control of the content. That includes JS and further redirection with window.location
. This can be abused in multiple ways to disguise the link to trick users into clicking it.
Examples
- A normal link anywhere "Look at this in Gitlab: https://gitlab.com/GROUP/PROJECT/-/jobs/JOBID/artifacts/file/hej.html"
- A malicious upload in Markdown. Adding a link to
/uploads/anything
will render the links as a validatachement
in GFM. This markdown[info.txt](/uploads/../GROUP/PROJECT/-/jobs/JOBID/artifacts/file/hej.html)
will render into an attachment link that will redirect a user to my site. This works in wikis as well.
- If created in a
private
orinternal
project, any user visiting the link will be shown the "Page not found" which will contain a link "Login to access GitLab". This link will put the user at the official login page with the "follow referer" flag set. When the user then log in, the user will immediately be redirected to https://gitlab.com/GROUP/PROJECT/-/jobs/JOBID/artifacts/file/hej.html and then to whatever the link points to. Which could be a phishing page mimicking the login page the user just visited and might be fooled to reenter credentials.
There are probably more places where a link like this could be used to mimic a regular gitlab.com URL.
I took the CVSS score from the open redirect that was patched in the latest patch, but changed PR to Low as the user needs to create the file. Even though I think that this one is worse than the one in the patch. It is worth noting that the generated link shows no sign of being a redirection. A lot of times a redirect is generated like so https://host.com?redirect=https://evil.com
which would give away that something is going on. These links just look like regular GitLab paths without a hint of where the user will end up.
Steps to reproduce
- Log in with a user, let's call the user
user01
- Create a project from https://gitlab.com/projects/new lets call it
project01
- Create a file in the new project called hack.html containing
<script>alert(document.domain); window.location = "https://example.com"</script>
- Go to the CI/CD editor at https://gitlab.com/user01/project01/-/ci/editor and enter this config
data:
script: echo hej
artifacts:
paths:
- ./
expire_in: 4 weeks
- This should also trigger the first pipeline run. Go to https://gitlab.com/user01/project01/-/jobs and find the latest job. Take a note of the Job ID.
- Go to https://gitlab.com/user01/project01/-/jobs/JOBID/artifacts/browse
- Copy the link from the "hack.html" file link.
- Test to browse to the link in any window. You will first see a popup with the
pages
domain (this is so that you can see that we first land here), and when you click OK you will go to example.com
What is the current bug behavior?
Artifact links point to a GitLab.com address which will redirect to a gitlab.io address
What is the expected correct behavior?
The link could point directly to the GitLab.io address
Output of checks
This bug happens on GitLab.com
Impact
Open redirect that could be used to trick users to visit malicious sites. The links look (and are) official and contains no references to the malicious site
Attachments
Warning: Attachments received through HackerOne, please exercise caution!
Proposal
Just show the contents of the file when the customer clicks on the artifact link. If I'm going to https://gitlab.com/GROUP/PROJECT/-/jobs/JOBID/artifacts/file/hej.html, I expect to see the contents of hej.html
- not to be redirected to where that page is being hosted.