Skip to content

Unauthorized member is able to view project deploy keys as well as change its title misleading the maintainers/owners of project.

⚠ 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 #2037814 by theluci on 2023-06-25, assigned to @greg:

Report | Attachments | How To Reproduce

Report

Hello,
This report is similar to CVE-2022-2095 in the sense that an unauthorized member can view project deploy keys.
But this report also shows that the unauthorized member is also able to make changes to the deploy key’s title.

Background

Gitlab provides a feature to set up Deploy Keys.
Only the owner/maintainer of a project can view project’s deploy keys.
Changing deploy key’s title is also something that only maintainer/owner of a project can do.

Vulnerability

While fetching the Privately accessible deploy keys, gitlab doesn’t check whether the member has access to the deploy keys or not.
As a result,
An unauthorized member, for example, a guest (attacker) of a victim-project can create a new project attacker-project goes to its Settings->Repository, Expand Deploy keys and can view victim-project deploy keys under Privately accessible deploy keys.

25jun-1.png

25jun-2.png

attacker is also able to change deploy key’s title misleading the maintainers/owners of victim-project.

25jun-3.png

Moreover,
After the deploy keys has been enabled in attacker-project, even if the attacker is removed from victim-project, the attacker can continue to view deploy keys as well as change their title.

25jun-3.5.png

25jun-4.png

That is a removed member can continue to view victim-project deploy keys as well as change their title misleading maintainers/owners of victim-project.

<--------------------------------------------------------Important------------------------------------------------------->

This comment led me to believe that there is information exposure in the deploy key’s title (“deploy key for internal_server_name”).
Also, an unauthorized member changing the deploy key’s title to USELESS_DEPLOY_KEY,KEY_TO_BE_DELETED, DELETE_KEY_ON_23rd etc. can mislead the other maintainers/owners into deleting the deploy key, which will affect the services that depend on the key.

<------------------------------------------------------------------------------------------------------------------------->

Steps to reproduce

  1. victim creates a group victim-group and a project victim-project inside.
  2. 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.

  1. victim goes to victim-group membership page https://gitlab.com/groups/<victim-group>/-/group_members and adds attacker as guest.
  2. attacker visits victim-project and is unable to view deploy keys.

This is the expected behaviour.

  1. attacker creates a new group attacker-group and a project attacker-project inside.
  2. attacker goes to https://gitlab.com/<attacker-group>/<attacker-project>/-/settings/repository, Expand Deploy keys and selects Privately accessible deploy keys.
  3. attacker is able to view victim-project deploy keys.

Information disclosure in the title of the deploy key (according to this comment).

  1. attacker clicks on edit next to an important deploy key and changes title as USELESS_KEY_TO_BE_DELETED.

attacker is able to mislead one of the maintainers or owner of the project into deleting an important deploy key, affecting the services that depend on the key.

<----------------------------Important - Removing attacker--------------------------->

  1. attacker enables all the deploy keys under Privately accessible deploy keys.
  2. victim removes attacker from victim-group.
  3. victim goes to https://gitlab.com/<victim-group>/<victim-project>/-/settings/repository, Expand Deploy keys and changes the title of a deploy key.
  4. attacker goes to https://gitlab.com/<attacker-group>/<attacker-project>/-/settings/repository, Expand Deploy keys and can view the updated deploy keys.

Information disclosure in the title of the deploy key (according to this comment).

  1. attacker clicks on edit next to an important deploy key and changes title as USELESS_KEY_TO_BE_DELETED.

attacker is able to mislead one of the maintainers or owner of the project into deleting an important deploy key, affecting the services that depend on the key.

As can be seen, a non-project member attacker is able to view victim-project deploy keys, as well as make changes to its title.

POC

poc-25jun.mp4

Output of checks

This bug happens on GitLab.com (Probably on instance too).

Impact

Unauthorized member (Members with insufficient role or Removed member) is able to view project deploy keys as well as change its title to mislead the maintainers/owners of project.

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

How To Reproduce

Please add reproducibility information to this section: