Using our SMB knowledge ! Exploit Kenobi , a Samba themed box

Using our SMB knowledge ! Exploit Kenobi , a Samba themed box

The title heavily suggests that you look at the SMB guide before attempting this box, as a lot more will make sense and things will go a lot smoother...

As usual, as we've been tipped off that this is a Samba box meaning we should make use of the enum scripts for nmap, amongst the other specified smb-* tools.

nmap-ports

nmap-enum-results

In this latter image we see that the key domain has been found, along with the fact there is an anonymous share available !

Let's log into it

anonymous-share

This log file pretty much had everything about all the services we were interested in, it contents all the configurations for Samba and for proftpd which is the FTP server running on port 21.

Another interesting service is the rpcbind server on port 111, and essentially what it does is allows the administrator to map a set of programs (services) to a program number which a client can supply to execute that particular service. Now, this can be exploited if the client in question has disproportionate permissions and/or the data handed to the client on the publicly available rpc server is too sensitive.

We can begin to look at available services with rpcinfo 10.10.68.61

rpcinfo

So we can see there is a network file system available - which may have some of the drives of workgroup users , hopefully Kenobi's drive which had an SSH key !

We can enumerate the service with some good old nmap scripts:

nfs-volume

From this we can see that there is a publicly available drive called /var which we can actually make requests to and from. But this leverage will come in handy in a moment.

From our logs we can see that kenobi has generated some SSH keys, and they are currently stored in /home/kenobi/.ssh and we can also scroll a little further down in the logs and see the proftpd server is working under the user kenobi (that user started the service) meaning it is most likely keeping some sort of archive ... and as this is a beginner box we can assume the backup includes his keys as well.

Now if we can utilise some sort of vulnerability in proftpd to pull the key , whilst not being able to SSH directly into his computer, we can direct the files to this publicly available /var folder, and from there pull it back to us.

Looking through searchsploit we can see that there are some options:

searchsploit

Looking through these vulnerabilities we can see that the exploit looks at the intrinsic faults with the SITE CPFR and CPTO commands :

  • CPFR specifies the source file/directory to use for copying from one place to another directly on the server.
  • CPTO specifies the destination file/directory to use for copying from one place to another directly on the server

With this we can move the keys to other places on the server, and we know the rpcbind service is serving the /var directory as public so we can move it there to get access.

move-those-keys

We can run these commands to pull that /var directory onto our system now

mkdir /mnt/landing-bay
mount 10.10.68.61:/var /mnt/landing-bay
cd /mnt/landing-bay/tmp

Now whilst we're in the file system of /mnt/landing-bay we are still under the permissions of the user, and we can see that there is no modification if we want to change the permissions of the id_rsa within the actual /mnt/landing-bay directory , but no problem we just copy the files over...

Now that we're into the kenobi user machine its time to do the usual linux enumeration:

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

The room turns our attention towards the /usr/bin/menu binary and that it runs as root , we're also told to run strings to pick up some useful information. The curl program is used to pick up data from the localhost, but if we can replace the curl binary with our replica (same name on path, but different functionality than our shell would run as root).

finished

Remember to do this from tmp if you're going to update your PATH to include tmp , otherwise it will find the genuine curl first, but this way it will look in the local directory first and hence our shell runs and we're running within "root space" as menu was executed with root permissions, and being a child process we inherit the same space.