ch4inrulz: 1.0.1Vulnhub Walkthrough
The ch4inrulz: 1.0.1 Vulnhub VM was rather fun to dissect. There were some tricks embedded into the VM to throw one off which certainly got me for quite a bit.
The ch4inrulz: 1.0.1 Vulnhub VM download can be found here: https://www.vulnhub.com/entry/ch4inrulz-101,247/
Here's the basic description taken from Vulnhub:
Frank has a small website and he is a smart developer with a normal security background , he always love to follow patterns , your goal is to discover any critical vulnerabilities and gain access to the system , then you need to gain root access in order to capture the root flag.
This machine was made for Jordan’s Top hacker 2018 CTF , we tried to make it simulate a real world attacks in order to improve your penetration testing skills.
The machine was tested on vmware (player / workstation) and works without any problems , so we recommend to use VMware to run it , Also works fine using virtualbox.
Difficulty: Intermediate , you need to think out of the box and collect all the puzzle pieces in order to get the job done.
The machine is already got DHCP enabled , so you will not have any problems with networking.
Happy Hacking !
v1 - 25/07/2018 v1.0.1 - 31/07/2018 *Fixes DHCP Issue*
1. Service Enumeration
Using the following nmap command: nmap -O -A -sT -sV -p- -T5 192.168.1.27 -vvv
We get the following output:
There wasn't anything to do here. Misleading service.
Started this off with a Nikto scan. Here were the results:
The were a few interesting things in here. Specifically looking at the index.html.bak file.
Viewing the index.htm.bak file we get the following contents:
Using John the Ripper we were able to get the password as frank!!!
The development page:
This time I used the dirb scanner to find the uploader page as nitko was not of much use here:
From there I crafted an "image" file with embedded PHP code. I found a PHP shell online and created a new file called shell.gif. After creating the file, I pasted the code and added a line to the file to trick file uploader into thinking it is infact a GIF file:
There wasn't much else to do from here. I did not know where the file was uploaded path wise. That's where the Port 8011enumeration comes into play.
Nikto did not provide anything useful for this part. So I ran another dirb scan and got something interesting related to an internal API:
The API page had a number of pages or calls to make. However, 75% of the calls/pages were not created or incomplete. The one call/page that we were able to utilize was a files_api.php page:
So we know two things from this now. The PHP page expects a parameter called "file" and that the data needs to be passed in raw format. From here I used curl to see if a Local File Inclusion (LFI) was possible by calling /etc/passwd:
At this point I know I can call my embedded PHP gif file using a LFI but still was unsure of the location. I ran numerous tools like nikto, dirb, and dirbuster to see if it was possible to brute force the name of the upload directory. Then I remembered that Frank likes to use patterns. Frank even said he likes to use them. So I tried a number of different combinations with the word upload in it until I found the designated folder upload path of /var/www/development/uploader/FRANKuploads/
On my Kali attacking machine I started a netcat listener. In another terminal I used the following command to call my embedded shell code which creates a reverse TCP shell:
root@kali:~/Desktop# curl -X POST -d "file=/var/www/development/uploader/FRANKuploads/shells.gif" http://192.168.1.27:8011/api/files_api.php
Using Python I generated a more interactive shell
python -c 'import pty; pty.spawn("/bin/bash")'
In Frank's home directory there is a key:
www-data@ubuntu:/home/frank$ cat user.txt cat user.txt 4795aa2a9be22fac10e1c25794e75c1b
From here I tried to run the unix-privesc-check tool that comes with Kali by hosting the file via Apache on my Kali machine and downloading it to the target. Nothing interesting was returned here.
One of the things anyone should do is a check on the kernel and OS version. Of course, I did not immediately do this upon obtaining limited shell access. If I had done this sooner I would've been able to find one of the few Linix Kernel 2.6.35 privilege escalation exploits on Explot-DB / Searchsploit CLI.
I hosted the code on my attacking Kali box and downloaded it on the target machine:
The 15285 exploit correlates to:
Linux Kernel 2.6.36-rc8 - 'RDS Protocol' Local Privilege Escalation | exploits/linux/local/15285.c
I then compiled the code and ran it to obtain a root shell:
And of course grabbed the last key under the root directory: