TryHackMe: Vulnversity

Meta Information: This is a room I recently completed on TryHackMe. I figured I’d do a write up of what I found, how I got in, and things that a potential sysadmin would want to do to fix their server. I’m writing this from the point-of-view of a independent security consultant.

Description of Server

The machine in question appears to be an Ubuntu Linux machine, with a number of open ports and protocols:

For the purpose of this write up, only the Apache HTTP server was investigated.

Test Methodology

The penetration testing was performed using Kali linux and the tools associated with it. The machine was probed and attacked over a VPN connection, but it is assumed that the machine would represent an internet-facing machine with no firewalls or security layers in place other than those present on the machine itself.

Apache Server Penetration

The Apache server appears to be serving a public website advertising a university. No obvious framework or content generator could be determined.

First, a scan was performed using a directory fuzzing program (gobuster) to discover directories not immediately visible accessible by the normal website frontend. An internal upload form (/internal) was discovered.

The form appears to implement server side verification for file extension types, and another fuzzer (burpsuite) was used to determine allowed file types. phtml files were allowed, so a reverse shell payload was uploaded as a phtml file.

The upload form placed the payload file in /internal/uploads, where it could then be executed and create a shell session for the www-data user, who was running the PHP process.

Using local enumeration tactics, a single user was found on the server (bill), and this user’s home directory was able to be read by the www-data user, yielding the user flag.

linpeas, a privilege escalation recon script was uploaded and ran, and it showed that /bin/systemctl was available to our www-data user and could be freely executed. Another PHP reverse shell payload was uploaded and installed as a service file, allowing root access to the server.

Recommendations

Protect The systemctl Executable

This executable was available to the www-data user, and allows trivial root access by use of the suid flag. The permissions on this file should be changed to block access to only the root user of the system, and the suid flag removed.

Require Authentication For /internal

This form is unsecured and allows uploads to the server from any address. Access controls should be put in place immediately to prevent unauthorized use.

Prevent Apache PHP Execution

Once our payload was uploaded, Apache executed the PHP file without question. This should not be allowed by default.

Filter User Uploads

In this case, we were able to upload a php shell payload, but other malicious files could be uploaded to the server. If allowing user uploaded files to be served publicly, care should be taken to ensure the file is valid for its intended use, such as ensuring it is truly an image file.

Adjust User Home Directory Permissions

The www-data was able to view the contents of bill’s home directory without any additional privilege escalation. If sensitive files are being kept in the home directories, permissions should be adjusted to block public reading.

Wrap Up

I’m still learning, so I’m sure there are more things wrong with this machine that I missed. I’m also sure there’s more I can write about, I’ll probably revisit the room once my skills are better and see what else I can find.