Report

Cyber Security - An Offensive Mindset

Progress/Portfolio report Summer 2019

the pwning of teacher

Executive Summary

The popular e-Learning framework used in millions of schools and universities, Moodle, is vulnerable by design to exploitation. A student with stolen credentials or a malicious teacher will be able to upload code via Moodle in a number of ways in the goal of attacking the computer that runs the Moodle instance. This attack can provide full remote access to that machine, including the modification of any sensitive data, as well as the breach of the internal network, in which a number of other attacks can be done to compromise the entire school network.

The compromise of a school network can easily lead to identify theft, fraudulent modification of grades, access to the billing systems aswell as classified data between non students.

This report will identify a method of attack using a custom quiz question which provides initial access to the Moodle server. Enumeration methods will also be identified that allows the traversal of a non-priviledged user into full remote access via insecurities within the database data structures, as well as highlighting the effects of poor password concealment.

Objective

The objective of this report is to highlight the journey of my technical development within Offensive Security, culminating at the 4 week mark in the total exploitation of a machine that is highly rated as a ‘real-life’ scenario.
The machine in question is ‘Teacher’ from HackTheBox.eu, which involves the exploitation of the Moodle e-Learning framework and privilege escalation due to poor security of passwords. Both of these scenarios, especially a poorly secured password are highly prevalant in the every day world, and this knowledge is beneficial for my professional development, as the experience gained here can easily be applied to the real world. This experience will be needed if I pursue my security career in order to identify the low-hanging fruit of threats such as passwords or vulnerable software, and provide solutions to help secure an environment.

I will also explore my methods of enumeration, which is the thought process and order of operations that I have built for myself that will help me in achieving the exploitation of a machine. As I practice on real world machines and vulnerable machines provided by a hobby website, my list of enumeration steps expands, and helps me in achieving an initial foothold in the exploitation. This step is incredibly important, as not only does enumeration grow vertically in number of items to iterate through, but through experience it also grows laterally - using the same steps in different methods, or paying closer attention to the simpler steps in order to find a foothold.

Tools

To connect to the HackTheBox environment, we are given an OpenVPN package which we connect to, esentially installing a tunnel between our machine and their network. The machine that we decide to work on is given a single or a range of private IP addresses, which we can then access as we are inside that network.

kali

The bulk of work done in the exploitation of the machine is within the Kali Linux operating system. Kali is a flavour of Linux specially built for penetration testing and exploitation, and includes about 3000 different tools, scripts and frameworks already installed, a selection of which we will be using.

nmap

Tools to be used are generally classified in different categories, such as auxiliary scanners, vulnerability scanners, exploitation tools and payloads.
Initial work is done using an auxiliary scanner such as nmap, which essentially communicates with the target computer and abuses the full capabilities of the TCP/UDP networking protocols to provide us as much information about the target as possible.

Dirbuster

Another avenue of auxiliary scanning is possible if the target machine is running a web server, as was the case of the Teacher machine. A tool named Dirbuster can be used, which guesses at possible web pages that the server can contain by using a dictionary of a few thousand of the most common web page names (such as index.html, /blog.php, /wordpress etc). Since initially we will have no idea about the structure of a website, we must use a tool like this to identify specific pages of interest. Moodle is an example of a page of interest that would not be found using any other type of tool.

hydra

Since a primary vulnerability was the user password, we can use tools such as Hydra, which acts like a brute force guesser of passwords given a specific dictionary. This attack involved creating a custom dictionary to launch a guessing attack against a password which was mostly known barring some missing characters.

netcat

Once we have scanned the target and have identified potential channels of attack, we can then use a tool that will allow our machines to communicate to each other via that open channel. Netcat is an example of that tool, in which we can send commands back to our computer once we have infiltrated remote access on the target server.

reverse shell

The primary workhorse of this attack was the use of a Reverse Shell. A reverse shell is a program which we can execute on the target machine in clever ways in order to allow access to it from our computer. In this scenario, we have exploited Moodle to incorporate a reverse shell into the Moodle server, which lets us connect to it via netcat as mentioned above, and thus begin to take control of the machine.

Recon

The first step of enumeration is reconnaissance - the art of gathering as much information as we can about the subject.

The very first step I take for recon is run an nmap scan, which will tell us exactly how the target machine appears to the outside world. It’ll tell us about all the channels it’s communicating with, which services it’s sharing with the world and show me potential footholds for attack.

I run this using the command:

1

nmap -sV -v -T4 -A {ip address}

The structure of this command is as follows:

-sV - A parameter that lets us view the Version of any services it is running.
-v - Run in verbose mode, which tells the program to output more information than normal back to us while running, including non critical things like status of the operation, problems etc.

-T4 - Run the program with 4 Threads. A thread is similar to a lane of traffic of a highway, but for the CPU of the computer. This parameter lets us run the command using 4 lanes of traffic, which can help parallelize and quicken the operation.

