TryHackMe: LazyAdmin Walkthrough

TLDR

The initial weakness of this box is the ‘Lazy Admin’ left the SQL backup file for the SweetRice CMS on the web server. An attacker can download the file, review the SQL statements and retrieve an MD5 password hash.

The password is simple and easily cracked, allowing access to the SweetCMS backend, from which an attacker can upload a reverse shell providing low-level remote access to the web server.

Further enumeration of the server reveals a script executed with elevated privileges. An attacker can modify the file's contents to execute their commands and elevate the privileges, granting unrestricted access to the web server.

Required Tools:

• Penetration Testing OS - Kali or Parrot OS (or whichever security-focused OS you prefer)

• PentestMonkey PHP Reverse Shell: https://github.com/pentestmonkey/php-reverse-shell/blob/master/php-reverse-shell.php

• LinPEAS.sh (optional): https://github.com/peass-ng/PEASS-ng/tree/master/linPEAS (not required, but bonus content)

Stage One: Enumeration

As always, I start with a quick Nmap scan optimised for speed rather than accuracy and identify two ports - 22 (SSH) and 80 (most likely HTTP).

After identifying open ports, I launched a more detailed Nmap scan to identify potential vulnerabilities. While the detailed scan ran, I reviewed the potential web server on port 80 and was immediately greeted with an Apache2 landing page.

Immediately, we can conclude that the server is running Apache2 webserver on Ubuntu. As a web administrator.

I reviewed the source code for the default landing page and found nothing useful.

The next logical step would be to perform web directory enumeration using Dirbuster; I quickly found a directory worth exploring - http[:]//10.10.91.55/content.

Accessing this directory brought up the SweetCMS application but nothing screamed vulnerable from the page or source code. However, searchsploit did provide a few results worth exploring.

Cross-site forgery did not seem like a path worth exploring, and I focused on the other exploits/information bits. After reviewing the code/text for each the one that stood out was the SweetRice 1.5.1 - Backup Disclosure (40718.txt).

This disclosure did not require any credentials was the easiest to try out; sure enough, I was able to retrieve the MySQL backup of SweetRice CMS.

This paid off; fortunately, an MD5 password hash was included in the SQL file, as well as potential usernames—admin and manager.

I made a quick dash over to craskstation.net, and I retrieved a password - Password123.

Stage Two: Exploitation

At this point, I have a set of potential credentials but only one logical place to try it out - SSH. I tried logging in manually with no success and opted to brute force the credentials during a brief moment of desperation.

“Insanity is doing the same thing over and over again, but expecting different results.“ - Rita Mae Brown.

It is time to move on from that rabbit hole and find a different path.

I tried reviewing the SweetRice website documentation about installation and configuration but found nothing immediately useful. After reviewing the other searchsploit exploits, I noticed they all mentioned the ‘as’ directory and bingo! We now have a login page to try out our credentials, and if unsuccessful, we can proceed to SQL injection.

Our credentials work—manager and Password123. Now, we need to figure out how to get low-level access to the web server. After reviewing the SweetCMS backend, I came across the Media Center section, which allows file uploads.

I already reviewed the SweetCMS website documentation and know the application runs on PHP. I already have the PentestMonkey PHP reverse shell script from my TCM PNPT download (Github repo), and I only need to amend the IP address on line 49 to point back to my attacker IP address.

Once the PHP reverse shell script is uploaded, I only needed to open a listening port using Netcat and access the reverse shell script (right-click the uploaded file hyperlink on SweetCMS and select ‘Open link in new tab‘). We now have low-level access to the web server.

User Flag: The user flag is in the /home/itguy directory.

Stage Three: Privilege Escalation

This particular box was a bit frustrating, mainly because my reverse PHP shell was unstable, and I had to keep reinitialising the connection back to my attack box.

The mysql_login.txt file is a dead end; in my case, the credentials did not allow access to MySQL or SSH. As I write this walkthrough, I realise I should have tried the credentials on the SweetCMS backend login; there is always next time.

The backup.pl file was a bit more interesting, but I did not see how it related to the box; it points to the /etc/copy.sh, file, which had unusual permissions.

Given that I am running as www-data, I will unlikely have permission to execute anything useful or retrieve the bash history and turn to Linpeas.sh. I managed to copy over linpeas.sh via the Python SimpleHTTP module and executed it. This is definitely overkill for a box like LazyAdmin, but to save time (and sanity), this script will enumerate and highlight anything that can be exploited to elevate my privileges.

The most obvious vulnerability is the backup.pl script, which is executed with elevated privileges, which in turn executes the copy.sh script. We already have permission to write to the copy.sh script, so it stands to reason that I can elevate my privileges using this path.

As a precaution, I created a backup copy of the copy.sh script to the /tmp directory (the www-data account does not have permission to write to the itguy’s directory), and replaced the existing commands with my own—echo “/bin/bash“ > /etc/copy.sh

I tried to execute the backup.pl script hoping to get an elevated shell on the target web server, but got an error. Reviewing the SUDO permissions for the www-data account might require executing the full command to get elevated privileges.

However, my reverse shell became unresponsive, and I had to reinitialise it; this time, I succeeded and got an elevated shell.

Root Flag: The root flag is in the /root directory.

Conclusion

This box has a few ‘rabbit holes’ a pentester can get lost in. My key takeaway from this TryHackMe box is to try and develop the skill to quickly identify these rabbit holes and move on to the next potential vulnerability.

Mitigation Measures

Regardless of the web application being hosted and maintained, I believe the following steps will improve the security of the application and its users.

1. Ensure all non-necessary installation files and folders are removed after completing the installation of a web application. Do not leave scripts or files that may disclose the service/application and version running on your web server.

2. Ensure no database backups are stored on the same web server hosting the web application. If possible, set up a script to connect to your web server to download the backups before deleting them. This will prevent an attacker from downloading the backups to either gain access to your application and customer/user data or launch attacks on other systems. Maintaining ‘off-site’ backups is also good practice and ensures you can recover fairly quickly from cyber attacks or technical faults.

3. Ensure the applications you use do not store passwords in plaintext, and apply a strong encryption algorithm that uses a salt variable. For more information on ‘salting’, check out this article: What is a Salt and How does it Boost Security?

4. Disable any service and application default settings that would contribute to information disclosure via error reporting or display versions e.g. the Apache default landing page.

References:

Cover Image: https://tasniaponkti.com/2016/09/25/a-lazy-persons-guide-to-get-things-done/