HOME
Find the Milnet VM on vulnhub.com!
From the very beginning, let’s enumerate all of the open ports to see what we’re dealing with. I like to run unicornscan on the full 1-65535 range for both UDP and TCP, then pass those ports to Nmap for a more thorough look – i.e. service enumeration.
As shown above, we’ve got SSH and HTTP ports open. Let’s take a closer look:
At this point I've taken a few moments to look for any quick wins (without antipication of finding anything). It seems to make the most sense for me to leave SSH alone and start enumerating the web server a bit further to see what we can come up with. Let's see what Nikto can see:
Cool. It looks like 'info.php' exists and contains the output from phpinfo() which will give us lots of information about the target. The RFI is a false positive.
Take note that this is running PHP Version 7.0.4-7ubuntu2. I also noticed that the OPcache engine seemed to be enabled which may allow for exploitation (see the following article). After poking around at this for a while, I decided to go back and take a look at the webpage, specifically looking at what requests are made as the site is navigated. Tamper Data is a great Firefox plugin for this activity.
Take a peek at the following POST request in Tamper Data:
Let's see what we can do by inserting various payloads as the 'route' value. Just might find command injection, LFI, RFI, SQLi, etc!
After digging around for a while, it appears that RFI is the way forward! Setting the 'route' value to my attacking server, we can see the HTTP request in the Apache logs.
Tamper Data:
Apache Logs:
Next I've setup a listener, setup a PHP reverse shell (Pentest Monkey's handy PHP reverse shell) and crafted the request with a little Python script:
...incoming shell!
Now that we're in, let's start enumerating all the things. Remember: Enumerate, Enumerate, Enumerate. Oh, did I happen to mention 'Enumerate'?
After taking a look at services, versions, networking, etc, I happened upon a nice text file that I've seen before. Could this be a rabbit hole meant to prolong my search?!
This tells me that if this is the vulnerable path, somewhere on the system is a script getting called automagically. Likely a cron job.
And the contents reveal:
So it wasn't a rabbit hole and in fact seems to be exploitable as the /var/www/html directory is writeable by the www-data user (our current user context)
Let's setup exploitation of this dangerous wildcard:
Contents of shell.sh:
Now we wait for <= 1 minute:
...until next time.
