Demoted member continues having read and write access to projects using his deploy key which victim is unaware of
HackerOne report #2038990 by theluci
on 2023-06-26, assigned to @greg:
Report | Attachments | How To Reproduce
Report
Hello,
Background
Gitlab provides a feature to set up Deploy Keys.
Only the maintainers/owner of a project can create or view project’s deploy keys.
There is no option to see the owner/creator of the deploy key through the UI, however, Gitlab provides the following API endpoint to List the project deploy keys for a specific user,
curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.com/api/v4/users/id_or_username/project_deploy_keys"
Where, id_or_username
is the ID or username of the user to get the project deploy keys for.
Vulnerability
According to the docs, this API endpoint is used to list project deploy keys for a specific user.
The doc states,
It lists only the enabled project keys from the common projects of requester and requestee.
It can be seen that the API endpoint was supposed to list the project deploy keys that a specific user (requestee) has in the current project by looking at the common projects between the requester and requestee.
However, the above endpoint does not return any result if the requestee is demoted.
That is, if victim
has a project victim-project
where attacker
is one of the maintainers and had set up his deploy key.
Then, after attacker
is demoted (maybe to a guest role) and victim
runs the following command,
curl --header "PRIVATE-TOKEN: <victim_access_token>" "https://gitlab.com/api/v4/users/attacker_username/project_deploy_keys"
<----------------------------------------------------Important---------------------------------------------------->
No results are returned leading victim
to believe that attacker
does not have any enabled deploy keys.
This is contradictory to documentation as attacker
is still a member of victim-project
and has an enabled deploy key which should’ve been returned by looking at the common projects of requester and requestee.
attacker
can now continue having read and write access to victim-project
using his deploy key which victim
is unaware of.
<------------------------------------------------------------------------------------------------------------------>
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 maintainer. -
attacker
visitshttps://gitlab.com/<victim-group>/<victim-project>/-/settings/repository
, Expand Deploy keys and adds a trustworthy looking deploy key such asCI_SERVER_FALLBACK_KEY
. (Be sure to grant write permissions as well.) -
victim
goes tovictim-group
membership pagehttps://gitlab.com/groups/<victim-group>/-/group_members
and demotesattacker
as guest. -
victim
runs the following command to make sureattacker
doesn’t have an enabled deploy key,
curl --header "PRIVATE-TOKEN: <victim_access_token>" "https://gitlab.com/api/v4/users/attacker_username/project_deploy_keys"
No results are returned leading victim
to believe that attacker
does not have any enabled deploy keys.
-
attacker
can now continue having read and write access tovictim-project
using his deploy key.
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
git checkout -b other
echo “Some text” > Sample.txt
git add .
git commit -m "my commit"
git push origin other
POC
Output of checks
This bug happens on GitLab.com (Probably on instance too).
Impact
A demoted member can continue having read and write access to projects using his deploy key which victim
is unaware of.
Attachments
Warning: Attachments received through HackerOne, please exercise caution!
How To Reproduce
Please add reproducibility information to this section: