If you are a teacher or a student then you must have heard about Moodle. It is one of the most popular learning management systems in the world. It has over a hundred million users, which makes it an attractive target for hackers and exploiters. Instances of hacking and defacing Moodle-based services are becoming more common now. These incidents call for awareness regarding Moodle security. By knowing about the various security threats and adopting some basic safety measures, you can easily protect your Moodle platform.
Understanding the security
To understand the security of your web application, you need to understand the various types of users of your Moodle-based application. Based on that you can custom fit your Moodle security system.
- Administrators: Administrators will have all privileges such as for changing all the settings, create and access various courses; modify all language packs, and also the users. They can also execute shell and PHP codes. Administrators in Moodle applications can be restricted in certain areas by hardcoding certain settings in the config.php file.
- Teachers: Teachers are the ones responsible for designing courses, enrolling, and teaching students. They will usually require permissions for uploading files and submitting HTML texts, for creating and managing activities and access information such as grades and personal information of students. Files containing flash, JavaScript, and other scripts are generally considered security risks. However, these files are commonly used by teachers, and removing them is not possible. There is always a certain amount of risk when considering the privileges the teachers have.
- Students: Students are the main participants in the courses. They will generally require the following permissions:
- For posting formatted texts along with inline images and attachments
- For uploading binary documents (files that contain text and the formatting in binary form)
- Guests: Unregistered guests can be spammers or hackers trying to find backdoors or insert one into your application. Try to disallow them from uploading any type of file or submit any type of text. Sites having the user sign up via email must be careful of spammers and numerous other types of attacks.
What types of attacks are we dealing with?
These are some of the common attacks:
- Unauthenticated and unauthorized access
- Cross-site request forgery
- SQL Injection
- Cross-site scripting
- Data loss
- Command-line injection
- Session fixation
- Denial of Service
- Brute force login
- Confidential and configuration information leakage
- Social engineering
The following provides a closer look at a few common attacks
- SQL Injection: Any attacker can delete all the data in your application using SQL Injection attacks, especially when your code fails to clean the parameters properly. In Moodle 2.0, the concatenation of strings is completely avoided, and instead, it would pass an array of values to the database with the SQL. To protect your web application from this type of attack, use higher-level dmlib methods, such as get_record, this will eliminate the need for you to create SQL yourself. Use place holders wherever you need to insert values into SQL statements.
- Cross-Site Scripting: In Moodle, users can type in HTML which in turn is displayed on the website. Thus, if the content has any hidden JavaScript, the user can have full access to everything on the page. Moodle helps in preventing cross-site scripting by cleaning the input, dividing the input into various categories, and by providing specific JavaScript guidelines for users. When the data comes in, using the optional_param or required_param functions, you can be sure of the input data. Moodle also divides the input into four categories: plain text, labels as plain text, HTML content by any user, and HTML content input by trusted users. Depending on the input data type, users can choose the output function to display them. Also, while sending data to JavaScript, users should follow the Java Script guidelines and put the content in an external file. Then, communicate with the file by using $Page->requires->js_function_call or $Page->data_for_js functions. These functions encode all PHP data before passing it to JavaScript.
Past security flaws
Security loopholes in the past let attackers enter into the system. Developers have patched them since, but they provide useful insights into how attackers exploit the vulnerabilities. Some of these are:
- The /badges/mybackpack.php file had a vulnerability that allowed setting the URL of badges, while it should be restricted only to the Open Badges backpack URL of Mozilla. There was a possibility of blind SSRF via requests by the page in this vulnerability.
- The capability named “Managing Groups” earlier was missing the “XSS Risk” flag. This capability was to be available only to trusted users, thus it was assigned to managers and teachers by default.
- To prevent login cross-site request forgery, the login form was not protected by any token. This was a serious risk since this can allow attackers to steal data or change passwords.
- During importing “drag and drop into the text” questions in quizzes, it was possible to inject and execute PHP code from within the questions. Infected questions or questions from untrusted sources could use this vulnerability to enter and cause harm to the application.
These were a few vulnerabilities in Moodle that were fixed. They are the perfect example to show how attackers can leverage various backdoors and bugs to exploit the system. Being vigilant about such gaps in your Moodle security helps in quickly resolving them and securing them.
An in-depth analysis of an attack
The following is an example of Code Injection through a major vulnerability in Moodle. RIPS Code Analysis detected a vulnerability that allowed users with the role of a Teacher to perform code execution within the application.
The attacker and the attack:
Any user who is assigned the role of a teacher can exploit this vulnerability. One can also escalate their role with the use of any other gap in security. Any attacker with this knowledge can run arbitrary commands on the operating system running the Moodle’s server.
The vulnerability:
Moodle has a feature that allows teachers to enter mathematical formulas. Moodle then evaluates these formulas with randomized values that prevent students from sharing their answers. After inserting random values in the formula, Moodle calls the eval() function on the formula which evaluates the answer. To prevent eval() from executing harmful codes, the developers have introduced a qtype_calculated_find_formula_errors() function which is a validator function. Moodle evaluates this function before the eval () to detect malicious code.
Bypassing the security:
In the following code snippet, line 1939 will allow only specific characters (-+/*%>:^\~<?=&|!.0-9eE). However, in line 1927, a str_replace() replaces all placeholders {x} in the formula with 1. Thus, any potentially dangerous code with the same format will be hidden from the eval(). Thus, an attacker can nest their code within the outer placeholder which will bypass the replace function and reach the eval(). Once eval() allows the formula to pass, the attacker can execute the code within the application.
The fix:
On informing Moodle about the vulnerability, they proposed several patches. The first patch was to blacklist any formula that initiates a PHP comment. However, this patch was exploitable with a more sophisticated payload. The second patch was designed to prevent nested placeholders. However, this patch was also unable to completely prevent malicious formulas from getting through. The third patch combined the ideas of the first two patches. But, in this patch, if an attacker targeted the import feature present in the quiz component, then the attacker will be able to reimport a malicious XML file to take control of the $dataset argument. This will let them nullify the placeholders. Thus, this will result in the malicious code getting through like the earlier patches. Fortunately, the fourth patch was release and Moodle claims that this is the fix for this vulnerability.
How to tighten your Moodle Security
Securing your web applications is necessary to protect your web applications from common attacks. There are a few general requirements and safety steps that everyone should follow for stronger Moodle Security.
1. Have a separate administration backend:
Along with having a separate backend for administrators, using strong passwords is also a necessary step. Most users keep the default administrator password as “admin”. This lets attackers an easy way into the application. Make sure to use a strong password with a variety of alphanumeric characters. Also, enforcing a password policy will further strengthen your Moodle security. Moodle offers an option to set password policy which will let users set stronger passwords.
2. Avoid storing any sensitive information in the web application:
Storing sensitive information within the application will result in a huge loss during an attack. Also, keeping regular backups of all information on the application is a good practice. The backups will let you restore your defaced or damaged application. In case of any infection, you restore a fresh copy of all the important files and folders.
3. Prefer encrypted communication by using SSL:
Apart from using SSL for communication, using HTTPS for user login will protect the user’s information. It will be difficult for attackers to extract usernames and passwords of your users. You can enable HTTPS login by following some simple steps. In Settings, select Site Administration and within the Security option activate the HTTP security.
4. Try to log all user actions:
Tracking user actions helps in inspecting suspicious activities in the application. Along with tracking the actions, setting an appropriate folder and file permissions is also important. This will prevent unauthorized users from form accessing sensitive files and folders. Avoid configuring permissions with 777; instead use more secure permissions such as – 750 or 755.
5. Always keep your Moodle updated:
As mentioned above, there might be vulnerabilities that are revealed by developers and users. These vulnerabilities are patched up in the newer versions. Thus, updating your Moodle will help you protect your application. Each new version comes with better security and tools. Using outdated or unsupported versions will put you at a higher risk of attacks.
Avoid any 3rd party plugins or browser extensions:
Uninstalling unused plugins is a good way to keep your application safe. You can check all the courses which use plugins in Moodle. You can do this by going to Site Administrator, then Plugins, click on Activities, where you will find Manage Activities. Once you find out the plugins you are not using anymore, uninstalling them is a good idea for Moodle Security.
If you need some assistance
Protecting web applications can be tricky sometimes and attackers keep coming up with newer methods to get into the system. Thus, being vigilant will save you a lot of hassle. However, protecting your web application all on your own can distract you from the important stuff. This is where Astra comes in to assist you in safeguarding your application so that you can concentrate on the more important aspects. With their wide range of security features and tools, Astra can protect your application round the clock from any type of attack. With their state-of-the-art dashboards and security threat detection systems, you will get all the data regarding any attack on your application. So, if you want the best Moodle security without any hassle, then Astra is the right choice for you.