HackTheBox: Beep Walkthrough

I finally got around to doing another HackTheBox machine, and this was surely an interesting one. The machine is Beep. We’re given an IP, and off to the races we go..

Reconnaissance

As I did last time, I began with a staged nmap scan.

First, a basic scan:

nmap -T4 -v -p- 10.10.10.7

After that, an intense scan of the open ports:

nmap -T4 -A -p22,25,80,110,111,143,443,878,993,995,3306,4190,4445,4559,5038,10000 10.10.10.7

Now this machine has a lot of open services, most of which don’t appear too interesting.

I grabbed the SSH banner using a metasploit module:

And I checked for any vulnerabilities in the mail server version:

Neither of these paths yielded anything interesting. Of course, these weren’t the focus anyways.. The real test will be the web application.

Web App Testing

My general approach to web app testing goes like this:

1. Run a vulnerability scanner to try to catch the obvious stuff.
2. Run gobuster to enumerate the directories.
3. While these run, perform some manual inspection and Google-Fu to see if the first two steps are even necessary.

(Side note: this pertains only to CTF. In a real environment, you may also want to look at the relative strength of your encryption algorithms, check to see if your tokens are predictable, etc.)

I fired up Nessus and gobuster. For gobuster, I used the command:

gobuster dir -u https://10.10.10.7 -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt -k -t 200

-k ignores certificate validity issues, which this site has. -t 200 sets the thread count to 200 so that it runs faster.

Visiting the IP on Firefox, this is what we get:

We get a bit of server information. A quick Google search didn’t turn up anything too interesting though. For Elastix itself, though, I found a couple of interesting exploits via searchsploit:

Now, nowhere could I find any version information about this Elastix server, but I figured there was no harm in giving these a shot, considering my other tests weren’t done running yet.

My first instinct was to go for the RCE, which proved fruitless. The exploit was written in 2012, and even with modification to meet the standards of the modern Python 3.7 libraries, I couldn’t get around the certificate validation problems. Here’s the modified code, in case anyone is interested:

And yes, I did open a listening port…

Next up was the LFI. Fortunately for me, it was basically just a matter of copying and pasting the link within a comment:

HTML page

Source — much more readable

I also noticed that the URL was pointing towards the /etc/ folder. Since this was an LFI vulnerability, I thought I might be able to view some other sensitive files:

/etc/passwd

/etc/shadow — not as lucky with this one

Furthermore, within the .conf file that started this avalanche of information, there were several passwords, including one that had been repeatedly mentioned. I decided to see where that password would get me.

Exploitation

I began with the /admin/ folder:

Access Granted

After perusing that for a few minutes and realizing it was a dead end, I took a shot at SSH:

Well, I wasn’t expecting it to be that simple. I won’t complain…

Lessons

1. Sanitize your inputs.
2. Sanitize your inputs.
3. Don’t put your password in plaintext files on servers exposed to the internet, or anywhere for that matter. Get you a good password manager.

That’s about it.