Thursday, November 17, 2016

Vulnhub - IMF Walkthrough

Welcome! This is my walkthrough of the IMF challenge hosted on vulnhub.com. The actual url to this exact machine is: https://www.vulnhub.com/entry/imf-1,162/

And now....onto the walkthrough....

After loading the image into VirtualBox, it showed up as 192.168.6.101 on my local network.

First, I decided to scroll through the source code on the web pages, which is always a decent first thing to do. Sometimes, it can lead to hidden folders that were simply commented out, potentially interesting folders beyond /images, /css, and /js, or in this case the first flag!

 The flag was base64 encoded and after decoding it using linux-fu (echo <flag> | base64 -d) it read out 'allthefiles' (no quotes). Next, I tried browsing to the /allthefiles folder, but to no avail. Then I ran a dirbuster scan with a wordlist to see if there was a hidden directory I needed to find, but nothing jumped out there either. Then I noticed that there were some javascript files that had names that were base64 encoded so I tried to decode them and got part of flag2 in the output, so I concatenated the files together to create the next flag.


Now to base64 decode flag2...and we got 'imfadministrator' (no quotes). Again, I tried using the flag as path and this time it got us to a login prompt.

After trying imf:administrator as the first pair of credentials, I saw the response 'Invalid Username' so I tried admin, administrator, root and got the same response. Then I remembered the contacts on the contact.php page. I tried all three usernames (the first part of the email addresses) and rmichaels was the only one that returned 'Invalid Password'. Next, I took a look at the source code and the first thing I saw was a huge comment "<!-- I couldn't get the SQL working, so I hard-coded the password. It's still mad secure through. - Roger -->" (no quotes). Ok, no SQLi, but onto password guessing!

After password guessing for awhile (longer than I care to admit) I started googling for things along the lines of 'php password bypass'. Lots of SQLi pages came up but another page came up that said something along the lines of 'PHP password bypass for CTF'. *strokes beard*. After reading about this, apparently PHP does not do well with type conversions when comparing to zero and we can alter the POST request to send an array object instead of a string object for the password field and because of the type conversion issues, the php page will incorrectly allow us access.


Flag3 simply states 'continueTOcms' so I clicked on the link to continue my adventure. I found the CMS and poked around for a little bit. Nothing interesting in the source, no exploitable LFI that I could see. Then I tried SQLi on the pagename parameter. Bingo! After some initial failures, I finally realized that I wasn't including my PHPSESSID cookie with my sqlmap usage. I finally got my command:


The dump showed a new page that we hadn't seen before 'tutorials-incomplete' (no quotes). This page has a picture with a QR code. After scanning it, I got the fourth flag. The flag was 'uploadr942.php' so I navigated to that page next.


First I tried to upload a text file and got an invalid file type error. After trying a couple different formats, I finally found the jpg was accepted as a valid filetype. There isn't any information on where the picture was uploaded to so, I thought I'd try the obvious options /images and /uploads. /images returned a blank page and /uploads was forbidden. So it exists? Going back to the result there is a comment in the source code that didn't exist before; unique hash? Possible filename? The /images/<hash>.jpg was not found. /uploads/<hash>.jpg worked! Holy crap! Ok, so now I needed something I could use to execute code with so I grabbed a webshell included in Kali Linux and attempted to upload the webshell renamed with the .php.jpg extension. Unfortunately, this didn't work because 'CrappyWAF detected malware. Signature: fopen php function detected'. Well screw you too IMF.

The CrappyWAF also detected the 'system' function. ....seriously....and exec too....and shell_exec....and passthru...COME ON!

I found a stackoverflow page that listed out different ways to execute code via php and BACKTICKS seems to be working. I edited my php-webshell to use backticks instead of system/exec/whatever calls and I only got 'Error: Invalid file data' instead of CrappyWAF errors. Two steps forward, one step back. Now, how to make it look like valid data...

After trying for a couple hours I decide that jpg files are not going to work and I determine that png, bmp, and gifs are also acceptable formats. I used a technique I found online to write the magic number "FF D8 FF E0" to a fake gif file and then append straight php to the fake file. This FINALLY allows us to achieve code execution on the machine.



HAHAHAHA FINALLY! I can cat the fifth flag and move forward...

The fifth flag reveals the phase 'agentservices'. Hmmm....after perusing around the box for a bit, I found ssh listening on port 22 and an unknown service listening on port 7788. (I found out later that the agent services was referring to the .htaccess file that allows us to execute php from a .gif). I also found /usr/local/bin/agent and /usr/local/bin/access_codes while looking for files related to 'agent' on the machine. The /usr/local/bin/agent turns out to be an ELF executable and the access_codes file says 'SYN 7482,8279,9467' which looks like port knocking ports to me.

I am able to port knock the machine using nmap and then I can simply nc to the machine on port 7788 and the service is now available! So, from our php webshell I can 'cat' the contents of the 'agent' executable, but I need to find out what the Agent ID means.

First I copy the agent executable back to my local workstation and I run strings, nothing jumps out about the Agent ID but, I can see there are menu options that include Extraction Points, Request Extractions and Submitting a report. In addition, there are numerous cities and places, i'm assuming, to request an extraction.


After running into some issues and desiring a more robust prompt, I switched over to meterpreter and executed an msfvenom payload via the php backdoor shell and now have a meterpreter shell on the machine.


Finally, I am able to run ltrace on the agent executable and we can easily see the 'strncmp' call made with my provided value 'a' and the actual value needed '48093572'.


Ok now it looks like we have access to this executable and from our previous recon on the box we know this executable is running as root so, I think it's time to design a BUFFER OVERFLOW!!! *epic music*

So after a little fuzzing, I found that the Report (option 3) is able to be corrupted with a string length of 1024 "\x90"s so now, I need to find where the buffer overwrites EIP. To do this we can use pattern_create.rb. We found where EIP crashes and determined that the offset is 168 bytes into the buffer. To confirm this, we edit bytes 168-171 (inclusive) to be unique and when the program crashes, we should see our exact bytes that caused the application to crash.


Now that we've confirmed we can write to EIP, let's see which registers are also overwritten. It looks like eax is holding a pointer to an array of data that was overwritten by our pattern so let's investigate that more thoroughly.


So again, we used pattern_create.rb to create a pattern and put it into the application, and then we use pattern_offset.rb to calculate the offset of the buffer! Which is....


...offset 0? That seems awfully nice. Now, I need to find someway to get code execution to eax. Fortunately, there is a site called ropshell that you can upload a binary to and it will give you back some options including one for 'call eax' located at offset 0x00000563. You need a little more computer architecture knowledge to know that this will be located at 0x08048563 in memory (most linux executables are loaded at base address 0x08048000). Lastly, we just need shellcode which is easily generated by msfvenom. Now we have the exploit!


Let's try and see if it works! So, this specific script didn't work, but the format stayed the same. I had to add some time delays and I switched from meterpreter shellcode to regular shellcode. Here is the actual script that worked followed by my root privs.



Well, now all that remains is to see the final flag and wrap up this walkthrough! Drum roll please......................


This was an awesome exercise and I'd like to give credit to all the website I used while researching how to exploit this box. I'd also like to say I did compare my walkthrough to the other walkthroughs already posted on Vulnhub.com and it was very fun to see alternate and similar techniques used. All thoughts and comments are the authors and do not represent the thoughts or comments of anyone else. I hope you enjoyed this walkthrough! -Hack Responsibly. Hack Professionally.

3 comments:

  1. maybe you should put up the links that helped you get through..

    ReplyDelete
  2. i didnt get this : "I used a technique I found online to write the magic number "FF D8 FF E0" to a fake gif file and then append straight php to the fake file. "

    ReplyDelete
  3. FF D8 FF E0 is the file signature for gif

    ReplyDelete