In reviewing multiple blogs and websites, Fristileaks is reported to be one of several vulnerable systems that are supposed to assist penetration testers with challenges similar to Offensive Security’s PWK coursework. My goal is to complete these challenges and document my findings along the way.
Setup:
I downloaded the Fristileaks VM from VulnHub.com and then imported the OVA file into my instance of VMWare. My VMWare host machine was an Ubuntu 16.04 Workstation.
I referred to the VulnHub.com site to review the Virtual Machine Information, Networking, as well as expected screen shots once the Fristileaks system had been started. Reading the Description, it was recommended to use Bridged Networking and to modify the MAC Address of the VM to 08:00:27:A5:A6:76.
For my attacking system, I decided to deploy a 64-bit VMware Image of Ubuntu 18.04 from Ubuntu.com. I then installed Trusted Sec’s Penetration Testers Framework from GitHub. In addition, I created a Fristileaks directory on the attacking system to capture and store files.
Note: due to firewall restrictions between my production network and my lab network, I had to use a second attacking system within my lab network (Kali 64-bit).
Victim Description:
The VulnHub.com site did not list any vulnerabilities, but it did note there was a text flag. I have included the vulnerabilities that I found below:
· Sensitive Date Exposure
· Misconfiguration
· File Validation
· Local Privileged Access
· Stored Passwords
· Local Privileged Escalation
· SUID Binary
Information Gathering:
Since I knew the isolated network IP Address range, I used Nmap to perform a host discovery scan of the 172.27.254.0/24 subnet.
nmap -sn -n 172.27.254.0/24
Next, I used the Nmap command to perform an Aggressive Service scan, treating all hosts as being online, probing all TCP SYN ports, and then outputting the findings into three different file formats starting with the name of NmapFullScan.
Based on the results, I knew the following:
· TCP Port 80: Apache 2.2.15; PHP 5.3.3
· Operating System: CentOS with Kernel 2.6.32–3.13
Enumeration:
Continuing with Nmap, I used the vuln NSE script and then output the findings into three different file formats starting with the name of NmapVulnScan.
Next, I used nikto to determine the vulnerabilities present as well as enumerating TCP Port 80. In addition, I used the tee command to output the data to the screen as well as to the file of nikto_22.txt.
nikto -host http://172.27.254.22 | tee nikto_22.txt
In addition, I turned to dirb to determine the listed web site directories and then output the file to the screen as well as to the file of dirb_22.txt with the tee command.
Base on the results from the three tools, there appeared to be a robots.txt file. So, I decided to launch a web browser to further investigate.
Next, I decided to review each of the disallowed directories as well as the source code.
Interesting. I received the same image for each of the directories and the source code was directed to a jpg file within the images folder.
At this point, I decided to review the default web page and source code.
Nothing interesting at first glance. So, I decided to look at the images page source code.
Hmm…only the two images previously discovered were listed. So, I once again returned to the main web page for additional clues.
Next, I decided to try each of the words listed on the main web page within the URL to discover any hidden directories. I finally got results from /fristi. Duh…I should have connected the dots based the other drinks.
Sensitive Data Exposure:
I decided to determine if I could brute force or use SQL injection to bypass the Member Login.
The answer to the above was no.
Not able to bypass the Member Login with brute force or SQL injection, I decided to review the source code for the /fristi page.
Interesting, the note left by eezeepz documented that base64 encoding was used. So, I copied the commented section to decode it.
I used the echo command to paste the base64 contents into a file named base64file.
Next, I used the base64 command to decode the base64file and created a new file named base64file.txt.
base64 -d base64file > base64file.txt
Once the file was decoded, I used the cat command to review the contents of the base64file.txt file.
In reviewing the file, it would appear that the decoded contents were an image file. So, I copied the base64file.txt to base64file.png.
Next, I used the display command to view the base64file.png file.
Interesting. I wonder if this was part of the login credentials for Admin Portal. So, I entered eezeepz into the Username field and then contents of the image file into the Password field.
Yep! A suscsessful login to the Admin Portal.
Bypassing File Validation:
I clicked on the upload file hyperlink and was presented with the ability to upload a file. So, I decided to click the buttons to see what happened.
Nothing exciting with the Browse button. However, the Upload Image button returned an error that specified allowed file types to be uploaded.
Knowing that there was some sort of file validation occurring with the file uploads, I decided to do some research on how to bypass the restriction. I found an article on Exploit-DB that provided a technique of inserting a null byte injection or a double extension into the file name.
So, I located a PHP reverse shell and modified the file to connect to my second attacking system (see Setup from above). Then I copied the file and added the PNG extension to the new file.
cp php-reverse-shell.php php-reverse-shell.php.png
Next, I clicked on the Browse button and selected the newly named file. Once selected, I clicked on the Upload Image button.
Success!
To validate that the php-reverse-shell.php.png file uploaded, I added /uploads/to the URL.
Well, it looked like directory listings were not present. So, I decided to add the file name into the URL. Prior to modifying the URL, I started a Netcat listener on my second attacking system.
I got a shell!
Local Privileged Access:
Within the shell, I typed the whoami&&id commands to validate credentials. I noticed that everything that I typed within the shell was doubled. So, I escaped into a generic shell by issuing /bin/bash.
I changed directories and found /home/eezeepz was accessible with the apache account. I found an interesting file named notes.txt within the directory.
Based on the content of the file, I used the echo command to create the runthis file in the /tmp directory. Within the file, I issued the chmod command, from the /home/admin directory, to change the permissions on the /home/admin directory.
After a few minutes, I reviewed the /tmp/cronresult file. Seeing the runthis file was executed, I performed a directory listing on /home/admin.
Awesome! I repeated the same process for the /home/fristigod directory, but was not successful.
Stored Passwords:
Focusing on the /home/admin directory, I reviewed the contents of a few files that I thought were interesting.
Based on the cryptpass.py, I decided to reverse engineer the Python script in order to decode the ROT13 string, followed by decoding Base64 string and then printing the results in clear text. So, I opened a Python Interpreter and issued the following:
>>> import base64
>>> import codecs
>>> import sys
>>> rot13Str = “mVGZ3O3omkJLmy2pcuTq”
>>> base64Str = codecs.decode(rot13Str[::-1], ‘rot13’)
>>> clearTextStr = base64.b64decode(base64Str)
>>> print (clearTextStr)
thisisalsopw123
Although the following was not needed, I decided to polish up a little on my Python skills and modified the original script; just in case I needed it for the future.
Using the updated script, I decrypted the string within the whoisyourgodnow.txt file.
Local Privileged Escalation (SUID Binary):
Returning to the shell, I tried to issue the su command with the fristigod account. However, I needed to have an interactive shell. So, I entered the python -c ‘import pty; pty.spawn(“/bin/bash”)’ command into the terminal.
Next, I issued the sudo -l command to determine elevated application privileges.
Note: I was not able to figure out why I was receiving double-characters when typing or copying/pasting commands. So, I took screen shots of the results without the command input to tamp down on the annoyance.
Based on the returned results, the command of /var/fristigod/.secret_admin_stuff /doCom appeared to have elevated privileges. So, I entered the command into the terminal.
Hmmm…not sure what the error was about. So, I tried using sudo with the /var/fristigod/.secret_admin_stuff /doCom command.
It took me a few minutes to realize that fristi and fristigod were two different users. Once I figured that out, I then issued the command of sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom.
Based on the returned information, it appeared that the doCom program was able to be run with a terminal command argument. So, I issued sudo -u fristi /var/fristigod/.secret_admin_stuff /doCom whoami&&id.
Great! The doCom program was able to run terminal commands as root.
Flag:
To finish the challenge, I needed to find the flag. So, I listed the contents of /root with the command of sudo -u fristi /var/fristigod/.secret_admin_stuff /doCom ls -al /root.
The fristileaks_secrets.txt looked to be an interesting file. So, I issued the sudo -u fristi /var/fristigod/.secret_admin_stuff /doCom cat /root/fristileaks_secrets.txt command to review the text file.
Challenge completed. I can definitely say that I took longer than 4 hours to complete this challenge.
