🔎🦶Enumeration/Foothold
Before I begin each machine I kick off a full port scan with RustScan
and pipe the open ports found into NMAP
.
Noticing Port 80
is available I navigate to the website. I change my host file (sudo mousepad /etc/hosts
) and refresh to show the following –
I search Searchor 2.4 noted at the bottom for an exploit. I found multiple… (which I believe is just because this box came out a few months ago). Doing some additional research I found GitHub – ArjunSharda – Pull 130 which I believe directly highlights the bug. I also noticed a .git
directory on the box upon getting the svc
account so in the future I might (probably won’t) come back and try a different approach. Long story short this version is exploitable to a remote command injection. By putting in the following in the What do you want to search for: area-
and changing your ATTACKER_IP and PORT and starting of an nc
listener you can get a shell. Once on the box I use ssh-keygen
to create myself a public/private key so I can get a more stable shell.
Once on the box I navigated over to app to do a deeper dive. I remembered I saw a git
folder once I got on the box so I looked up the config and associated commits.
Using the information found in the config file we can now see a new user cody and a new subdomain, gitea.searcher.htb. After adding the sub-domain to my hosts file mouse /etc/hosts
I navigate over to the URL.
I logged in as Cody and was able to find nothing useful. I checked the Gitea
version, keys and commits with no avail. I decided to run LinPEAS
on the box and added Andy’s password. It came back with a hit –
Running the command shows the following –
I found a guide earlier when trying to do docker escapes which highlighted using inspect to find the configuration of the container Exploit-Notes – Docker.
I copied it over to my local machine and ran it through jq
to make it pretty:
The json
export provided me with a username and password for the gitea
database –
🔝Escalation to Root
With this new password I tried multiple avenues until I realized it was the other user, Administrator found in the gitea
application. Logging in showed the full-checkup.sh
and system-checkup
scripts from earlier.
In the system-checkup
script the full-checkup.sh
is not a fully defined path. We can take advantage of this by building our own full-checkup.sh
and executing the script in the same directory with sudo
. I built a one-liner
using python3
as it was on the box and called it full-checkup.sh
. I uploaded it to the box, setup a netcat
listener and executed the previous command in the same directory:
full-checkup.sh