Elastic Search: Positive search results leaked via badge
HackerOne report #729747 by xanbanx
on 2019-11-05, assigned to @jeremymatos:
Hi GitLab Security Team,
Summary
I noticed that GitLab added a post-search filtering after the Elastic Search query to redact confidential data.
For a positive search result on the notes scope, the GitLab UI still shows the number of successful search results (without the actual search result).
However, this little information is already enough to gain a lot of knowledge.
An attack can start for example with the following strategy:
- Search for
CVE
--> positive search result because the badge shows a count - Search for
CVE-1
--> positive search result because the badge shows a count - ...
With this strategy an attacker can find out for example which CVE a project might be vulnerable.
Steps to reproduce
Tested on a local installation of GitLab Enterprise 12.4.2
- Setup Elastic Search and enable advanced search
- Create a public group and inside a public project
- Restrict the access to all features, e.g., issues, to project members only
- Create an issue and on that project create a comment containing
CVE-123
- As an unauthenticated user, perform the following query in the browser with the group id from the group in step 2:
http://localhost:3000/search?scope=notes&search=CVE-123&group_id=<group-id>
This will return We couldn't find any comments matching CVE
. However, the notes badge has a 1
leaks a positive search and a note containing the CVE-123
View also the attached screenshot for that.
Impact
An attacker can try many precise search queries with the powerful Elastic search syntax.
The search badge is leaking a positive search result. For very precise search queries, e.g., CVEs an attacker can gain a lot knowledge of the internals of the project.
What is the current bug behavior?
Advanced search leaks number of positive search results via search badge although the user does not have access to the search result.
What is the expected correct behavior?
Do not show the search indicator if user does not have access to the search result.
Results of GitLab environment info
System information
System: Ubuntu 19.04
Proxy: no
Current User: xanbanx
Using RVM: yes
RVM Version: 1.29.9
Ruby Version: 2.6.3p62
Gem Version: 3.0.6
Bundler Version:1.17.3
Rake Version: 12.3.3
Redis Version: 5.0.3
Git Version: 2.23.0
Sidekiq Version:5.2.7
Go Version: go1.12.6 linux/amd64
GitLab information
Version: 12.4.2-ee
Revision: a3170599aa2
Directory: /home/xanbanx/gdk/gitlab-development-kit/gitlab
DB Adapter: PostgreSQL
DB Version: 11.5
URL: http://0.0.0.0:3000
HTTP Clone URL: http://0.0.0.0:3000/some-group/some-project.git
SSH Clone URL: ssh://xanbanx@localhost:2222/some-group/some-project.git
Elasticsearch: yes
Geo: no
Using LDAP: no
Using Omniauth: yes
Omniauth Providers:
GitLab Shell
Version: 10.2.0
Repository storage paths:
- default: /
GitLab Shell path: /home/xanbanx/gdk/gitlab-development-kit/gitlab-shell
Git: /usr/bin/git
Best regards,
Xanbanx
Impact
See above
Attachments
Warning: Attachments received through HackerOne, please exercise caution!