HackTheBox: (“Laboratory”) — Walkthrough

Mohamed Elmasry
8 min readApr 17, 2021

Hi People :D

Today we’ll solve “Laboratory” machine from HackTheBox, an easy machine that shows you how to exploit gitlab12.8.1 and Path-Hijacking vulnerability, so let’s get started


— — —

  1. Ports 80,22 and 443 are opened
  2. From Nmap results, there’s a subdomain (“git.laboratory.htb”), add it to /etc/hosts file then navigate to it
  3. git.laboratory.htb is running GitLab 12.8.1 so that I searched for an exploit for this gitlab version
  4. I found This HackerOne report which contains steps to reproduce gitlab 12.8.1 exploit then I used this exploit to get secret_key_base from secrets.yml file
  5. With secret_key_base, I was able to escalate this bug to RCE using some commands from the HackerOne report then I got a git user shell
  6. From git user, I changed dexter password then login with his account into git.laboratory.htb
  7. In dexter account, I found his SSH keys which I used to SSH into dexter then I found user flag
  8. After uploading LinPEAS to the machine and run it, I found SUID file called docker-security which is owned by dexter group
  9. I noticed that the docker-security file seems to be using chmod command without specifying the full path (“/usr/bin/chmod”), this behavior is vulnerable to Path-Hijacking
  10. I used some commands from the upper article and I got a root shell successfully


— — — — — —

Start with Nmap

nmap -A

We have three open ports (22/80/443) and we find a subdomain (“git.laboratory.htb”) so let’s add this domain and subdomain to the /etc/hosts file

Web Enumeration

— — — — — — — —

Navigate to laboratory.htb ( after add it to /etc/hosts )

Scroll down a bit, there are some users here but dexter looks interesting as he is a CEO

There is no use from this website other than this information.

So let’s move to git.laboratory.htb

It’s running GitLab, so we must make an account first ( note that when you register an account, the email must be @laboratory.htb such as (anything@laboratory.htb).

After making an account, go to the help page ( from question mark at the top right corner ) to see GitLab Version

It’s running GitLab 12.8.1, now we need to search for exploitation


— — — — — —

[*] Manual exploitation :

I found This HackerOne report explaining the exploitation of the vulnerability

Here we have a demo and steps to reproduce, so let’s try it

First, login with your account in git.laboratory.htb then make a new project named Project_1 as an example

Second, create another project named Project_2 as an example

Third, in Project_2 navigate to Issues and make a new issue

In this issue, put our exploitation command into the Description box then submit the issue


Fourth, click on Move issue ( from bottom right corner ) and select Project_1 then click on Move

After doing all these steps, we got a passwd file as an attachment

Nice but at this point we can read files only, that isn’t enough!

So back to HackerOne report again .. scroll down, I found this comment explaining how to escalate this bug to RCE

To escalate it, we need to get secret_key_base from secrets.yml file located in this path: ( /opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml ).

It’s easy! we can read the secrets.yml file in the same way we read the passwd file.

Again, make 2 projects ( Project_1 & Project_2 ) then from Project_2 make a new issue called secrets.yml_Read as an example then we put our exploit in Description box but this time we changed the payload to read secrets.yml as this:


Then move this issue to Project_1 and we successfully read secrets.yml and get secret_key_base

[*] Automated exploitation :

We also can use a public script to automatically read secrets.yml.

In This GitHub repo, you’ll find Python script named cve_2020_10977.py

Just download this script and pass URL, username and password ( for your gitlab account ) to it then it will ask you to put the full file path, in our case, it will be ( “/opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml” ).

And we got secret_key_base without any effort!

Now we need to install GitLab12.8.1 inside a docker, if you have docker installed just download GitLab with this command:

sudo docker pull gitlab/gitlab-ee:12.8.1-ee.0

After downloading, run your docker with this command:

docker run -it gitlab/gitlab-ee:12.8.1-ee.0 sh

Then reconfigure your docker with these commands:

/opt/gitlab/embedded/bin/runsvdir-start &gitlab-ctl reconfigure

Change your secret_key_base with one that we got from the previous exploit using nano or vim:

nano /opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml

As HackerOne report says, we need to execute some commands into gitlab-rails console to get cookie value that we need to get a shell:

gitlab-rails console_commands ( Local )

Here we just change the payload to get a file called Shell.sh that contains our reverse shell then give it execution permission with chmod 777 Shell.sh then execute it.

After all these commands we got a cookie value

Create Shell.sh file with a reverse shell payload and run python3 http server then do the curl command to get the shell:

curl -k -vvv 'https://git.laboratory.htb/users/sign_in' -b "experimentation_subject_id={Your_Cookie}"

And finally, we got a shell as git

User Flag

— — — — —

As we got a git shell, we can use gitlab-rails console to change users password ( as mentioned here )

Just follow the commands in the upper image to change dexter password.

First, we used User.find(1) command to find out the user whose ID number is 1 and save the result in the user variable .. in our case, dexter is the user with id number 1 as he is the CEO

Second, we used user.password and user.password_confirmation to set the new password and user.save! to save the password.

All commands in order:

set dexter password

We successfully changed dexter's password so let’s login with it in git.laboratory.htb.

There are 2 projects but the second one looks interesting because he mentioned that this project has personal stuff so let’s check out

In this project, there are SSH keys for dexter

Copy this private SSH key and use it to connect as dexter via SSH.

ssh -i {SSH_Key_File} dexter@laboratory.htb

Finally, we reached the user flag :D

Root Flag

— — — — —

Let’s upload LinPEAS to do enumeration stuff

Running LinPEAS then take a look at the SUID files in the results, there’s a file called docker-security in /usr/local/bin

This file is not readable but we can see that this file seems to use chmod command without specifying the full path ( “/usr/bin/chmod” ), this is vulnerable to Path-Hijacking ( You can validate this by using pspy )

By using one of the Path-Hijacking Techniques, we can get root shell easily.

Make a file named chmod contains /bin/bash then give it execution permission with :

chmod +x ./chmod

Then put your work directory in PATH variable using :

export PATH=$(pwd):$PATH

Then run the file and you will get the root shell.

Or you can do it with one command:

PATH=$(pwd):$PATH docker-security

And we got the root flag ☺

Thanks for reading and if you love this writeup, you can give me a Respect on my HackTheBox Account

Facebook Twitter LinkedIn



Mohamed Elmasry

Digital Forensics Investigator | CTF player and creator | SOC Analysts | Threat Hunter