Unauthorized member is able to view project deploy keys as well as change its title misleading the maintainers/owners of project.
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.
attacker
is also able to change deploy key’s title misleading the maintainers/owners of victim-project
.
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.
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
-
victim
creates a groupvictim-group
and a projectvictim-project
inside. -
victim
goes tohttps://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.
-
victim
goes tovictim-group
membership pagehttps://gitlab.com/groups/<victim-group>/-/group_members
and addsattacker
as guest. -
attacker
visitsvictim-project
and is unable to view deploy keys.
This is the expected behaviour.
-
attacker
creates a new groupattacker-group
and a projectattacker-project
inside. -
attacker
goes tohttps://gitlab.com/<attacker-group>/<attacker-project>/-/settings/repository
, Expand Deploy keys and selects Privately accessible deploy keys. -
attacker
is able to viewvictim-project
deploy keys.
Information disclosure in the title of the deploy key (according to this comment).
-
attacker
clicks on edit next to an important deploy key and changes title asUSELESS_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--------------------------->
-
attacker
enables all the deploy keys under Privately accessible deploy keys. -
victim
removesattacker
fromvictim-group
. -
victim
goes tohttps://gitlab.com/<victim-group>/<victim-project>/-/settings/repository
, Expand Deploy keys and changes the title of a deploy key. -
attacker
goes tohttps://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).
-
attacker
clicks on edit next to an important deploy key and changes title asUSELESS_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
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: