Busqueda — HackTheBox
Busqueda is an easy machine from HackTheBox. It involves exploiting Arbitrary Code Injection in website using vulnerable searcher library to gain initial access, taking advantage of password reuse and abusing custom python script for privilege escalation.
NMAP
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 256 4fe3a667a227f9118dc30ed773a02c28 (ECDSA)
|_ 256 816e78766b8aea7d1babd436b7f8ecc4 (ED25519)
80/tcp open http Apache httpd 2.4.52
|_http-server-header: Apache/2.4.52 (Ubuntu)
|_http-title: Did not follow redirect to http://searcher.htb/
Service Info: Host: searcher.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernelPort 80 (HTTP)
Add the domain searcher.htb in the /etc/hosts file and open the website in browser. This website seems to be a type of search engine using Flask and Searcher library whose version is 2.4.0. We can submit queries at the bottom.
Whatever we search, depending on the engine, it would generate a URL for us with a query parameter appended at the end.
Website just returns invalid engine if the search engine doesn’t exists.
Searching for Searcher 2.4.0 , it appears that it is vulnerable to Arbitrary Code Injection.
Looking at the PR mentioned in the above resource, we can see the source code. This is vulnerbale because it uses eval to run the queries.
I exploited this by injecting the following payload which pings our host, in the query parameter. This confirms that the code is executed.
'),__import__('os').system('ping+10.10.14.71')#
Now, just replaced the ping command with reverse shell payload successfully got shell on the target.
It was git rep, and I tried to view the logs but found nothing. Instead, within the directory there were some credentials in the config file.
Checking the passwd file, there’s no user cody.
Using the password with svc user, got logged in via SSH.
Privilege Escalation
Checking the sudo privileges, the svc user can run some python script as root.
Checking the permissions on script, we can’t modify or read it.
So, executing the script, it seems that we can specify three options. Running the docker-ps option, we can see that there are containers within the machine.
The full-checkup option doesn’t works for some reason.
For docker-inspect options, we need to specify a format. Looking from the docker inspect documentation, i specified {{.Config}} format, and got some credentials.
Since, we saw that gitea is running, we can try to access the Gitea instance at port 3000 via port forwarding using the following command.
ssh -L 3000:127.0.0.1:3000 svc@searcher.htbFirst using the credentials from the /var/www/app repo, we can login as cody user. But there’s nothing interesting.
Looks like there’s another user administrator.
Trying the password that we got from docker-inspect command, we got login as administrator.
There’s a scripts repo that contains the python script that we can run as root with sudo.
Reading the script, in the process_action function, the full-checkup seems to run a script, but it does not specify the absolute path of the script. We can abuse this by creating a fake copy of this script and place our reverse shell payload in it.
We just create full-checkup.sh in current directory, place our reverse shell payload in it and make it executable. Running the sudo command, we get a reverse shell as root.
