Project access token names are returned for unauthenticated requesters
HackerOne report #1336059 by joaxcar
on 2021-09-10, assigned to GitLab Team:
Report
Summary
Hi GitLab,
I first thought that this finding was quite low. But after testing my theory for a quick query I obtained an access token to a private project from what I assume is at least a premium member on Gitlab.com (as the feature "project access tokens" are only available for premium or above on your main instance.)
Background:
When a project access token is created the user is asked to "give the token a name". The documentation surrounding this is quite vague (as I have discussed in previous reports) and there is little indication, if not digged up in the documentation, that this "name of the token" will be the name of the underlying BOT user that is created to facilitate the token. As Gitlab is structured at the moment ALL regular users are publicly viewable through booth https://gitlab.com/USERNAME and through the API (/api/v4/users/:id).
The problem:
When creating a project access token
the user creating it is probably thinking more about being informative inside the, possibly private, project. And not about what this name might reveal to unauthenticated users browsing GitLab. As bot users are given a rather generic username (project_<PROJECT_ID>_bot) a simple search for ex. _bot
will list all these bots. What is now visible to a malicious user is
- The ID of (often private) projects from premium or above users
- OFTEN information about this project such as: members names, project name, company name, build tools and so forth. Even TOKENS, as I will explain below
Following this one could then check if there exists multiple BOT users in a given project by searching for <PROJECT_ID>_bot
. The new list will show all BOT users bot1, bot2... and so forth. This list can give the malicious user greater insights in the private project. Searching for _bot10
gives a list of projects that contain at least 10 BOT users, potentially revealing a great deal about a project.
Research:
I know that one should not test vulnerabilities on active customers, but in the development of this report I did make some requests towards gitlab.com. I hope that this can be forgiven and I promise to test on my own system in the future. Unfortunately I did not have my own self managed service at reach. I thought that listing publicly available information (using the search API) would not count as "testing on customers" but I was probably wrong there. I will here list the calls I have made that might have broken this trust:
- Searching for
_bot10
and then subsequently for<PROJECT_ID>_bot
of one of the results. Giving me a list of full names of what looked like members of a given company. I can dig up the project ID if that is needed for log-digging. The information was not saved by me but still exists. - Finding a bot user named with a weird string which I in a case of miss judgment decided to try as a token in these curl commands
curl --header "PRIVATE-TOKEN: <REDACTED>" "https://gitlab.com/api/v4/user"
curl --header "PRIVATE-TOKEN: <REDACTED>" "https://gitlab.com/api/v4/projects?visibility=private"
After realizing that this is an actual token to a private project, I stopped any further research. I have removed any traces of the information on my part but these calls should have been sent from the IP 185.219.190.201 if you need to check the logs.
Again, I am sorry for breaking the rules and hope that this disclosure could make up for the mishap. Please tell me if you need any more information from me to restore trust
And this token: <REDACTED>
Is publicly exposed on Gitlab at the moment.
Steps to reproduce
- Log out of gitlab.com (this works unauthenticated)
- Go to https://gitlab.com/-/graphql-explorer
- Make the request
{
users(search: "_bot") {
nodes {
username
name
}
}
}
- The result lists information of mostly premium customers private projects
Impact
A unauthenticated actor can request lists of BOT users that potentially reveal secret information from private projects of (on gitlab.com: premium) customers.
What is the current bug behavior?
Name of project access tokens are stored as the name of publicly searchable bot users. Information about this is lacking and can cause serious information leakage.
What is the expected correct behavior?
BOT users should have generic names and the name should be given to the bot users token. Or BOT users should not be listable.
Output of checks
This bug happens on GitLab.com
Impact
A unauthenticated actor can request lists of BOT users that potentially reveal secret information from private projects of (on gitlab.com: premium) customers.
How To Reproduce
Please add reproducibility information to this section:
- Log out of gitlab.com (this works unauthenticated)
- Go to https://gitlab.com/-/graphql-explorer
- Make the request
{
users(search: "_bot") {
nodes {
username
name
}
}
}
- Observe names of bot users containing information that users probably don't expect to be public