Htb Laboratory

Brief Overview

Laboratory was a short and sweet machine. Initial access was obtained using a metasploit module, and privesc to user was simple. Root privesc made use of a path variable vulnerability. I enjoyed this box overall.

Nmap

nmap -sV -p- 10.10.10.216

PORT    STATE SERVICE REASON 
22/tcp  open  ssh     syn-ack 
80/tcp  open  http    syn-ack 
443/tcp open  https   syn-ack 

All of this looks pretty standard. Web page is also pretty simple, but after running a quick gobuster directory search we see a certificate error that points to git.laboratory.htb. If we add this domain to our hosts file we can reach the machine’s gitlab page.

We can make an account by using any email that ends in laboratory.htb and sign in to view our dashboard. Nothing super interesting here that we can access, but we can fin the version of gitlab running on this machine by going ot the help menu. The version is Gitlab 12.8.1

If we look up exploits for this Gitlab version, we come across the following metasploit module:

exploit/multi/http/gitlab_file_read_rce

When configuring this exploit, there are some parameters that we have to set that most of us probably aren’t used to. This is because Gitlab is a vhost:

msf> set vhost git.laboratory.htb
msf> set ssl true
msf> set rport 443
msf> set rhosts 10.10.10.216

From here we can login with our credentials to get a shell! Then I decided to see if I can change the admin password of the gitlab to see if they have any interesting repositories. This docs page was extremely helpful in figuring it out: [Gitlab Docs]

By using the gitlab-rails console we can interact with the gitlab database and change the administrator password:

$ gitlab-rails console -e production 

user = User.find(1)
user.password = 'password'
user.password_confirmation = 'password'
user.save!

Now that we’ve changed dexter’s password, we can sign into his gitlab account!

That was easy. Dexter’s SSH Key is just sitting in his repo. Time to download and SSH into the box as Dexter!

Root

After some initial enumeration, I found an interesting file: /usr/local/bin/docker-security that has the SUID bit set. Let’s analyze this binary using ltrace:

ltrace /usr/local/bin/docker-security

It seems to be using chmod at some point during its execution. This means it may be vulnerabile to a path variable vulnerability! If you have never heard of that kind of attack, this article was very informative: [Path Variable Attack]

Now we will setup some things for this attack. First, we will create a fake chmod file in the /tmp directory that will execute bash, make it executable, then add it to our PATH:

echo "/bin/bash" > /tmp/chmod
export PATH=/tmp:$PATH

This will cause the docker-security binary to use our fake chmod binary instead of the real one because the /tmp directory comes before the real binary in our PATH, meaning it will be used first!

Once we run docker-security, it will immediatly give us a root shell!

I hope you all enjoyed this write-up!