Keep Calm and Hack The Box – Blocky

As a full-stack developer, I‘m always eager to test my skills and learn new techniques to build more secure applications. Hack The Box (HTB) provides an excellent training ground to legally practice penetration testing in a safe, controlled environment.

In this guide, we‘ll walk through compromising the retired Blocky box while analyzing the security mistakes that made it vulnerable. Beyond a step-by-step walkthrough, we‘ll also explore secure coding best practices and proactive defense strategies to mitigate such risks in our own web projects. Let‘s hack and learn!

Introducing Blocky

Blocky is an easy-rated HTB Linux box running a WordPress blog with a Minecraft theme. The ultimate goal is to exploit misconfigurations and security flaws to gain unauthorized root access on the system.

To break into Blocky, we‘ll follow this general attack path:

1. Scan the target to identify open ports and services
2. Enumerate the WordPress installation for vulnerabilities
3. Analyze exposed JAR files to extract sensitive information
4. Crack hashed login credentials to gain an initial foothold
5. Exploit sudo misconfigurations to escalate to root privileges

Our hacking toolkit will include a mix of open-source scanners, brute forcers, and analysis utilities:

• Nmap for port scanning and service enumeration
• WPScan to detect WordPress vulnerabilities and users
• Gobuster to brute force web directories and files
• Nikto for web server scanning and vulnerability checks
• JD-GUI to decompile and analyze Java code
• John the Ripper for password hash cracking

Before we start, always remember to exercise caution and stay within legal limits when practicing your hacking skills. With our plan established, let‘s dive into enumerating Blocky‘s attack surface.

Enumerating the Target

Enumeration is the key that unlocks most penetration testing engagements. By systematically mapping the target‘s ports, services, and applications, we paint a clearer picture of potential security gaps to investigate.

First, we‘ll run a comprehensive Nmap scan to identify open ports and fingerprint services:

nmap -sV -sC -oA nmap/blocky 10.10.10.37  

• -sV probes open ports to determine service/version info
• -sC runs default nmap scripts for deeper enumeration
• -oA outputs results in all major formats

Nmap discovers three open TCP ports:

• 21 (FTP)
• 22 (SSH)
• 80 (HTTP)

The OpenSSH 7.2p2 service on port 22 likely rules out any SSH exploits, as this is a fairly secure version not subject to any widespread vulnerabilities.

We‘ll shift our focus to enumerating the Apache httpd 2.4.18 web server on port 80. Firing up Gobuster, we‘ll brute force common web directories:

gobuster dir -u http://10.10.10.37 -w /usr/share/seclists/Discovery/Web-Content/common.txt -x php,txt,html

• dir mode performs directory brute forcing
• -u specifies the target URL
• -w sets the wordlist to use
• -x looks for specific extensions

The /wp-content, /wp-login.php, and /wp-includes paths strongly indicate a WordPress installation. We also spot a promising /plugins directory to examine later.

WPScan‘s WordPress vulnerability scanner confirms a WordPress 4.8 installation and detects a "notch" username:

To round out our web enumeration, we‘ll run a quick Nikto scan to check for any outdated software, misconfigurations, or exposed sensitive files:

nikto -host http://10.10.10.37 -C all    

• -host designates the target
• -C all enables all optional scan checks

While Nikto doesn‘t report any critical findings, it does highlight some interesting paths like /wp-content/uploads and /plugins to explore manually.

Unpacking the WordPress Application

With a WordPress installation confirmed, let‘s poke around the blog to understand its functionality and uncover any security flaws. Visiting http://10.10.10.37 in our browser displays a basic Minecraft-themed blog titled "BlockyCraft":

A quick pass through the site reveals no obvious vulnerabilities or leads. However, browsing to the /plugins directory uncovers two intriguing JAR (Java Archive) files:

JAR files package compiled Java class files and resources into a single compressed archive for distribution. If these JARs contain the WordPress plugins powering Blocky, they may yield sensitive configuration details like hardcoded database credentials.

We‘ll download BlockyCore.jar and use the JD-GUI decompiler to analyze its source code:

Jackpot! Drilling into the BlockyCore class file, we spot a mysql_pwd variable that appears to contain a hardcoded password string.

As full-stack developers, this is one of the cardinal sins of application security. Hardcoded credentials make it trivial for attackers to extract sensitive secrets if they gain access to source code or compiled binaries. Accidentally exposing a JAR file like this is equivalent to shipping your database password in plaintext for the world to see.

Instead, secrets should be stored securely outside of code and accessible only through strictly controlled methods. Techniques like encryption, secure configuration vaults, and environment variables help reduce the risk of credential exposure.

Armed with potential database creds, let‘s see if we can access Blocky‘s MySQL database and extract any useful information.

Pillaging the Database

