At the beginning of October 2020, the Wizcase cyber research team, led by Ata Hakcil, discovered a security vulnerability in the open-source learning platform Moodle. Anyone who had an account on a given school’s Moodle (with TeX filter enabled) could then take over students’ accounts, professors, and even the accounts managed by the platform administrators.
Moodle is an open-source educational platform used by 179,000 sites and has 242 million users. It allows universities to distribute content to students and teachers. It allows teachers to easily communicate with students, organize and post links, documents, assignments, quizzes, and grades.
Who Was Exposed and For How Long
According to Moodle’s website, the platform has more than 242 million registered users in 251 countries. They are students, professors, school admins, and more. If you are using Moodle, we really suggest you take the “Mitigations” section to heart.
To understand the core of this issue, we’ve also tested it on previous versions, and we were able to trace this vulnerability back to a small code change in version 2.8.0, which was released on the 10th of November, 2014. This means that the vulnerability our team discovered had existed for 6 years before being discovered and patched.
Any university/school that had the TeX filter enabled was at risk. TeX filter is usually needed for sharing mathematical formulas, so any university with a scientific or economics department, or any field that requires mathematical formulas probably have the TeX filter enabled.
Tex filter can be enabled by the site administrator only and is enabled for all the users of the given site.
(Moodle offers an alternative method for rendering mathematical formulas using Mathjax, but it does not support some of the functionalities offered by TeX, and is commented on to be less backward compatible.)
How the Vulnerability Worked and What are the Consequences
As a Moodle user, you can communicate with other people who have access to the platform. This communication is happening through private chats/discussion boards that you are opening with the people of your choosing.
These “message boxes” allow you to type any content you would like to send to the recipient.
Moodle checks every single input in these for characters like , “ and encodes them properly with HTML entity encoding, while the backend rejects inputs without proper encoding. However, a small oversight with the math equations and TeX notation has allowed characters to slip by without encoding.
When TeX formulas are sent to the backend, the same rules apply: they are encoded using HTML entity encoding, and any input without proper encoding is rejected. But here is the catch: TeX interpreter will process this input and will decode the HTML entities in this process, allowing anyone to bypass the sanitization process.
When you try to communicate with students, professors, or admin, the box where you input text to be sent had a vulnerability (when TeX filter was enabled) that allowed you to insert content that would be read as code by Moodle, which would then implement it. It means that you could then implement code that would request a change in grades (or else), and the moment someone viewed the message you sent, it would have been applied without anyone being notified.
It is sometimes easy to misjudge what can and can’t be done when an attacker can do anything in your stead on a website, so we’ve created some demonstrations.
We’ve installed Moodle and enabled TeX filter on our own servers to demonstrate this vulnerability without causing any harm to others. For these demonstrations, we are going to have 4 different accounts.
We will define “viewer” as the person receiving the message from the attacker and opening it.
In our report, we decided that the “hacker” account would be a student account, but it could be any other account type (teacher or manager).
Student account takeover
For our first demonstration, we are going to show what an attacker can do with another student’s account.
On the video, you can see our attacker model, “Lousy Student” post a small snippet designed to trigger the vulnerability, which is misinterpreted by Moodle and instructs the viewer’s browser to visit another (malicious) website and to run the code it sees on it.
With this demonstration, our goal was to “steal” the submitted homework from “Hardworking Student”.
Teacher account takeover
For our next demonstration, we’re going to show a more critical aspect of the vulnerability.
This time, instead of going after “Hardworking Student”s homework, our attacker is tackling the problem right at the source – by compromising the teacher’s account to change their grades.
Admin account takeover
In this last demonstration, we are going to expose the biggest threat raised by the vulnerability. This time the Administrator’s account is going to be compromised, with the attacker gaining full control of anything on the website as well as partial control on the server the website is running on.
This attack starts like the previous ones, but this time a much smaller input is being sent to the website. When the administrator visits the forum post, they do not suspect anything wrong is happening. However, they’ve visited the malicious website in the background, where they unwillingly downloaded and ran the script they found on this website. That gave the hacker control over the server, and allowed them to view the credentials Moodle uses to connect to the database, which contains all the data the website stores.
Consequences and risks
The main threat engendered by this vulnerability is “account takeover”.
For example, if an admin account is compromised (a harmful message opened in the chatbox), an attacker would be able to access the username and hashed passwords of all the server users and modify their password to something else. As the admin can read database configuration, and the database contains the hashed passwords of all the users, they could either crack those or just change it to something else directly. The attacker could also grant himself admin rights (as admins have this option) and then lock out the other admins.
Even without compromising the admin account, they could just steal the cookies of other users viewing the vulnerable pages, which would allow them to log in as these users (but they would lose access after that person logs out).
This would allow any attackers to do anything another user can do on Moodle without the victim ever knowing it.
For each kind of account, the impact of the account takeover varies significantly. Please find below a non-exhaustive list of what could be done by a bad actor:
Account Takeover – For Other Students
Viewing other students’ direct messages, profile descriptions, chat messages, or discussion posts could give them access to the account. Be skeptical when visiting links sending to your school’s Moodle (whether they are students’ profiles, forum links, or anything else), even if the URL looks safe.
This would let attackers to:
Account Takeover – For Faculty Members
Always be skeptical when opening pages where there is content other users have permission to edit or add – such as forum posts, direct messages, other people’s profiles. If there are any similar vulnerabilities, viewing these kinds of contents may cause you to accidentally change grades or can allow attackers to use your account as a medium when attacking other faculty members or administrators.
Account Takeover – For Administrators
Do not interact with other members from an account with administrator permissions. If you need to read forums or messages, it would be better to create another account that doesn’t have the same permission and keep the admin accounts unused to perform these actions.
This would let attackers to:
We strongly suggest updating your Moodle installation to the latest version if possible and not rely on mitigations in the long term.
Original post at
About the author Chase Williams
If you want to receive the weekly Security Affairs Newsletter for free subscribe here.
(SecurityAffairs – hacking, Moodle)
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.