WWBuddy - TryHackMe Write-Up

Description: WWBuddy challenges us to exploit a vulnerable Linux-based web application still in development, exposing critical real-world flaws. The path to root begins with a classic SQL Injection vulnerability, granting initial system access. This is followed by the exploitation of the notorious Log4Shell (Log4RCE) vulnerability, enabling remote code execution through malicious log injection. The machine provides an excellent hands-on experience with web exploitation, webshell deployment, and privilege escalation on Linux systems.

STEP 1: Enumeration

To begin the assessment, we start by executing an nmap scan to identify open ports on the target system.

We discovered a web application running on port 80. Next, I used Feroxbuster to enumerate directories and identify potential accessible paths on the server.

This allowed us to enumerate the "/register"  endpoint, which, upon successful registration, granted us access to the application.

Once logged into the application, we have the option to update our user information and reset the account password.

STEP 2: Exploitation

Let’s analyze and exploit the application’s SQL logic. Typically, when updating a user’s password, the backend executes a query similar to:

This query updates the password for a specific user by matching their username. However, if user inputs are not properly sanitized or parameterized, this query becomes vulnerable to SQL Injection (SQLi).

By injecting a payload like:

Into the username field, we manipulate the WHERE clause to always evaluate to true. This effectively bypasses the username restriction and updates the password for all users in the database.

After injecting the payload to change the username condition (admin' or 1=1 -- -), we proceeded to update the password to Teste123. This action effectively reset the password for all users in the database to this value, allowing unauthorized access.

With this, we successfully authenticated into the WWBuddy account using the password Teste123.

After authenticating as Henry in the application and accessing the "/admin" endpoint, we discovered an interesting feature: the site logs potential intruders attempting to sniff the site, recording their IP address, date and time, and username.

Additionally, we found the first flag hidden within the page's source code.

STEP 3: Remote Code Execution (RCE)

The logs appear to record access to the "/admin"endpoint by other users. This opens up the possibility for log poisoning to achieve remote code execution (RCE) and potentially a reverse shell.

Currently, only the users Roberto and WWBuddy appear in the logs. By modifying their usernames to include a PHP web shell payload, we can attempt to trigger RCE via log injection.

When accessing the endpoint again while authenticated as Roberto, we noticed that the username no longer appears in the logs.

However, by reusing the cmd parameter that we previously injected into the username field, we were able to successfully execute system commands through the web shell. This confirms that the input is being directly interpreted by the server without proper sanitization, allowing for remote code execution (RCE).

The next step was to obtain a reverse shell. For that, we used a simple PHP payload that opens a socket connection back to our attacking machine:

Before sending it via the vulnerable parameter, we URL-encoded the payload to bypass any filtering mechanisms:

URL-encoded payload:

Reference: URL Encode and Decode - Online

Finally, we set up a listener on our machine using Netcat:

Once the payload was triggered, we received a reverse shell successfully.

STEP 4: Privilege Scalation

Finally, we escalated privileges by searching for binaries with the SUID (Set User ID) permission enabled. SUID allows a binary to be executed with the privileges of the file owner (often root), regardless of which user runs it.

To find all SUID binaries on the system, we used the following command:

Among the SUID binaries identified, we found that pkexec had the SUID bit set, a common target for privilege escalation due to its history of known vulnerabilities.

We leveraged a known exploit against pkexec, which allowed us to spawn a root shell. After uploading and executing the exploit on the target machine, we successfully gained root access.

Reference: GitHub - NxPnch/pkexec-exploit

Once executed, the exploit successfully escalated our privileges to root, allowing us to access the final flag located in /root.