-A - Attempt to gather information about the OS, including OS name, version, traceroute and potential scripts running

The output of the command may look something similar to this:

Straight away we can see that there is an open TCP port at port 80. From experience, I know that this is the port that HTTP traffic communicates on AKA the tangible internet that we can access via a web browser. This means, if we type in http://10.10.10.153 into a web browser, we should be able to see what that web server is offering us.

Great - We have a public facing website. We can then use some more reconnaissance tools such as Dirbuster to guess at which else comes after 10.10.10.153/ so we can laterally traverse the website without having any knowledge of it.
Dirbuster usually requires a wordlist, which is essentially a large text file containing the most popular variations of page names, and then begins guessing and trying to reach those pages. If it fails, then the web server will simply display a 404 error, which means the requested content was not found. If Dirbuster guesses right, it’ll let us know.

We can use dirbuster in the following way:
dirb http://10.10.10.153 /usr/share/wordlists/dirb/common.txt
This will use the ‘common’ wordlist, which contains maybe 3000 different variations. If time is not a problem, you could opt for an even larger wordlist.
After a few minutes, dirbuster can reveal some interesting information:

Dirbuster has found a moodle page, which is something that we would not be able to find via the front page of that website if we looked.
Moodle is a piece of software running somewhere on that web server. A piece of software that is likely to have vulnerabilities, which it’s now time to scan.

Vulnerability Scanning

Vulnerability Scanning is essentially a research project on it’s own. There are a few main sources of the information, but Google will be the primary source.
Exploit-DB.com is also an excellent source of viewing published vulnerabilities of software and their intended target version. We begin by searching for our potential software flaw using Exploit DB:

There are many avenues of attack we can use, however after reading through each of these exploits they mostly involve getting access to a teacher’s account within moodle. We don’t have an account at all, nor can we create one.

Before we proceed, we need the credentials for a teacher account. We must traverse laterally back to what we have discovered in our enumeration already to see what we missed. At this point, we have only found a website, so we can begin by going back and looking at the website itself.

After a bit of manual trawling through the pages, we can see our first anomaly. This gallery of teachers has a broken picture at the very top left.

This is a cause of investigation. We can view the source code of the website by pressing the View Source button if we right click anywhere on the page. We are then greeted with this:

images/5 is the only image that has an ‘onerror’ tag within the HTML. This means that possibly someone has purposely made this image invalid in order to provoke that error mesage into the console.
If we try and access that image by itself we can see that the browser cannot display it:

I know from experience that if you attempt to open some file that has been renamed an image, or was not originally an image in the first place will cause the browser to give this message. We can then begin forensics of this file to determine what is is.

To begin forensics, we need to download this image, use our Operating System to see if it knows what type of file it is, then view it:

We got the image, used Kali to tell us what it is, then displayed the contents of the supposed text file. We now know that a user named Giovanni has the password Th4C00lTheacha* - with the asterick representing an unknown character.
If you refer back to the previous image where we found the Moodle page - we noticed that the Algebra class was taught by a Giovanni. We now have a potential vector for credentials. As a caveat, this is probably the most unrealistic situation in this environment. However, the teacher’s password could be gathered another way in the real world. As an example, the teacher may write down their password on a post-it note or notebook somewhere and simply leave it at their desk. It would be a trivial exercise to ask for a meeting with the teacher at her desk or office, the secretary asking you to wait near that room while she gets the teacher, then performing some physical recon or lockpicking in, having a peek at the password and gaining credentials in that fashion.

This vulnerability is the human one - A password is meant to be kept secure, unique and not easy to be guessed. This is a rule that is broken incredibly often, and is most likely the cause of 99% of security breaches in the world.

Exploitation

So we have part of a password, and now we need to break in to Giovanni’s account. Since we only have to guess 1 character, we have to map out each possibily of alphanumeric or symbolic characters.

Here we have created a text file with every variation. We can then feed this to a tool named Hydra, which will guess every single possibility of passwords using those characters we have entered in the wordlist.
We can use hydra in the following fashion:

hydra -l Giovanni -P /wordlist.txt 10.10.10.153 http-post-form "/moodle/login/index.php:username=^USER^&password=Th4C00lTheacha^PASS^:Invalid login, please try again" -Vv

Here is this command broken down:
-l - login as user Giovanni
-P - use a Password file, the one we made and called it wordlist.txt
http-post-form - A Post form is essentially just a form that we submit to a website, like a login screen, shopping cart, etc.
"/moodle/login/index.php" - The location of the actual login page in your browser’s address bar.
username=^USER^&password=Th4C00lTheacha^PASS^ - Use the username we supplied at the beginning, then the password we supplied with the file. Since we know most of it, we can just add the ^PASS^ segment to the end of the line
:Invalid login, please try again - The message we see on our screen that indicates failure to log in. Hydra needs to know when it has failed.
-Vv - Enable Verbose level 2, this means we want a lot of information to be played back.

