Initial Recon

Conduct typical initial portscan

└─$ nmap 10.10.11.208
Starting Nmap 7.93 ( https://nmap.org ) at 2023-04-26 11:13 EDT
Nmap scan report for 10.10.11.208
Host is up (0.089s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 2.59 seconds

Navigating to the web port (80) redirects to searcher.htb so I added that to my /etc/hosts file to make browsing easier and ensure proper functionality of the site.

The site has a meta search functionality that can generate a link or redirect you to the site. I am guessing this can be abused with some sort of command substitution. The bottom of the page indicates it is written in Flask and utilizes the Searcher 2.4.0 library. Well, it turns our Searchor 2.4.0 is vulnerable to command injection.

The specific patch is here.

With that in mind, I was able to get some command execution with the following search query string: test' + __import__('os').system('pwd'))#.

Initial Access

Using the command injection string above, I explored and enumerated the system:

• Ubuntu
• User: svc

I then used this access to inject my own SSH key into authorized_keys to get better access.

Privilege Escalation

There is a config.json file in the users home directory. Some searching landed me on this page: https://book.hacktricks.xyz/linux-hardening/privilege-escalation/runc-privilege-escalation

This turned out to be a dead end.

In the app directory /var/www/app there is a .git directory to explore.

Gitea does not provide anything additional but I did find that I could use this password for the svc user to see what commands can be ran as sudo. Of note is this entry User svc may run the following commands on busqueda:
(root) /usr/bin/python3 /opt/scripts/system-checkup.py *

The script is not writeable by the svc user but it does look like we can do something here.

Looking at the /opt/scripts directory, it is another git repo. It also contains additional scripts that it looks like the primary script calls. Running the full-checkup  command from the user home directory does not work but does work when running from /opt/scripts which seems to indicate that it is being called with a relative path to the local directory. Using this, I should be able to create my own script file to run.

This is indeed the case. I can create a file in a directory I can write to. I could use this to execute any command, but in this case I just did cat /root/root.txt to get the flag. I also had to set the file with executable permissions with chmod +x full-checkup.sh.