Laboratory (HTB)

DONT ASSUME ANYTHING. READ SCANS FULLY

HackTheBox – Laboratory Write-Up

topics: web application attacks (subdomains), client side attacks, manual exploitation/public attacks, escapaing containers, Linux Privilege Escalation (SUID)

1. Enumeration

2. Local Privilege Escalation

3. System Privilege Escalation

tools: gitlab rails

Enumeration

initial autorecon and nmapAutomator scans

nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN

We have three ports open on this machine: SSH and HTTP(S). From the scans we must add laboratory.htb to the hosts file. The scans also show an alternative HTTPS domain git.laboratory.htb

The HTTP site redirects to the HTTPS site so this will logically be the main focus of the penetration test.

Navigating to the website we find a fictional cybersecurity company and the below three users

safe to assume the user is dexter

The user dexter claims to be the site owner. There were no input fields or directories found by gobuster or diresearch using multiple wordlists. Lets navigate to git.laboratory.htb

we have a gitlab platform

We're redirected to a sign in page. Lets also enumerate the directories on this subdomain with dirsearch and create a user account.

sign up only accepted "@laboratory.htb" email domains

dirsearch suggested a robots.txt file which contained some particular directories

The platform is Gitlab, with our user account we can view the version being used which is 12.8.1

Inspecting this with searchsploit reveals an Arbitrary File Read vulnerability for versions < 12.9.0

The python script that came with ss did not work after several edits so I decided to look elsewhere by searching generally for "Gitlab 12.9.0 Arbitrary File Read" and found this python script

python3 dex2.py https://git.laboratory.htb me password1

I first decided to read /etc/passwd to confirm the users on this machine

seems as if the target did not have a conventional user

At this point I assumed that dexter was a valid user on the machine and I would be able to read the SSH key at /home/dexter/.ssh/id_rsa but I was incorrect. There are users unique to the gitlab subdomain with the home directory seemingly /var/opt/gitlab and the main user git

Local Privilege Escalation

The more I read on this vulnerability, the more I realized it might be more popular than expected. Searching more broadly with the CVE I found this RCE python script that with a few tweaks, was able to establish initial access but with an unstable shell, so I carried out the exploit manually.

Initial Access

I came across the original disclosed vulnerability on hackerone with the following instructions:

To establish remote command execution we must

• read secret_key_base from the target instance

• install and run Gitlab 12.8.1 locally

• replace secret_key_base in secrets.yml file in local instance

• start a rails console and replace the command in erb with a reverse shell and generate a cookie

• send a curl request with the cookie and listen for the shell

We can read the key from /opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml using the above PoC script

Install Gitlab 12.8.1 locally with the following command. I used a backup Ubuntu 18.04 VM.

wget --content-disposition https://packages.gitlab.com/gitlab/gitlab-ce/packages/ubuntu/bionic/gitlab-ce_12.8.1-ce.0_amd64.deb/download.deb

Run dpkg -i <package> and locate secrets.yml to replace the secret_key_base with the target's key

Next we have to reconfigure and restart gitlab with

gitlab-ctl reconfigure
gitlab-ctl restart
gitlab-rails console 

reconfigure command hung and didnt properly finish

the rails code seemingly needed to connect to the kali vm through the HTB VPN. run bionic version on kali instead?

And run the following commands to create a valid cookie with the reverse shell payload

w

w

Escaping Container

At this point I transferred LinEnum with wget for system enumeration. LinEnum revealed that this machine is a docker container

dexter might not be a user in the container but may be on the host

From the shell, we can see we were first brought to the gitlab-rails directory within Gitlab. Gitlab-Rails as we know is an interactive Gitlab CLI. Because we are in a container and the website is owned by dexter, perhaps there is a shared folder or we can find/reset his credentials.

instructions to reset user passwords in gitlab-rails

We can run the following commands in gitlab-rails to reset dexter's password

gitlab-rails console -e production
user = User.where(id: 1).first
user.password = 'password1'
user.password_confirmation = 'password1'
user.save!

w

w

Root Privilege Escalation

w