After we run this command, we may see some output like the following:

Hydra has announced a success - We now have a password, and can begin exploiting the Moodle software itself, since the methods we researched involved teacher access.

After logging in and prodding around the environment, we stumble across a page that lets us upload custom questions for a Quiz. This is exactly the page we needed, as previous research has indicated that this version of Moodle has a security flaw which allows a teacher to execute code within the custom quiz creation

Since we have done the research, we can exploit this immediately. That web page suggests we enter the following code into the Question field, and then manually adjust the URL at the top of the browser to execute whatever we need it to:

We now need a method of creating a reverse shell

Without revealing the exact method of opening the reverse shell, we ask the Moodle server to initiate a netcat connection to our machine, and ask our machine to listen for that connection from the Moodle server.
We can begin listening using the following code:
nc -nlvp 5555
The structure of this command is as follows
-n - numeric IP addresses only, don’t resolve the actual name of the website
-l - listen mode. We are asking our computer to listen for a connection
-v - verbose mode. Output more information about the running process
-p - port number. The port number indicates from which channel we are listening on. In this case, we will listen on port 5555, which means we have to send the request from the Moodle Server from port 5555.

We now have direct terminal access to the machine, but as an unpriviledged user. With a UNIX based server, any sort of service must be run by a user account. In this case, the web server is run by the ‘www-data’ account. This account has absolutely no permissions to do or see anything except files neccessary for the web server to operate. We must then use a technique of enumeration called Privilege Escalation in order to log in to the terminal access as another account, preferably another user. This means we need to find some more user credentials

Our first step of terminal enumeration is to see exactly what is running on the machine itself, in the hopes we can find something to exploit. We can run the following command:
ps aux
This command will show us the current processes running, while the aux parameter will let us know exactly where this process is running from, what arguments are run with it and more.

This command, for this scenario, has revealed a Relational Database system named MariaDB. Upon trying to log into MariaDB, we are asked for yet another password.
This is where the human vulnerability comes into play again, as usually, the password for this system is hardcoded on the configuration file. So we can read this file, get some credentials, and attempt a log in in that way.

As you can see, the password was written in plain text as Welkom1!, which we were able to use to log into MariaDB. Now that we are here, all we need to do is view a database table - specifically the table for users, and see if MariaDB has stored the user’s password in an unsecured fashion.
We can write an SQL query like the following:
Show tables - First we need to figure out where the Users are stored via a table name, so we can query the database
We find out that the table is called mdl_user, so we can then query that table to return a username and password like so:
SELECT username, password FROM mdl_user

From the output above, we can see that the passwords were encrypted. From experience, I know that the first few passwords shown are encrypted with a strong algorithm, possibly SHA256 with a salt, which would mean that these passwords are impossible to crack. However, there was a password listed here for a backup user that was only 32 bits long, which I recognized as being possibly an MD5 hash. I used an online tool to confirm my suspicions. This means that password can easily be cracked:

We now have a password for a user named Giovannibak - I assumed this to be a historical record for Giovanni’s details, and hopefully she doesn’t change her passwords much. I tried to log into the machine using her details directly using ssh:

ssh giovanni@10.10.10.153 - Then logged in using her password. This worked, and I was now logged in as a normal account with permissions.

Now we have to begin enumeration again. This time, as a privileged user it’s quite easy. We can look at all of Giovanni’s personal files and find anything strange using the ls command to list all items in our ~ home folder.
I have watched some tutorial videos in the past for unrelated machines, and what I saw remined me of a video I saw called Joker by Ippsec, in which this same technique of priv esc is used.
After looking at the home directory on the right, we can see some backup files, which are regenerated every 30 seconds from some source. The backup file just creates a copy of the current home directory.

The techniques I learned in this video can be used here - We can trick that timed backup to backup a different file by pretending that the folder that the backup process is backing up is somewhere else through the use of a symbiotic link.
A symbiotic link in a UNIX system is essentially a shortcut saying ‘This file is actually somewhere else’. So, I tricked the backup process into backing up the root directory of the computer, which will contain information about the end level of this machine - the administrator.

So then I just had to wait 30 seconds, and that backup file has backed up the entire root directory. From here, I can just open the backup file and read the contents, and obtain the root password.

Mitigation

Mitigation for this attack will include keeping software up to date at all times, especially if it is closely related to other sensitive systems, such as the user database.
A stronger password policy will also need to be applied, as passwords were kept insecurely. An immediate refresh of all passwords via a linux administration system, as well as disabling the setting of the password if it does not meet minimum complexity requirements.

A scheduled process should also be used to ensure that all software is kept up to date, as this particular exploit of Moodle was patched fairly quickly.