Vulnhub Prime: 1 — A Local File Inclusion (LFI) Vulnerability

This walkthrough will attempt to solve VulnHub’s Prime 1 CTF VM. The box contains several vulnerabilities, but the exploit chain centers on a local file inclusion (LFI).

As with almost every hacking attempt, we started with network reconnaissance to discover hosts and identify the target (Figure 1).

Focusing on the target (Figure 2), we ran a port scan to identify which services were exposed. Also continued to scan the host with Nmapto identify running services in detail (Figure 3).

The target had port 80 open, serving a web page. We inspected the site (Figure 4) and ran directory discovery to find potential paths and resources (Figure 5).

The scan showed the target is running WordPress (Figures 5 and 6).

With the same directory scanning tool, we enumerated files ending in .txt (Figure 7). Accessing the secret.txt URL revealed a clue on the website (Figure 8).

Initially, the clue on the GitHub page (Figure 9) was confusing to interpret and required some trial and error.

Applying the hint from secret.txt (Figure 8) and the fuzzing command shown in Figure 9 to other potentially valid directories revealed a new clue (Figure 10).

We ran Dirb again, this time targeting files with the .php extension. The scan showed two php files (Figure 11).

After accessing image.php and appending the clue from Figure 10 to the URL path, we tested various inputs to see if the server would load arbitrary files.

The output provided above in Figure 12 confirmed the presence of a local file inclusion (LFI) vulnerability that allowed to see the list of user account information. This happened because the web app let us control the file path it used to load files, without validating the input.

We then used curl to retrieve the file and display its contents in a more readable format.

We came across two user accounts on the system: Viktor and Saket.

With Saket’s information and again some trial-and-error on the site, revealed a valid path containing a password-like string (Figure 15).

With the target SSH port open, we attempted to authenticate as user ‘Saket,’ but the string provided as hint was invalid for SSH login.

But, using the same string as the password for the user ‘victor’ granted us access to the Wordpress platform (Figures 15 and 16).

We searched for writable files to inject a payload and found secret.php (Figure 17), which could allow us to add a snippet for code execution.

We located a suitable reverse-shell script among Kali’s bundled webshells (Figure 18), edited its target IP with vim to point at our machine (Figure 19), and launched a listener to catch the incoming connection (Figure 20).

We pasted the PHP reverse-shell code that was updated with our listener IP into secret.php on the WordPress site (Figure 21).

When the listener received no connection, we reviewed WordPress file-structure documentation (Figure 22) to see where the reverse-shell was stored on disk, then invoked that file via its disk path to trigger the callback.

After correcting the uploaded shell’s URL path, the reverse shell connected successfully (Figure 23).

Once we identified the target’s Ubuntu version (Figure 24), we used Searchsploit to find a matching local exploit (Figure 25), transferred the exploit to the target, and attempted privilege escalation.

We served the exploit from an Apache host (Figure 26) downloaded it to the target via our existing access (Figures 27–28).

Once the exploit was transferred and compiled with gcc (Figure 29), we executed the binary to escalate to root and capture the flag.