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.
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
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
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:
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:
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.
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).
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.