Laboratory — HackTheBox WalkThrough
This is a practical Walkthrough of “Laboratory” machine from HackTheBox. Although this machine is marked as easy level, but for me it was kind a crazy level. Credit goes to 0xc45 for making this machine available to us and base points are 20 for this machine.
This walkthrough will be explanatory, because I learned a lot of new things from this machine. So, don’t mind my blabbering.
Passwords, hashes and Flags will be redacted to encourage you to solve those challenges on your own.
Enumeration
We will kick off this machine by enumerating using Nmap.
We got three open ports on target machine, SSH, HTTP/S and nmap http-title script is didn’t able to follow redirect to a hostname. There’s also an alternate DNS is available, that might be a virtual host.
Let’s add hostname and virtual host to /etc/hosts file pointing it to target IP address.
Let’s visit the webpage and find any juicy information.
There’s nothing in particular which can be used for further attack other than CEO name (dexter) might be something or might be nothing. Nothing is page source and no robots.txt available.
If we visit the virtual host, then we’d see sign in and register fields. The target is running GitLab for its projects.
I tried to register using regular gmail, but it gave me an error.
So, we cant use any other mail service other than it’s own. So you have to use “@laboratory.htb” to register. Once I register and logged in, I check the help section and found out GitLab applications running version.
Upon a quick google on version base vulnerability check, we can find its official statement. Source
CVE-2020–10977 Initial report submitted by vakzz on hackerone
If we google the CVE, then there’s a POC already available for this vulnerability. Let’s download that, run against our target.
Before I got POC code, I recreated it following the steps from Vakzz.
- Create two new projects
- Create a new issue on any of the project
- In description, add the path of the file you want to read and submit the issue
- Move this issue to a second project
Note: you can only read if the current (service user) has Permission. I have tried.
As you can see, with out initial access, we exploited the GitLab vulnerability to read passwd file from target machine. You can also use the POC to automate it.
For RCE there’s only one POC available, but for some reason I couldn't able to get a reverse shell. I read the original bug report it has explained a manual way to get reverse shell by exploiting this vulnerability.
- First we need to extract secret key from target gitlab directory. You can follow the same method as discussed earlier.
- We have to install GitLab 12.8.1 on our Kali machine.
- We have to replace the our gitlab secret key with target’s gitlab key
- Generate payload via rails console (This’d in a cookie format)
- Send this cookie to the server
- Get the reverse shell
Note: If you are trying this on Kali Machine, make sure to take a snapshot from VMware. If something goes wrong then you can revert it through snapshot.
I have already installed and configured it on my Kali Linux. At the end of the blog, I will leave some pointers to install GitLab.
Once it’s installed and configured, we need to copy target gitlab’s secret_key_base to our gitlab’s secret.yml file.
Note: You need to read/download the secret.yml file from target using same above mentioned method. Location: /opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml
As you can see I have already downloaded the secret.yml file from target. Now we need to copy that (secret_key_base) to our secret.yml file.
Now create a shell file with your IP and port to upload on target and upon execution of that shell file, we’d get a reverse connection.
Start a HTTP server in that same location (rshell.sh), I like updog, it’s very easy to use and can be used for upload and download. You can use any other service too.
Now we need to access gitlab rails console. It takes couple of minutes to load.
If you see irb(main), then you are inside the rails console of our own gitlab.
Now we need to copy and modify payload accordingly. Make sure to use your IP:port of rshell.sh file. You can get this below payload from hackerone bug report.
Copy the payload, paste and execute it in gitlab-rails console to generate cookies. The above payload will download our ‘rshell.sh’ and save it in /tmp on target. Upon execution, you’d see a lot of data and that’s okay, you don’t need to look for anything.
As of now, our reverse shell (rshell.sh) is in /tmp on target. Now we need to execute it by using same payload but you have to change “erb = ERB.new” parameter to execute our shell file.
Copy the payload and execute it again. In the result, look for “cookie”=> parameter.
Copy the cookie. Now open new terminal and start netcat listener for reverse connection.
Now create a curl string just like below from new terminal tab.
Now you have to paste the cookie value after “experimentation_subject_id=”.
Execute the curl command with the cookie string. If everything goes right, you will get a reverse connection on your netcat listener.
Aight, *hacker voice* we are in. We got our initial access, now we need to enumerate further for PrivEsc. You can use LinEnum or LinPeas to do that.
God Damn, we are in a docker container. We have to escape this to get flags.
As we know we are in gitlab docker, we can able to find any other users if present. To do that we need to access, gitlab rails console.
Just make sure you are accessing target gitlab not your own, so that why “uname -a” command. Once you are in irb(main), run user = User.find(1) this command retrieves users from database. As you can see there’s a user named “dexter”. If there’s no any user then it’d give you error just like below.
There’s no any other user, so we have to work with “dexter” user. From this console we can also change the user password. Source
To do that, we need to set the password, confirm it and save it to database.
Now we need to use browser to access this user account and find any valuable information. Sign in with “dexter” user and input the same password which you changed earlier.
Once you are in “dexter” account, you see two projects.
As you can see, one of them says “confidential”, let access it and find out.
Open it and copy the key and save it on your kali machine. It’s time to access the legit machine not docker.
Once you save it make sure to change the permission of file using “chmod 600 id_rsa", read/write permission to only the owner of that file. It’s SSH thing for security reason.
Let’s access dexter user using SSH.
Now we need to escalate privileges from user to root. So I start with finding any binaries with SUID bit enabled.
I found a lot of binaries but one binary wasn't supposed to be there. Upon execution of that binary it looks for chmod in without absolute path, so we can have our own chmod file with /bin/bash binary to execute and we add this to our path.
We got all the flags required to complete this machine.
Thank you for reading this blog. While attempting this challenge I learned so many things. This was unique target with unique vulnerability.
Reference
https://gist.github.com/dnozay/188f256839d4739ca3e4
https://docs.gitlab.com/ee/administration/troubleshooting/navigating_gitlab_via_rails_console.html#modifying-active-record-objects
https://hackerone.com/reports/827052
