Skip to content
GitLab
Next
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    Projects Groups Topics Snippets
  • Register
  • Sign in
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 54.9k
    • Issues 54.9k
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1.5k
    • Merge requests 1.5k
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Terraform modules
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #222527
Closed
Open
Issue created Jun 16, 2020 by GitLab SecurityBot@gitlab-securitybotReporter

2FA bypass using git command

HackerOne report #898477 by fushbey on 2020-06-15, assigned to @jeremymatos:

I reported a 2FA bypass using the API, but I was told it was an intended behavior, I also added that we could bypass 2FA using git command, and I was asked to report it here.

Summary

If we make a group 2FA enabled, that means we want to restrict its access to users with 2FA enabled if they don't have that enabled, they are redirected to the page settings to enable it, they can't move elsewhere until they do it or they leave that group they are part of.
However, this can be bypassed with read and write access to the projects under the 2FA enabled group using the git command using the username and password, so no personal tokens involved here.

Steps to reproduce

We need two users, both are members of an example group. I used private groups and private projects.
1 - As "userA" Create a private Group.
2 - User A configures the Group to require 2fa, set "Time before enforced" to 0 to test this now.
3 - User A invites user B to the private Group, give him a role so he can push code(Developer minimum)
4 - User B tries to access Gitlab through the Web, you can see it is required to set up 2fa, you are always redirected to [2fa settings] page(https://gitlab.com/profile/two_factor_auth)
6 - UserB can, however, bypass this restriction using the git command without the personal access token, only using his username, and password, I used
https://gitlab.com/anothergroup1/spring-security-group/test-project as an example, you can see I succeed to clone AND push(read and write).

$ git clone https://gitlab.com/anothergroup1/spring-security-group/test-project  
Cloning into 'test-project'...  
Username for 'https://gitlab.com': MYUSERNAME  
Password for 'https://MYUSERNAME@gitlab.com': MYPASSWORD  
warning: redirecting to https://gitlab.com/anothergroup1/spring-security-group/test-project.git/  
remote: Enumerating objects: 12, done.  
remote: Counting objects: 100% (12/12), done.  
remote: Compressing objects: 100% (5/5), done.  
remote: Total 12 (delta 0), reused 0 (delta 0), pack-reused 0  
Unpacking objects: 100% (12/12), 926 bytes | 231.00 KiB/s, done.  
laro at laro in ~  
$ cd test-project/  
laro at laro in ~/test-project on master  
$ git checkout -b new-branch  
Switched to a new branch 'new-branch'  
laro at laro in ~/test-project on new-branch  
$ nano README.md   
laro at laro in ~/test-project on new-branch*  
$ git add .  
laro at laro in ~/test-project on new-branch*  
$ git commit -m 'updated'  
[new-branch 57c88e0] updated  
 1 file changed, 1 insertion(+), 1 deletion(-)  
laro at laro in ~/test-project on new-branch  
$ git push https://gitlab.com/anothergroup1/spring-security-group/test-project  
warning: redirecting to https://gitlab.com/anothergroup1/spring-security-group/test-project.git/  
Enumerating objects: 5, done.  
Counting objects: 100% (5/5), done.  
Writing objects: 100% (3/3), 260 bytes | 260.00 KiB/s, done.  
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0  
remote:   
remote: To create a merge request for new-branch, visit:  
remote:   https://gitlab.com/anothergroup1/spring-security-group/test-project/-/merge_requests/new?merge_request%5Bsource_branch%5D=new-branch  
remote:   
To https://gitlab.com/anothergroup1/spring-security-group/test-project  
 * [new branch]      new-branch -> new-branch  
laro at laro in ~/test-project on new-branch  

Impact

If you want to enforce 2FA for users, that means you want to add an extra layer of security so user credentials that get compromised would not be able to be used to leak and push code, however, this does not happen with the git command.

Examples

(If the bug is project related, please create an example project and export it using the project export feature)

(If you are using an older version of GitLab, this will also help determine whether the bug has been fixed in a more recent version)

(If the bug can be reproduced on GitLab.com without violating the Rules of Engagement as outlined in the program policy, please provide the full path to the project.)

What is the current bug behavior?

Broken access control: allows users to read/write code only using credentials, no 2FA is enforced whatsoever.

What is the expected correct behavior?

if 2FA is enabled for a group to restrict access, a user should not be able to read nor write code unless he has 2FA enabled.

Impact

If you want to enforce 2FA for users, that means you want to add an extra layer of security so user credentials that get compromised would not be able to be used to leak and push code, however, this does not happen with the git command.

Assignee
Assign to
Time tracking