Undiscovered
Last updated
Was this helpful?
Last updated
Was this helpful?
Browsing port 80 takes us to the following page below.
From here I checked directories with dirsearch.py and was unable to discover anything of interest.
Checking NFS also proved futile as I was unable to show any mounts. From here we can check for sub domains with wfuzz.
As we have results for multiple sub domains we should look for the key difference which is the lines returned where deliver and booking are of interest. Add both of these to the /etc/hosts file.
Viewing booking.undiscovered.thm in the browser:
And deliver.undiscovered.thm:
From here I ran enumeration with dirsearh.py against both sub domains and was unable to get anything from booking.undiscovered.thm. I was however able t get results on deliver.undiscovered.thm.
Over on /cms I tried logging in with the CMS default credentials of admin:admin.
I was however unsuccessful. I then caught the request with Firefox and used this to build a bruteforce attempt with Hydra.
After a short while we get a valid response in Hydra.
Using searchsploit we can see RiteCMS 2.2.1 has a couple of authenticated RCE exploits.
As per the listed steps head to Adminsitration > File Manager and upload a web shell.
Once uploaded you will be given a direct link to the file. As per below we now have RCE.
I then set a netcat listener on my attacking machine and then run the following command in the webshell.
Where we retrieve a proper reverse shell.
From I then transferred over linpeas. After we find the following below.
We can mount the /home/william directory on our attacking machine. On the attacking machine run the commands below:
When attempting to cd into /mountpoint we are given a access denied error. Viewing the permissions of /mountpoint shows that the owner and group owner are set as nobody:4294967294
This problem exists because of UID mapping. We need to ensure the user intended to access /home/william exists on the attacking machine with the same UID as on the target machine.
Checking /etc/passwd on the attacking machine we see william has a UID and GUID of 3003.
From here we can set up a user called william on our attacking machine with the same UID and GUID and then attempt to access the share again.
Creating a new user on the attacking machine:
We can su to william with the password defined in the last step and the cd into /mountpoint.
As we have effective access as the user william into his home directory we can set it up so we can SSH in as the user william.
On the attacking machine do:
Complete the process without providing a password. Then create the .ssh directory in /mountpoint then echo the contents of the attacking machine /home/kali/.ssh/id_rsa.pub into /mountpoint/.ssh/authorized_keys.
On the attacking machine as the user william
Then echo the contents of /home/kali/.ssh/id_rsa.pubinto /mountpoint/.ssh/authorized_keys
After doing so we can connect to SSH as the user william without providing a password.
After connecting and checking the directory again we see that script has a SUID bit set for the user leonard.
Running the binary with the parameter 'test' shows an attempt to use /bin/cat to read from /home/leonard/test.
We can try with the parameter .ssh/id_rsa to see if we can read a SSH private key.
We can then copy the key to our attacking machine and use the following command to set the correct permission on it.
We can then SSH in as leonard ensuring the id_rsa key is specified.
Now that we are leonard and running linpeas shows that vim.basic has cap_setuid+ep set.
Checking GTFOBins for vim capabilities.
We see we need to edit the command a little bit here.
Once connected in we need to escape from vim using :!/bin/sh
We are now root.
