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.
Vulnerability discovered: October 9, 2020 Vulnerable versions: versions between Moodle 2.8 (November 2014) – Moodle 3.10 (November 2020) Fixed versions: 3.10.1, 3.9.4, 3.8.7 and 3.5.16 Vendor notified: October 11, 2020 Response received: October 12, 2020 Patch issued: December 2, 2020 Patched version released: January 25, 2021
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
Technical Explanation:
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 viewing what was posted by a user in the server response, contents of the processed result is placed in a script tag with the type MathJax/TeX to be rendered on the client’s browser. With these inputs HTML entity decoded, there is no longer a server-side measure preventing anyone from closing this MathJax/TeX script tag, and opening a new script tag to inject our javascript code to the page.
Non-Technical explanation:
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.
Lousy Student: Our attacker model, a student account with limited permissions; Hardworking Student: Our victim model 1, a classmate of Lousy Student, also has limited permissions; Annoying Teacher: Our victim model 2, teacher who is assigned to the course who has complete permissions over that one specific course; Admin: Our last victim model (3), the website administrator. Every Moodle website has at least one administrator account, as it is created during the setup. This account has complete access to everyone’s profile, full moderation on every course, full access to site administration tools, and limited access to the rest of the server.
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. When someone opens this discussion board, it confuses Moodle into running parts of it as javascript code on the viewer’s browser, allowing the attacker to do any action on the website as if they were on the side of the viewer, without anything ever being noticeable by the viewer. 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. This demonstration starts similarly to the first one — the attacker posts a long piece of text which is being misinterpreted by Moodle and runs as javascript code on the viewer’s browser. The only difference is that we are using a completely different javascript code, which is crafted to change grades. As before, the victim/viewer does not suspect anything wrong, but as you can see, the grade has been updated successfully.
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:
Steal homework or any other submitted assignments; Steal any uploaded files; Modify uploaded files; Read direct messages; Edit profile settings; Send any kind of post on the forum or direct messages in your stead.
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.
This would let attackers to: Steal uploaded files that may contain answer sheets or unreleased exams; Send any kind of posts on forums or direct messages in one’s stead; Modify the course and the course content in one’s stead; Modify grades for exams and homework; Enroll or un-enroll students to class; Download/delete other student’s homework so they can steal it and reupload it as their own.
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:
Change Moodle’s settings like the domain name or other settings; Change accounts rights (like which accounts are administrator); Change which accounts are teachers for which courses; Modify any users account settings; Modify any users password; Set up any plugin to the website (which could give full database access to the attacker);
Mitigations
We strongly suggest updating your Moodle installation to the latest version if possible and not rely on mitigations in the long term.
What Can I Do to Protect My Data?
If you are a staff member for an institution that is using Moodle and you haven’t updated to the most recent version or haven’t applied the mitigations yet, you should be careful when using Moodle. We suggest avoiding parts of the website where all users are able to input text, like direct messages, discussions, chats, or user profiles. Keep in mind that if you were exposed and your account compromised, you might not notice anything wrong with your account.
Who is Wizcase?
WizCase is one of the biggest international online security websites, with content translated into 30 different languages. We provide tools, tricks, and best practices for online safety and security. This includes detailed VPN reviews and tutorials. Our online web security team of White Hack hackers have uncovered some of the biggest data breaches, including unsecured webcams and dating site scandals. Not only do we release our reports to the public, but we disclose them to the company as well, allowing them to secure their servers and creating a more secure environment for everyone.
