Let’s kick this off by running an nmap scan !

As you can see, we have ports 22, 8000 and 8080 open. Nmap script enumerated and provided us information that this website is running gitweb 2.20.1 on 8000. Port 8080 is running NGNIX.

Let’s start by enumerating port 8080, where you can sign up for an account.

After creating a user account and looking at it for some time I decided to start enumerating port 8000.

I enumerated the GIT repository and found couple of interesting information’s : 1) Hashes for couple of users, bill and Jennifer – we can use this to crack them offline 2) Upon opening the Gemfile, the file reveals that the rails version used is 5.2.2.1.

I decided to peruse the rail with known vulnerability route:

Reference: Exploit

In order to generate the payload for this vulnerability, we need to install rails and its dependencies to generate the payload

git clone  https://github.com/masahiro331/CVE-2020-8165.git

apt-get install sqlite3 libsqlite3-dev

Installed ruby version:

Now, once you have rail installed you can follow the steps from here: Exploit

Now we have the payload that is urlencoded, we can inject this into username field in the web application running on port 8080. For this we will intercept the traffic using Burp Suite:

Although, the response from Burp says “500”, the payload is marshalled into Redis. All you need to do is to refresh your profile page and the reverse shell appears on your netcat listener.

Yay, we now have access as bill!

Upon trying to see if user bill can run anything as sudo, I noticied that the error messages were sort of aggressive lol

I used a script to look for any privilege escalation vectors and found these hashes which are different from the ones we found before”

I threw the hashes in john to crack it and got a cleartext password:

Now let’s try and run sudo

Hmm verification code ? I recall seeing something called “google authenticator” while I was grabbing the user.txt file.

Okay we got it here:

Look like we got the secret key:

With the secret in our hand, I will use an authenticator from my local system to grab the verification code:

The verification works but the operation wasn’t getting completely executed, so the only possible justification is the difference in timezone

Even after changing the timezone, I kept getting errors. So, I was very frustrated at this point so I just got up and got myself some coffee and I came back to it and realized that the time is still different for both the system…uff coffee does magic lol

Now I just have to set the time on my local machine to match with the time on the viticms machine so the token matches/ does not expire:

timedatectl set-time  00:52:46

Once, the time was set correctly, the token worked:

Alright so,bill have sudo on /gem

Let’s abuse that from the information in GTFOBins:

The end!