Earlier in our enumeration, Gobuster uncovered a /phpmyadmin path hinting at a phpMyAdmin database administration panel. We‘ll navigate to http://10.10.10.37/phpmyadmin and log in using our newly discovered credentials:

We‘re in! With full access to Blocky‘s WordPress database, we can pillage it for any sensitive data. Let‘s start by dumping the wp_users table to gather WordPress user details:

SELECT * FROM wordpress.wp_users; 

This confirms the "notch" user account spotted by WPScan and reveals a password hash string. We‘ll use a hash identifier tool like hash-id to fingerprint the hash type:

Hash-id reports the hash as MD5, a widely used cryptographic hash function. However, MD5 is severely flawed for password storage due to its speed and lack of protection against hash cracking.

PHP provides stronger, more modern password hashing APIs like password_hash() which integrate proper salting and bcrypt or Argon2 algorithms. As security-minded developers, we must advocate for secure password storage practices in our applications.

Cracking the Hash

To crack notch‘s MD5 password hash, we‘ll load it into a file and feed it to John the Ripper (JtR) for dictionary-based cracking:

john --format=raw-md5 --wordlist=/usr/share/wordlists/rockyou.txt notch_hash.txt

• –format specifies the input hash type
• –wordlist designates a dictionary of potential passwords

In mere seconds, JtR reveals notch‘s password: 8YsqfCTnvxAUeduzjNSXe22. We now have a set of user credentials to attempt system access over SSH:

ssh [email protected]

Success! After entering notch‘s password, we land an SSH shell and secure our initial foothold on Blocky. Enumerating notch‘s home directory reveals a user.txt flag, indicating we‘ve achieved a user-level compromise of the box.

Elevating to Root

While user access is a solid achievement, our ultimate goal is to gain full administrative control by escalating privileges to the root superuser. After landing on any Linux system, it‘s a smart habit to check your sudo rights:

sudo -l  

Yikes, the (ALL : ALL) ALL sudo rule means notch can run any command with superuser privileges. This is extremely dangerous and violates the principle of least privilege.

Notch‘s excessive sudo rights make it trivial to spawn a root shell and completely own the Blocky system:

sudo su  

Exploring the /root directory uncovers the final root.txt flag. We‘ve successfully achieved a full vertical compromise of Blocky from unauthenticated access to total administrative control!

Lessons Learned

Blocky fell to a combination of outdated software, insecure password storage, sensitive files exposed to the web, and excessive user privileges. Beyond the satisfaction of owning the box, tackling this challenge highlights several valuable lessons for developers and defenders:

1. Regularly update and patch WordPress installations and plugins to mitigate known vulnerabilities. The WPScan WordPress Security Scanner is an excellent tool to assess your WordPress attack surface. Also consider implementing a Web Application Firewall (WAF) to defend against common threats.

2. Never store credentials or secrets in plaintext or hardcoded in source code. Adopt secure storage techniques like encrypted config vaults, environment variables, or key management services. Audit your code and repositories for any accidentally committed secrets.

3. Follow secure password storage best practices. Bcrypt, Scrypt, PBKDF2, and Argon2 are purpose-built password hashing algorithms. Ensure your authentication implementation uses proper salting, iteration counts, and hash functions like SHA-256.

4. Carefully control access to sensitive config files and development assets. Implement strong access controls, .htaccess restrictions, or store critical files outside web root. Conduct rigorous testing to identify any unintended exposure.

5. Apply the principle of least privilege for OS and application permissions. Only grant the minimum access a user or service requires. Regularly audit and right-size broad privileges. Consider implementing centralized access management and monitoring solutions.

6. Foster a culture of collaboration between development, operations, and security teams. Integrate security testing into your SDLC to identify flaws before production release. Prioritize secure design principles and empower everyone to raise security concerns.

By building security-centric development practices and proactive defenses, we can harden our applications against the techniques attackers frequently leverage. Although adapting this new mindset takes practice, your enhanced secure coding skills will pay dividends in your development career.

Final Thoughts

We successfully compromised Blocky by exploiting an exposed JAR file, cracking a weak password hash, and abusing misconfigured user privileges. Crucially, we also extracted valuable security lessons to level up our secure coding abilities.

I highly encourage aspiring penetration testers and developers to explore Hack The Box for themselves. With numerous realistic scenarios, HTB is the perfect training ground to practice your offensive and defensive security skills.

For further reading, I recommend the OWASP Top Ten Proactive Controls and OWASP Application Security Verification Standard to guide your secure development journey. You can also connect with me on Twitter and GitHub to continue the conversation.

Remember, the battle to secure our applications is ongoing. But by thinking like a hacker and striving to build proactive, layered defenses, we can certainly shift the advantage. Seize every opportunity to hack, learn, and evolve. Stay curious, stay hungry, and keep calm and hack the box.