The next machine from Hack the Box is Bank, an Ubuntu web server hosting a website for a…wait for it… a bank.

Starting with the regular nmap scan, we see ports 22, 53, and 80 open, with the default Apache home page showing on the web site.

The first thing I checked was the web page and ran gobuster to try and find any useful sub-directories. However, there didn’t seem to be anything to work with. On a hunch (based on previous HTB machines), I added an entry to my host file to associate the machine’s IP with ‘bank.htb’. Once this was done, visiting bank.htb re-directs to the login page below for a fake bank.

I tested a few common default credentials, but, not surprisingly, they didn’t work. I re-ran gobuster on http://bank.htb instead of the IP used earlier and found several new directories. Three just held the files used to load the website and nothing sensitive, one I didn’t have access to view, but /balance-transfer looked interesting.

Visiting this page gives a list of what appear to be individual bank transactions with encrypted customer information.

There were a large number of transactions listed on this page and all of them, except one, had a size listed between 580 and 585. The one below stood out for being less than half the size of the others.

Opening this transaction shows clear-text credentials for the customer Christos Christopoulos on a transaction that appears to have failed to be encrypted.

Using these credentials on the bank login page found earlier allows us access to the customer’s dashboard, showing various pieces of account information.

The dashboard also has an option for “Support”, which leads to what seems to be a way of submitting a ticket and allows for a file to be uploaded.

My first reaction was to create a malicious php file with msfvenom and upload it through this page, hoping we can run it somehow on the web server. Below is the command used to generate the php code that was then copied into a file called “shell.php”.

Unfortunately, the site gives an error that only image files are allowed to be uploaded when trying to upload shell.php. Modifying the file name to an extension used for images uploads successfully, but isn’t very useful if we can’t execute the code. After a few other fruitless attempts, I looked at the source code for the page and found a way around their upload limitation using debug functionality that was not removed.

I re-named my php file to shell.htb and tried to upload it one more time. This time it worked successfully and my information/file was listed under the “My Tickets” section on the left side of the page.

Before clicking the “Click Here” option for my attachment, I started a listener in metasploit to catch the connection, assuming it was going to work. Luckily, the php code executed when the attachment was viewed and it connected back to my listener, giving me a meterpreter shell on the machine as the www-data user.

Now that we’re on the machine, we need to find how to escalate privileges. Looking for SUID files is usually my first step, so I dropped into a shell from meterpreter and used python to upgrade the functionality.

From my new shell, I ran a search for any files with the SUID bit set. One in particular stood out, a file called “emergency” in a non-standard directory.

Using cat on the file doesn’t give any useful information as it appears to be a compiled binary, but the binary is owned by root and can be executed by the www-data user. Running the file doesn’t do anything immediately noticeable, other than replacing our standard prompt with a #. Testing the prompt reveals it has created a new shell running with an euid of root.

And that’s all there is for Bank. I enjoyed this one, mainly because the last few I’ve done have ended up being pretty basic once you figure out what kind of exploit is needed.

Additional Notes

As this server was also running a DNS service, some additional enumeration could be done around this. I used dig to attempt a zone transfer on the server and found the sub-domains below, but they didn’t really help me get anywhere, though it’s very possible (and even likely) that I missed something.

• http://www.bank.htb
• chris.bank.htb
• ns.bank.htb

Recommendations

1. Restrict access to web directories that do not need to be publicly visible.
2. Enable alerting of some type for when a transaction log fails to be encrypted.
3. Ensure any additional functionality used for debugging is removed before code is put into production.
4. Remove the use of files on the server that allow a regular user access to a shell with root privileges. If additional privileges are needed, an account with appropriate privileges should be used.