Laboratory
Gaining Access
Nmap scan:
$ nmap -p- --min-rate 5000 10.129.78.175
Starting Nmap 7.93 ( https://nmap.org ) at 2023-06-29 17:18 +08
Nmap scan report for 10.129.78.175
Host is up (0.043s latency).
Not shown: 65532 filtered tcp ports (no-response)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open httpsWe have to add laboratory.htb to our /etc/hosts file to access the web ports.
Laboratory -> Gitlab RCE
The website is some kind of company page for coding services:
The background animated thing is pretty cool honestly. Anyways, this looked pretty static, so I did a subdomain and directory scan on the site, and found one git subdomain.
When we visit this subdomain, it reveals a GitLab instance.
When trying to create a user, it appears we have to have a specific email domain being used.
Using laboratory.htb works as the email domain, then we can view the dashbaord:
Interestingly, this was running GitLab 12.8.1, which is an outdated version of the software.
This version is vulnerable to an LFI.
It was also vulnerable to RCE exploits.
There was a Metasploit module for it, which I honestly wanted to try and it works!
I only wanted to use this because I was lazy to set up the Docker containers required for the exploit.
Privilege Escalation
GitLab Rails -> SSH Key
This shell was spawned within a container, and there weren't any users in the home directory.
Within the home directory of the git user, there were loads of Gitlab related files:
The main thing I was looking for was credentials to any other users on the Gitlab instance, since they may have interesting files to look at. I googled more about password for Gitlab, and found methods to reset the user's password.
The documentation states that need to start a rails console, which we can do using gitlab-rails console.
We can start some basic enumeration by first finding the administrators:
Then, we can actually reset the password of dexter.
Afterwards, we can sign in as dexter and view his projects:
'Some personal stuff' in the SecureDocker project. Turns out that refers to his private SSH key that was left on the project!
Using this, we can ssh in as the user and grab the user flag:
Ghidra -> SUID Exploit
I ran a linpeas.sh scan on the machine and found some interesting SUID binaries:
The docker-security one looks like the intended exploit path. When run, this binary does nothing:
I downloaded a copy of this binary to my Kali machine because it looks custom and I could not find any other software online matching this. Then, I opened up a copy in Ghidra. The program is really simple:
The funny thing is that the binary is using the full path for the target file, but chmod itself doesn't have the full path specified. All we have to do is create an program that is called chmod which executes a command as root:
Then, we can just run docker-security to get a root shell:
Rooted!
Last updated