GitLab User Enumeration
-
Ben Campbell - 20 Mar 2015
MWR InfoSecurity discovered a username enumeration vulnerability in GitLab v5.0.0 to v7.5.0 which provides a Ruby on Rails web interface to manage git repositories.
MWR have worked with the GitLab team to ensure that future versions of GitLab are no longer vulnerable to this issue.
As security testers why should we care about GitLab? Source code may be the critical business information that organisations are trying to control. Access to GitLab means an attacker could recover this information as an end goal; review the code for vulnerabilities that exist elsewhere in the environment; or backdoor the code to further their access.
Additionally, historic bugs in GitLab have allowed remote code execution:
- https://about.gitlab.com/2014/09/24/gitlab-shell-and-bash-cve-2014-6271/
- https://about.gitlab.com/2013/11/14/multiple-critical-vulnerabilities-in-gitlab/
- https://about.gitlab.com/2013/11/08/security-vulnerability-in-gitlab-shell/
- https://about.gitlab.com/2013/11/04/gitlab-ce-6-2-and-5-4-security-release/
Finally, GitLab can be configured for authentication via LDAP. This can mean that gaining access to GitLab could reveal the Active Directory credentials used to query LDAP and give us our first step into the Windows Domain environment.
User Enumeration
The vulnerability exists as the internal API has been mounted so that it is publicly accessible (from the webserver), and requires no authentication:
- http://gitlab/api/v3/internal/check reveals the GitLab version and revision. For attackers scanning the internet this means they can easily pinpoint specific public GitLab instances containing certain vulnerabilities. If a public instance allows self-registration this box can now be identified, a user registered, and the machine exploited.
- http://gitlab/api/v3/internal/discover?key_id=# reveals the username for the associated SSH key. As most active users are expected to configure an SSH key this means that most usernames can be anonymously enumerated. The attack is trivial as the key_id value starts at 0 and increments by one from there. Additionally if the GitLab server is joined to an Active Directory server for authentication, this will reveal valid usernames which can be used to attack the Windows domain.
To help demonstrate this security issue MWR have published the gitlab_user_enum script for the Metasploit Framework.
These values can then be used to feed into the GitLab login scanner module for Metasploit also produced by MWR:
After finding a valid password, check the version returned by the gitlab_user_enum module and see if the service is vulnerable to any of the remote code execution vulnerabilities e.g. the Metasploit exploit/multi/http/gitlab_shell_exec module.
Post Exploitation
If you successfully gain access to a GitLab host, you may gain further access to an enterprise by checking out the LDAP configuration in gitlab.yml file (Omnibus installs are likely to be in /var/opt/gitlab/gitlab-rails/etc/):
ldap:
enabled: true
servers:
main:
{"label":"LDAP","host":"192.168.153.138","port":389,"uid":"sAMAccountName",
"method":"plain","bind_dn":"CN=Administrator,CN=Users,DC=test,DC=lab",
"password":"Password1!","active_directory":true,
"allow_username_or_email_login":false,
"base":"CN=Users,DC=test,DC=lab",
"user_filter":""}
Remedial Actions
If you haven’t patched take advantage of some of the newer features of GitLab by upgrading now to v7.6.0 or greater.
Keep an eye on the GitLab blog for additional security issues in future. The GitLab team take security seriously and MWR have found they respond positively to security issues raised with them.
Download
The Metasploit modules should be included in Metasploit Framework. Otherwise they can be obtained from their respective pull requests gitlab user enum, gitlab login.