Just to make life easier I usually add an entry in my hosts file for easier access of the target machine.
Okay now onto the hacking!
As always, I started off with an NMAP scan against the machine.
nmap -Pn -sC -sV -oN initial ready.htb
Nmap scan report for ready.htb (10.10.10.220) Host is up (0.0078s latency). Not shown: 998 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 3072 48:ad:d5:b8:3a:9f:bc:be:f7:e8:20:1e:f6:bf:de:ae (RSA) | 256 b7:89:6c:0b:20:ed:49:b2:c1:86:7c:29:92:74:1c:1f (ECDSA) |_ 256 18:cd:9d:08:a6:21:a8:b8:b6:f7:9f:8d:40:51:54:fb (ED25519) 5080/tcp open http nginx | http-robots.txt: 53 disallowed entries (15 shown) | / /autocomplete/users /search /api /admin /profile | /dashboard /projects/new /groups/new /groups/*/edit /users /help |_/s/ /snippets/new /snippets/*/edit | http-title: Sign in \xC2\xB7 GitLab |_Requested resource was http://ready.htb:5080/users/sign_in |_http-trane-info: Problem with XML parsing of /evox/about Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Scanning & Enumeration
Based on the scan that was run, I realized that port 5080 was running a web server. This was the web app that was being served!
After registering for an account, I headed to the help page which gave away the version of Gitlab that was being used.
Couple google searches revealed that there was a public RCE exploit available for this version of Gitlab.
I made use of this script to exploit the existing vulnerability uncovered in the previous stage.
Getting the user flag was as straight forward as heading into the only other user's directory and reading the file.
This was the most frustrating section for me. I spend so much time looking for ways to get into the root user. But the session I was in turned out to be a docker container. I have had some experience with escaping docker containers but I had to be root on the machine first.
After enumerating around the machine for awhile, I ran the following command in directories to find for any possible passwords.
cat * | grep -e 'root\|password'
Eventually, I was able to get the root user password. However, there was no files in the root directory as this was a container. Thus, I executed a simple container escape!
I first ran
fdisk -l to find out all the possible partitions the machine had.
This revealed to me that the Linux FS was mounted on
/dev/sda2. Thus, I mounted that whole partition onto a directory that I created in the container. Followed by that I read the root flag and finished the box!