User can bypass group "Git abuse rate limiting" by forking all projects
HackerOne report #1781776 by joaxcar
on 2022-11-22, assigned to @cmaxim:
Report
Summary
NOTE TO TRIAGER:
the policy state
Server side Denial Of Service with a temporary impact on performance that can be solved by tuning application limits or additional rate limiting
Lack of, or insufficient, rate limiting. (We are aware of the lack of rate-limiting in many places and our application-wide application limits initiative aims to improve that)
regarding rate limit bugs. This bug is not a case of the first one, and I would also argue that it is not the case of the seccond one, as the bug allows for a user to avoid getting banned from accessing a group. The abuse restriction is more than just a rate limit as it is talked about in other parts of the application.
END OF NOTE
Gitlab 15.6 introduced "Git abuse rate limiting" where a group owner can set a limit on how many projects under the top group that a single user can clone or download. The docs states
Git abuse rate limiting is a feature to automatically ban users who download or clone more than a specified number of repositories in a group or any of its subgroups within a given time frame. Banned users cannot access the main group or any of its non-public subgroups via HTTP or SSH. Access to unrelated groups is unaffected.
This restriction does not seems to affect forking
of projects. Which essentially achieves the same thing. This allows a user to download all projects in the group without getting banned by the abuse rate limit
Steps to reproduce
(Need Ultimate license)
- Create two users, one "victim" and one "attacker"
- Log in as the "victim" user
- Create a new group "victim_group"
- Create a number of projects inside the group, minimum 3
- Go to https://gitlab.com/groups/GROUPNAME/-/settings/reporting
- Enable the feature by setting "number of repos" to 1 and time limit to "1000", also enable auto banning
- Go to https://gitlab.com/groups/GROUPNAME/-/group_members
- Invite the "attacker" as guest
- Log out and log back in as "attacker"
- Create a new group as attacker called "attacker_group"
- Go to https://gitlab.com/-/profile/personal_access_tokens and create an API access token
- Open a terminal and clone my modified version of "Gitlab group fork"
git clone https://gitlab.com/joaxcar/gitlab-group-fork.git
- Run these commands (replace groupnames and TOKEN)
cd gitlab-group-fork
pip3 install -r requirements.txt
python3 gitlab_group_fork.py victim_group attacker_group -t TOKEN
- The script will fork all projects (and subgroup projects) into the new group
- You can see that all projects will get forked
- Double check that you still have access to the victim_group projects in the UI as the attacker
If you instead now try to clone two/three of the projects using the same token like so
git clone https://attacker:TOKEN@gitlab.com/GROUPNAME/PROJECTNAME1.git
git clone https://attacker:TOKEN@gitlab.com/GROUPNAME/PROJECTNAME2.git
git clone https://attacker:TOKEN@gitlab.com/GROUPNAME/PROJECTNAME3.git
you will see that the user gets banned from accessing the group
Impact
Users can bypass abuse rate limits by using fork instead of clone to download all projects in a group with abuse restriction
What is the current bug behavior?
Forking projects in a restricted group is not treated as cloning
What is the expected correct behavior?
Forking is a clone and should trigger a ban
Output of checks
This bug happens on GitLab.com
Impact
Users can bypass "Git abuse rate limiting" by using fork instead of clone to download all projects in a group with abuse restriction
How To Reproduce
Please add reproducibility information to this section: