I’ve been spending most of my free time on Pentest Lab Pro as of late (post on this to follow), but last night I decided to sit down with a new boot-to-root box over at Vulnhub called IMF. I had a lot of fun with this box, as it had a bit of everything. Here’s my walkthrough.

1. Performing the obligatory nmap scan to find that the server only had post 80 listening on a relatively new version of Apache. I performed a UDP scan as well (nmap -sU 172.16.27.211) with no results.

2. Ran both Nikto and dirb scans on the server and found nothing of any relevance. Time to inspect the website the server is hosting for some clues.

3. The web application itself is a pretty minimalistic one with not much room for a client to interact with. I poked around the application, specifically the contact us page, to see if I could get something injected but it seemed fruitless. I started scanning through the source and found my first clue in the Contact Us Page which was flag number 1.

Any time I see a string ending with “=” I assume it’s base64. With a quick one-liner we can decode the string to find out it was, in fact, base64.

4. Now prior to me finding this flag I noticed that the css files had some odd file names and made a note to come back to investigate. I didn’t pick up on it at the time but flag1 was obviously a clue to look at the files that had the suspect names that also appeared to be base64.

I stripped out everything except for the filename (minus the extension, of course) and was left with the following string which I decoded in Burp using the Decoder tool.

screen-shot-2016-11-12-at-7-17-48-am-2

5. Judging by the fact flag1 was likely a clue, I’ll assume that flag2 is likely a clue as well. There were minimal spots for input on the application (and nowhere I could find to log in), so I assumed this was not a username but perhaps a directory. I was correct.

screen-shot-2016-11-12-at-7-21-22-am-2

6. I tried a few of the usual suspects for username / password (including imfadministrator) but had no luck. A view of the source code for that particular page revealed an interesting line.

When trying to enumerate usernames I noticed that the web application actually helped with this process where it would explicitly state if the username was incorrect. This made life much easier as it would help take the guessing game out of what the username was so I could focus on the password.

screen-shot-2016-11-12-at-7-24-59-am-2

The HTML comment above was made by Roger. I went back to the main front-end webpage Contact Us page and found a Roger S. Michaels listed as a Director. I tried the username rmichales@imf.local (presumably his Active Directory account) with no luck, but when I used rmichaels I got a different error and that was that the password was invalid and not the username. I now knew the valid username but needed to figure out how to get his password.

I tried a few usual suspects with no luck. I was getting ready to boot up Hydra to attempt a brute force but wanted to poke around and see if the “hard coded password” was exploitable.

After some serious Google-fu, I came across This Link which stated that we could potentially bypass the authentication method by tampering with the pass variable and sending an empty array.

I fired up Burp again, set the interception mode to On and tampered away (note that the password below is irrelevant, it’s the [] after the &pass variable that allows this attack to occur.

screen-shot-2016-11-12-at-7-38-43-am-2

We are then greeted with the following (Sorry about the Firefox logo in the screenshot – that’s not part of the web app 🙂 )

screen-shot-2016-11-11-at-9-28-37-pm

7. Flag 3 is decoded as the following

I do as instructed and see the following screen. My excitement of seeing the “Upload Report” link is immediately dashed when I see the following.

screen-shot-2016-11-12-at-7-44-18-am-2

I noticed the GET parameter in the URL and tried to see if I could perform LFI / RFI attacks with no luck. I stuck a single quote on the end of the URL to see if I’d get a MySQL error, which I did.

8. Alright so it looks as though we’ve got an application vulnerable to SQLi and we know that the database engine is MySQL based on the error. I fired up SQLMap and ran the following command to see if I could dump the database contents.

This produced the following dump

Note above that there is a “tutorials-incomplete” that is not linked in the main CMS.

Prior to leaving SQLMap I tried my luck at gaining a shell through the vulnerability but had no luck. (Command used : sqlmap –cookie=”PHPSESSID=bi7cs05nbc4evvqig29snclju6″ -u “http://172.16.27.211/imfadministrator/cms.php?pagename=home” –dbms=MySQL –os-shell)

9. Navigating to the Tutorials Incomplete page showed a picture of a whiteboard and a QR Code. Despite my better judgement, I scanned the QR Code which gave me the following.

flag4{dXBsb2Fkcjk0Mi5waHA=}

Now we’re getting somewhere.

10. I navigated to http://172.16.27.211/imfadministrator/uploadr942.php and was greeted with a nice little upload screen. I prepared the PHP reverse shell I got from Pentest Monkey and tried uploading it to the server but no love…invalid file type.

I tried simply putting the php code into a file named as a .gif but received the following error.

screen-shot-2016-11-12-at-8-16-41-am-2

11. I decided to pivot and go with a Weevely shell due to it’s extensibility.

There are a variety of ways to fool uploader forms into thinking a php webshell is an image, but I find the easiest way is to name the file hax.php.gif and append a GIF in the front of the webshell.

12. With the shell modifications we now have a successful upload. After pulling my head and trying a variety of methods to find out where my shell was uploaded, I looked at the source of the upload page and noticed a unique comment.

The comment is interesting to me and after a bit of trial and error I see my shell located at imfadministrator/uploads/adf15c479b2f.gif. I dial in with Weevely and get myself a limited shell.

Once logged in I do a quick ls and find my fifth flag.

Looks as though I’m now looking for a service or daemon named agent (or some variant). Before moving on I do a bit further research (download and execute linenum.sh) and notice an interesting firewall entry that shows both TCP 22 and 7788 running. Oddly, neither of those showed up in the original nmap scans so I assume they’re only available to the local box.

I try to access it via nc and see the following screen, which does not allow me to input any real data.

13.  In an effort to find some more information pertaining to the agent service, I do a find / -name agent*.  Among the slew of access denied’s I see reference to a /etc/xinetd.d/agent. A quick cat of the file reveals some interesting information, not the least of which is the location of the agent executable.

14. I navigate to /usr/local/bin to see what I can dig up. In that directory I see the agent file, but also see a file called “access_codes”. A cat of that file shows what appears to be a Port Knocking sequence of three TCP ports.

Installing the knockd executable on my Kali box I notice that SYN is the default method in the /etc/knockd.conf file. I take a shot in the dark and issue the following command which I hope will unlock a door.

TCP port 7788 is now available externally. While this is a step forward, it’s still not the big move forward we need as any attempt to overflow a buffer is met with errors.

NOTE : After some further research it appears as though the following nmap command would also work, which would prevent the need to install knockd

To be continued…