Hack the Box: Busqueda
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'))#.
Using the command injection string above, I explored and enumerated the system:
- User: svc
I then used this access to inject my own SSH key into
authorized_keys to get better access.
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.