The Ultimate Moodle Security Practices and Malware Removal Guide
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 an 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.
- 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 files or submit any type of text. Sites having 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 attacks, 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.
Past security flaws
Security loopholes in the past let attackers to 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 the passwords.
- During importing “drag and drop into 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 the security. Any attacker with this knowledge can run arbitrary commands on the operating system running the Moodle’s server.
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 (-+/*%>:^\~ The expression to bypass the security[/caption]
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 the 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 which everyone should follow for stronger Moodle Security.
Have a separate administration backend:
- Along with having a separate backend for administrator, 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 strength your Moodle security. Moodle offers an option to set password policy which will let users set stronger passwords.
Avoid storing any sensitive information in the web application:
- Storing sensitive information within the application will result in huge loss during an attack. Also, keeping regular backups of all information of 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.
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.
Try to log all user actions:
- Tracking user actions helps in inspecting suspicious activities in the application. Along with tracking the actions, setting appropriate folder and file permissions is also important. This will prevent unauthorized users form accessing sensitive files and folders. Avoid configuring permissions with 777; instead using 750 or 755 is more secure.
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 stuffs. 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 attacks. 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.