1. Start off with enumeration of the machine.

2. A quick Nikto scan reveals a few potentially interesting things.

  • mod_negotiation is enabled with MultiViews which could potentially lead to brute forcing file names.
  • The PHP version is quite old – 5.3.10 (this was actually discovered via phpinfo() page that was discovered in the Nikto scan
  • The server offers several interesting HTTP methods : POST, GET, HEAD and OPTIONS.

3. The main page taunts the user to find a SQLi injection. I try running SQLMap against the POST form contained within the main page and get no love. I move on.

4. I move on to enumerate subfolders with dirb.

Of the above results, one piques my interest in particular which is the test page.

I try injecting a file parameter with a GET method in the URL but have no luck. I focus on the POST method with cURL and get lucky.

5. Time to start enumeration. At the moment it looks as though I really only have access to view files, and my options are likely limited to the www-data user. I start poking around and find some of the source code which points me in the correct direction.

Viewing the first include file c.php we get our hands on some mysql credentials.

Now to try to find a method to exploit the credentials. There is no directory at /phpMyAdmin or /pma (which are usual phpMyAdmin directories), so I launch another dirb enumeration with a larger word list this time.

The revised dirb provides a new directory – /phpmy which hosts a phpMyAdmin page.

6. Using the user/pass billu:b0x_billu as discovered in the c.php file I am able to log into phpMyAdmin. I see a database called ica_lab. Within that database there is a table called auth, which conveniently has the username and password stored in plaintext (biLLu:hEx_it).

Using these credentials I am able to log into the primary login screen…the one that taunts of a SQLi vuln.

7. Continuing to the Add User drop down, I see that I have the option of uploading an image file.

Simply adding GIF to the beginning of the shell and naming it .gif is not working. We need to use an EXIF trick to fool the uploader into thinking that our shell is an image and not malicious.

Start by creating the PHP reverse shell

Then we edit it to add our GIF data prior to the <?php tag.

Rename it as a .gif, upload it with panel.php and set up our listener.

8. The tricky part now is trying to get the system to call the code as PHP and not have it interpreted as a .GIF.

Poking around I come across the panel.php page which allows an authenticated administrator to either view the users, or add a new user. The Add User was already exploited to upload our malicious .gif shell, and some searching reveals that the Show Users option in the drop down might also be vulnerable.

I browse to the website with Burp Suite setup and send the load variable to the repeater to try to call my shell.

We are greeted with a session in Meterpreter.

9. On to privilege escalation. One of the first places I will always look is the Kernel to see if there is a vulnerable Kernel. It looks as though in this case we’re in luck.

I try the 37292.c exploit. I transfer the exploit to my web server, use wget from the /tmp drive to download the file to the target machine, compile and run.

Thanks for reading!