Skip to content

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

  1. A normal link anywhere "Look at this in Gitlab: https://gitlab.com/GROUP/PROJECT/-/jobs/JOBID/artifacts/file/hej.html"
  2. A malicious upload in Markdown. Adding a link to /uploads/anything will render the links as a valid atachement 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.

gfm.png

  1. If created in a private or internal 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

  1. Log in with a user, let's call the user user01
  2. Create a project from https://gitlab.com/projects/new lets call it project01
  3. Create a file in the new project called hack.html containing
<script>alert(document.domain); window.location = "https://example.com"</script>
  1. 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
  1. 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.
  2. Go to https://gitlab.com/user01/project01/-/jobs/JOBID/artifacts/browse
  3. Copy the link from the "hack.html" file link.
  4. 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.

Edited by Jackie Porter