Vulnerability: Est. Millions of s of Popular Educational Platform Exposed to Takeover Threats And More

What’s Going On?

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 on a given school’s Moodle (with TeX filter enabled) could then take over students’ s, professors, and even the s managed by the platform s.

Moodle is an open-source educational platform used by 179,000 sites and has 242 million s. 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 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 only and is enabled for all the s of the given site.
(Moodle offers an alternative method for rendering mathematical formulas using Mathjax, but it does not 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 , 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 by the sanitization process.

When viewing what was posted by a 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 , 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 s.

• Lousy Student: Our attacker model, a student 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;
• : Our last victim model (3), the website . Every Moodle website has at least one , as it is created during the setup. This has complete access to everyone’s profile, full moderation on every course, full access to site istration 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” would be a student , but it could be any other type (teacher or manager).

Student takeover

For our first demonstration, we are going to show what an attacker can do with another student’s .

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 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 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.

takeover

In this last demonstration, we are going to expose the biggest threat raised by the vulnerability. This time the ’s 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 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 ed 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 “ takeover”.

For example, if an is compromised (a harmful message opened in the chatbox), an attacker would be able to access the name and hashed s of all the server s and modify their to something else. As the can read database configuration, and the database contains the hashed s of all the s, they could either crack those or just change it to something else directly. The attacker could also grant himself rights (as s have this option) and then lock out the other s.

Even without compromising the , they could just steal the cookies of other s viewing the vulnerable pages, which would allow them to as these s (but they would lose access after that person logs out).

This would allow any attackers to do anything another can do on Moodle without the victim ever knowing it.

For each kind of , the impact of the takeover varies significantly. Please find below a non-exhaustive list of what could be done by a bad actor:

Takeover – For Other Students

Viewing other students’ direct messages, profile descriptions, chat messages, or discussion posts could give them access to the . 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 ed files;
• Modify ed files;
• Read direct messages;
• Edit profile settings;
• Send any kind of post on the forum or direct messages in your stead.

Takeover – For Faculty

Always be skeptical when opening pages where there is content other s 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 as a medium when attacking other faculty or s.

• This would let attackers to:
• Steal ed 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;
• /delete other student’s homework so they can steal it and re it as their own.

Takeover – For s

Do not interact with other from an with permissions. If you need to read forums or messages, it would be better to create another that doesn’t have the same permission and keep the s unused to perform these actions.

This would let attackers to:

• Change Moodle’s settings like the domain name or other settings;
• Change s rights (like which s are );
• Change which s are teachers for which courses;
• Modify any s settings;
• Modify any s ;
• 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 s are able to input text, like direct messages, discussions, chats, or profiles. Keep in mind that if you were exposed and your compromised, you might not notice anything wrong with your .

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 White Hack team comprised of online web security experts has discovered some of the largest data violations, which involve unprotected webcams and controversies linked to dating sites.

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.